帳號:
密碼:
最新動態
 
產業快訊
CTIMES / 文章 /
閒話RFC─RFC 2706與RFC 2739
 

【作者: 洪進吉】   2000年03月01日 星期三

瀏覽人次:【12172】

RFC 2706

一個電子商務的應用

很多人認為RFC僅是一些通訊協定,應該甚少接觸到商業上的應用,這是不爭的事實。將RFC直接用於商業用途真的很少,因為在「標準」的概念中,必須要有相當的公認性才有可能成為標準,但相對的,在實務上,若直接牽涉到商業行為,很少能夠產生一定公認性的協定,因此不難想像,如欲在RFC看到純為商業用途所提出來的Standard Track應該是比較困難的。


雖說在Standard Track沒有,但並非所有的RFC都必須變成一種標準,這樣就失去RFC的精神了,因此在Infomational部份,筆者試圖尋找泛商業性質的RFC,且亦的確看到了一篇與電子商務具備相當關連性的RFC文件,就是RFC 2706─ECML v1:Field Names for E-Commerce,這裡的ECML指的是Electronic Commerce Modeling Language。


背景

在一般的傳統商務裡,為了要完成交易行為,必須定義出很多語法與格式,就像我們用會計來處理帳務一樣,商業的書信也有一定的方式,這些都是為了促進交易程序更為嚴謹,即便產品本身有不同的屬性,但在交易程序中所須要的共同元素是免不了的。


在電子商務中,金錢交易的電子化佔了相當重要的地位,所謂「金錢交易的電子化」,簡言之即是「電子錢包」(Electronic Wallets),但事實上,推動電子錢包並不容易,也正因以往缺乏標準的關係,才會有ECML的推出,由於ECML的任務在於加速電子商務的推展,因此,ECML獲得了AOL、IBM、Novell、Sun、VISA等十數家大廠的支持(註一)。


架構

吾人所熟知大部份的電子交易行為均透過Web網站達成,且多以Form來溝通,但最大的問題是,在Field上每一個人的想法多少都有點不同,所以,如何訂定一種Form的Field,讓大家能夠順利依循與使用,這樣才有可能進行資訊交換,進而達成商業交易行為。但也因為這是一個共同發展的協定,所以它會架構在一些既有的基礎上,應用到的便有SSL/TLS(RFC2246)、SET、XML跟IOTP等。


內容

在ECML v1.0中,定義了幾個欄位(field)來做溝通,請見(表一):


《表一 》
《表一 》

由表一可看出,這些field包含了一些基本的交易行為,讓電子商務或電子錢包更容易進行交易,這也是ECML的精神。當然,這些欄位都有定義,也有最小的表示值,這裡筆者將試圖舉個例子來說明在HTML上實作的方式︰


交易時


<HTML>
<HEAD>
<title> eCom Fields Example </title>
</HEAD>
<BODY>
	<FORM action="http://ecom.example.com" method="POST">
	Please enter card information:
	<p>Your name on the card
		<INPUT type="text" name="Ecom_Payment_Card_Name" SIZE=40>
	<br>The card number
		<INPUT type="text" name="Ecom_Payment_Card_Number" SIZE=19>
	<br>Expiration date (MM YY)
		<INPUT type="text" name="Ecom_Payment_Card_ExpDate_Month" SIZE=2>
		<INPUT type="text" name="Ecom_Payment_Card_ExpDate_Year" SIZE=4>
		<INPUT type="hidden" name="Ecom_Payment_Card_Protocol">
		<INPUT type="hidden" name="Ecom_SchemaVersion"
		value="http://www.ecml.org/version/1.0">
	<br>
		<INPUT type="submit" value="submit"> <INPUT type="reset">
	</FORM>
</BODY>
</HTML>



交易完成


<HTML>
<HEAD>
<title> eCom Transaction Complete Example </title>
</HEAD>
<BODY>
	<FORM>
	Thank you for your order. It will be shipped in several days.
		<INPUT type="hidden" name="Ecom_TransactionComplete">
		<INPUT type="hidden" name="Ecom_SchemaVersion"
			value="http://www.ecml.org/version/1.0">
	</FORM>
</BODY>
</HTML>



小結

筆者在看到這一篇RFC時,也是相當有興趣的,因為真的很少有這樣的RFC。


現在還在起草的ECML v1.1中,除了就一些小問題修正外,最主要的還是補強XML的部份與範例,這也說明了XML在資訊交換的重要性。


除了ECML外,IETF在起草有關電子商務的通訊協定時,還有Simple Commerce Messaging Protocol(SCMP)跟Internet Open Trading Protocol(IOTP),若時間許可,筆者將儘快為各位紹這些Protocol,它們均相當有趣亦具備前瞻性。


RFC 2739

Calendar Attributes for vCard and LDAP

所謂的Calendar Attributes for vCard and LDAP,即是在vCard與LDAP實現Calendar的方法,以往無論就email、檔案或網頁的傳遞,都有相對應不錯的通訊協定可資完成,但行事曆的通訊協定還沒有一個普遍的方式,即使某些程式如Outlook在這方面看來似乎是成熟的,但說真的,這也只是Microsoft既定的規則。


行事曆上所衍生的應用在未來具備相當的遠景,因為,人們真的除了能夠做言語的溝通外,共同生活也是一件很重要的事,而能夠共同生活,就是要了解彼此的狀態與行事曆(狀態的問題以後將在Instant Message的Status與Notification中討論)。行事曆的交換,是進一步讓大家的生活互相參與的重要機制,因此就網路所扮演的角色而言,這是一個很重要的功能。


內容定義

定義出下面四種的URI:


1.Free/Busy URI (FBURL)


2.Calendar Access URI (CAPURI)


3.Calendar URI (CALURI)


4.Default URIs


在vCard的使用上,也是用這幾個Property,以vCard的形式呈現,如下列這個例子:



BEGIN:VCARD
VERSION:3.0
N:Dun;Alec
FN:Alec Dun
ORG:Microsoft Corporation
ADR;WORK;POSTAL;PARCEL:;;One Microsoft Way;
Redmond;WA;98052-6399;USA
TEL;WORK;MSG:+1-206-936-4544
TEL;WORK;FAX:+1-206-936-7329
EMAIL;INTERNET:user@host1.com
CALADRURI;PREF:mailto:user@host1.com
CALURI;PREF:http://cal.host1.com/user/cal.ics
FBURL;PREF:http://cal.host1.com/user/fb.ifb
CALURI:http://cal.company.com/projectA/pjtA.ics
FBURL:http://cal.company.com/projectA/pjtAfb.ifb
END:VCARD



而在LDAP則如下:



- One object class:
- calEntry

- Eight attributes:
- calCalURI
- calFBURL
- calCAPURI
- calCalAdrURI
- calOtherCalURIs
- calOtherFBURLs
- calOtherCAPURIs
- calOtherCalAdrURIs



小結

事實上,雖然鼓吹使用iCalendar、vCard跟LDAP的人不少,但真正使用的人不多,就實際應用而言,要被廣為接受尚須一段時日,即使筆者認為vCard與LDAP等應該算是一個已成熟的產品。


(作者為自由作家gene@tku.net)


備註

註一︰American Express、AOL、Brodia、Compaq、CyberCash、Discover、FSTC、IBM、Mastercard、Microsoft、Novell、SETCo、Sun Microsystems、Trintech、Visa等。


相關文章
強化轉型核心動力 打造更強數位韌性
數位轉型下的工具機發展趨勢
您的開源軟體安全嗎?
OLED與Mini LED爭逐主流PC顯示技術
企業創新契機 永續經營與數位轉型並行
comments powered by Disqus
相關討論
  相關新聞
» IBM提出「智慧金融藍圖」 籲善用生成式AI打造參與式銀行
» Ansys、台積電和微軟合作 提升矽光子元件模擬分析速度達10倍
» 微軟全新自主agents賦能團隊實現更多拓展性
» IBM公布企業AI治理手冊 協助AI治理速啟動、穩落地
» IBM研發的演算法成為後量子密碼學標準


刊登廣告 新聞信箱 讀者信箱 著作權聲明 隱私權聲明 本站介紹

Copyright ©1999-2024 遠播資訊股份有限公司版權所有 Powered by O3  v3.20.2048.18.216.251.190
地址:台北數位產業園區(digiBlock Taipei) 103台北市大同區承德路三段287-2號A棟204室
電話 (02)2585-5526 #0 轉接至總機 /  E-Mail: webmaster@ctimes.com.tw