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:[email protected]
CALADRURI;PREF:mailto:[email protected]
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等應該算是一個已成熟的產品。

(作者為自由作家[email protected])

備註

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