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等。