Network Working Goup D. Eastlake
Request for Comments: 2706 IBM
Category: Informational T. Goldstein
Brodia
October 1999
ECML v1: Field Names for E-Commerce
Status of this Memo
このメモの位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。全著作権所有。
IESG Note
IESG注意
This document is the output of a vendor consortium, and is not the output of an IETF Working Group. Implementors of this specification are warned that this data model is heavily biased toward conventions used in the United States, and the English language. As such it is unlikely to be suitable for international or multilingual use in the global Internet.
この文書では、ベンダーのコンソーシアムの出力であり、そしてIETFワーキンググループの出力ではありません。この仕様の実装者は、このデータモデルは、米国、および英語の表記に向けて大きく偏っていると警告しています。そのためには、グローバルなインターネットの国際または多言語の使用に適していることはほとんどありません。
Abstract
抽象
Customers are frequently required to enter substantial amounts of information at an Internet merchant site in order to complete a purchase or other transaction, especially the first time they go there. A standard set of information fields is defined as the first version of an Electronic Commerce Modeling Language (ECML) so that this task can be more easily automated, for example by wallet software that could fill in fields. Even for the manual data entry case, customers will be less confused by varying merchant sites if a substantial number adopt these standard fields.
お客様は、頻繁に購入またはその他の取引、彼らはそこに行く、特に最初の時間を完了するために、インターネットの商人のサイトで情報のかなりの量を入力する必要があります。このタスクは、より容易にフィールドに入力できたウォレットソフトウェアによって、例えば、自動化することができるように、情報フィールドの標準セットは、電子商取引モデリング言語（ECML）の最初のバージョンとして定義されます。かなりの数がこれらの標準フィールドを採用した場合でも、データの手入力の場合のために、顧客が加盟店サイトを変化させることにより、より少ない混乱するだろう。
Acknowledgements
謝辞
The following persons, in alphabetic order, contributed substantially to the material herein:
以下の者は、アルファベット順に、材料本明細書に実質的に貢献しました。
George Burne, Trintech
ジョージ・バーン、Trintech
Joe Coco, Microsoft
ジョー・ココ、マイクロソフト
Kevin Weller, Visa
ケビン・ウェラー、ビザ
Table of Contents
目次
1. Introduction................................................2
1.1 Background.................................................2
1.2 Relationship to Other Standards............................3
1.3 Areas Deferred to Future Versions..........................4
2. Using The Fields............................................4
2.1 Presentation of the Fields.................................4
2.2 Methods and Flow of Setting the Fields.....................5
2.3 HTML Example...............................................6
3. Field Definitions...........................................7
4. End Notes...................................................9
5. Security Considerations....................................10
References....................................................11
Authors' Addresses............................................12
Full Copyright Statement......................................13
Today, numerous merchants are successfully conducting business on the Internet using HTML-based forms. The data formats used in these forms varies considerably from one merchant to another. End-users find the diversity confusing and the process of manually filling in these forms to be tedious. The result is that many merchant forms, reportedly around two thirds, are abandoned during the fill in process.
今日では、数多くの商人が正常にHTMLベースのフォームを使用してインターネット上でビジネスを行っています。これらのフォームで使用されるデータ形式は、1人の商人から別のものにかなり異なります。エンドユーザーは混乱の多様性と、手動で面倒なことに、これらのフォームに記入のプロセスを見つけます。その結果、多くの商人フォーム、伝え周りの三分の二は、プロセス中の充填中に放棄されていることです。
Software tools called electronic wallets can help this situation. A digital wallet is an application or service that assists consumers in conducting online transactions by allowing them to store billing, shipping, payment, and preference information and to use this information to automatically complete merchant interactions. This greatly simplifies the check-out process and minimizes the need for a consumer to complete a merchant's form every time. Digital wallets that fill forms have been successfully built into browsers, as helper applications to browsers, as stand-alone applications, as browser plug-ins, and as server-based applications. But the proliferation of electronic wallets has been hampered by the lack of standards.
電子財布と呼ばれるソフトウェアツールは、このような状況を助けることができます。デジタル財布は、彼らが請求、出荷、支払い、嗜好情報を保存できるようにすることで、オンライン取引を行う中で、消費者を支援し、この情報を自動的に完全な商人の相互作用を使用するアプリケーションまたはサービスです。これは非常にチェックアウトプロセスを簡素化し、商人のフォームたびに完了するために、消費者の必要性を最小限に抑えることができます。フォームを記入デジタル財布が正常にブラウザにヘルパーアプリケーションとして、スタンドアロンのアプリケーションとして、ブラウザのプラグインとして、そしてサーバーベースのアプリケーションとして、ブラウザに組み込まれています。しかし、電子財布の増殖は、標準の欠如によって妨げられてきました。
ECML (Electronic Commerce Modeling Language, <www.ecml.org>) Version 1 provides a set of simple guidelines for web merchants that will enable electronic wallets from multiple vendors to fill in their web forms. The end-result is that more consumers will find shopping on the web to be easy and compelling.
ECML（電子商取引モデリング言語は、<www.ecml.org>）バージョン1は、自分のWebフォームに入力するために、複数のベンダーからの電子財布を可能にするWeb商人のための簡単なガイドラインのセットを提供します。最終結果は、より多くの消費者が簡単かつ説得力のあることをウェブ上で買い物を見つけることです。
The set of fields documented herein was developed by the Wallet/Merchant Standards Alliance (www.ecml.org) which now includes, in alphabetic order, the following:
本明細書で文書化されたフィールドのセットは、今含むウォレット/マーチャント規格連合（www.ecml.org）によって開発されたアルファベット順に、以下ました。
American Express (www.americanexpress.com)
AOL (www.aol.com)
Brodia (www.brodia.com)
Compaq (www.compaq.com)
CyberCash (www.cybercash.com)
Discover (www.discovercard.com)
FSTC (www.fstc.org)
IBM (www.ibm.com)
Mastercard (www.mastercard.com)
Microsoft (www.microsoft.com)
Novell (www.novell.com)
SETCo (www.setco.org)
Sun Microsystems (www.sun.com)
Trintech (www.trintech.com)
Visa (www.visa.com)
The fields are derived from and consistent with the W3C P3P base data schema at
フィールドが由来しにおけるW3C P3P基本データスキーマと一致しています
<http://www.w3.org/TR/WD-P3P/basedata.html>.
＜ｈっｔｐ：／／ｗっｗ。ｗ３。おｒｇ／ＴＲ／ＷＤーＰ３Ｐ／ばせだた。ｈｔｍｌ＞。
ECML Version 1 is not a replacement or alternative to SSL/TLS [RFC 2246], SET [SET], XML [XML], or IOTP [IOTP]. These are important standards that provide functionality such as non-repudiatable transactions, automatable payment scheme selection, and smart card support.
ECMLバージョン1は、置換または代替のSSL / TLS [RFC 2246]に、SET [SET]、XML [XML]、またはIOTP [IOTP]はありません。これらは、非repudiatable取引、自動化、支払方式選択、およびスマートカードのサポートなどの機能を提供し、重要な規格です。
ECML may be used with any payment mechanism. It simply allows a merchant to publish consistent simple web forms.
ECMLは、任意の支払機構を使用することができます。それは単に商人が一貫性の単純なWebフォームを公開することができます。
Multiple wallets and multiple merchants plan to interoperably support ECML. This is an open standard. ECML is designed to be simple.
複数の財布や複数の商人は、相互運用可能ECMLをサポートする予定。これは、オープンスタンダードです。 ECMLはシンプルになるように設計されています。
Version 1 of the project adds no new technology to the web. A merchant can adopt ECML and gain the support of these multiple Wallets by making very simple changes to the HTML pages that they currently use to support their customers. Use of ECML requires no license.
プロジェクトのバージョン1は、ウェブに新しい技術を追加しません。商人はECMLを採用し、彼らは現在、彼らの顧客をサポートするために使用するHTMLページへの非常に簡単な変更を加えることにより、これらの複数の財布の支持を得ることができます。 ECMLの使用にはライセンスは必要ありません。
Standardization of information fields transmitted from the merchant to the consumer, considerations for business purchasing cards, non-card payment mechanisms, wallet activation, privacy related mechanisms, additional payment mechanisms, and any sort of "negotiation" were among the areas deferred to consideration in future versions. Hidden or other special fields were minimized. The primary target was North American consumer to merchant electronic commerce.
消費者に商人から送信される情報フィールドの標準化、ビジネスの購買カード、非カード決済の仕組み、財布の活性化のための検討事項、プライバシー関連のメカニズム、追加の支払いの仕組み、および「交渉」の任意の並べ替えがで考慮に延期エリアの中にありました将来のバージョン。隠された、または他の特別なフィールドが最小化されました。主なターゲットは、商人、電子商取引に北米の消費者でした。
To conform to this document, the field names shall be as listed in section 3 below. Note: this does not impose any restriction on the user visible labeling of fields, just on their names as used in communication with the merchant.
以下のセクション3に記載されているように、この文書に準拠するには、フィールド名がしなければなりません。注意：商人との通信に使用されるように、これはちょうど彼らの名前の上に、フィールドのユーザー見えるラベルには何の制限もありません。
There is no necessary implication as to the order or manner of presentation. Some merchants may wish to ask for more information, some less by omitting fields. Some merchants may ask for the information they want in one HTML form on one web page, others may ask for parts of the information at different times on different pages. For example, it is common to ask for "ship to" information earlier, so shipping cost can be computed, before the payment method information. Some merchants may require that all the information they request be provided while other make much information optional, etc.
プレゼンテーションの順番や方法に関しては何の必要な意味はありません。いくつかの商人は、フィールドを省略することにより、いくつかの少ない、より多くの情報のためにお願いしたいことがあります。いくつかの商人は他の人が別のページ上の異なる時刻に情報の一部を求めることができる、一つのウェブページ上の1つのHTML形式で彼らが欲しい情報を求めることができます。例えば、以前の情報「に船」を求めるのが一般的ですので、送料は支払方法の情報の前に、計算することができます。いくつかの商人は他の多くの情報をオプションにしながら、彼らが要求するすべての情報は、など、提供することを要求することができます
There is no way with version 1 of ECML to indicate what fields the merchant considers mandatory. From the point of view of customer software, all fields are optional to complete. However, the merchant may give an error or re-present a request for information if some field it requires is not completed, just as it may if a field is completed in a manner it considers erroneous.
商人が必須と考えるものフィールドを示すためにECMLのバージョン1と方法はありません。顧客のソフトウェアの観点から、すべてのフィールドを完了するためにオプションです。それは必要とし、いくつかのフィールドが完了していない場合は、商人は、それがフィールドが、それは誤ったと考える方法で終了している場合と同じように、情報のエラーや再現在の要求を与えることができます。
There are a variety of methods of communication possible between the customer and the merchant by which the merchant can indicate what fields they want that the consumer can provide. Probably the easiest to use for currently deployed software is as fields in an HTML [HTML4.0] form. Other possibilities are to use the W3C P3P protocol or the IOTP Authenticate transaction [IOTP].
商人は、彼らは消費者が提供できることを望むものフィールドを示すことができたことで、顧客と商人の間で可能な通信の様々な方法があります。おそらく、現在配備ソフトウェアのために使用するのが最も簡単にHTML [HTML4.0]フォームのフィールドとしてです。他の可能性は、[IOTP] W3C P3PプロトコルまたはIOTP認証トランザクションを使用することです。
User action or the appearance of the Ecom_SchemaVersion field are examples of triggers that could be used to initiate a facility capable of filling in fields. It is required that the Ecom_SchemaVersion field, which is usually a hidden field, be included on every web page that has any "Ecom_" fields.
ユーザアクションまたはEcom_SchemaVersionフィールドの外観は、フィールドに入力することが可能な機能を開始するために使用することができるトリガの例です。通常、隠しフィールドでEcom_SchemaVersionフィールドは、任意の「Ecom_」フィールドを持つすべてのWebページに含まれている必要があります。
Because web pages can load very slowly, it may not be clear to an automated field fill-in function when it is finished filling in fields on a web page. For this reason, it is recommended that the Ecom_SchemaVersion field be the last "Ecom_" field on a web page.
Webページは非常にゆっくり読み込むことができますので、それはそれは、Webページ上のフィールドに入力終了する自動化されたフィールドフィルイン機能に明確ではないかもしれません。このため、Ecom_SchemaVersionフィールドは、Webページ上の最後の「Ecom_」フィールドにすることをお勧めします。
Merchant requests for information can extend over several web pages. Without further provision, a facility could either require re-starting on each page or possibly violate or appear to violate privacy by continuing to fill in fields for pages beyond with end of the transaction with a particular merchant. For this reason the Ecom_TransactionComplete field, which is normally hidden, is provided. It is recommended that it appear on the last web page involved in a transaction, just before an Ecom_SchemaVersion field, so that multi-web-page automated field fill in logic could know when to stop if it chooses to check for this field.
詳細については、商人の要求には、いくつかのWebページ上で拡張することができます。さらに設けることなく、施設は、各ページに再起動するか、おそらく違反したり、特定の商人との取引の終了に超えたページのフィールドに入力し続けることによって、プライバシーを侵害するように見える必要になる場合がありどちらか。このため、通常は隠されているEcom_TransactionCompleteフィールドについては、提供されます。マルチウェブページ自動化フィールドが、それはこのフィールドをチェックすることを選択した場合に停止したときに知ることができ、ロジックを埋めるように、それは、ちょうどEcom_SchemaVersionフィールドの前に、トランザクションに関与し、最後のWebページに表示されることをお勧めします。
An example in HTML might be as follows:
次のように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フィールドの例</ TITLE> </ HEAD> <BODY> <FORM ACTION = "http://ecom.example.com" 方法= "POST">カード情報を入力してください。<カード上にp>あなたの名前の<input type = "text" の名= "Ecom_Payment_Card_Name" SIZE = 40>は、カード番号の<input type = "text" NAME = "Ecom_Payment_Card_Number" SIZE = 19> <BR>有効期限を<BR> （MM YY）の<input type = "text" の名= "Ecom_Payment_Card_ExpDate_Month" SIZE = 2>の<input type = "text" の名= "Ecom_Payment_Card_ExpDate_Year" SIZE = 4>の<input type = "隠れた" NAME = "Ecom_Payment_Card_Protocol"> <入力タイプ= "隠された" 名前= "Ecom_SchemaVersion" 値= "http://www.ecml.org/version/1.0"> <BR>の<input type = "提出" 値= "提出"> <INPUTタイプ=」リセット "> </ FORM> </ BODY> </ HTML>
After all of the pages are submitted, the merchant will reply with a confirmation page informing both the user and the wallet that the transaction is complete.
すべてのページが提出された後、商人は、トランザクションが完了したことをユーザーや財布の両方を知らせる確認ページで応答します。
<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>
<HTML> <HEAD> <TITLE> ECOMトランザクションの完全な例</ TITLE> </ HEAD> <BODY> <FORM>ご注文ありがとうございます。それは数日中に出荷されます。 <INPUTの種類= "隠し" 名= "Ecom_TransactionComplete"> <INPUTの種類= "隠し" 名= "Ecom_SchemaVersion" 値= "http://www.ecml.org/version/1.0"> </ FORM> </ BODY > </ HTML>
The fields are listed below along with the minimum data entry size to allow. Note that these fields are hierarchically organized as indicated by the embedded underscore ("_") characters. Appropriate consumer to merchant transmission mechanisms may use this to request and send aggregates, such as Ecom_Payment_Card_ExpDate to encompass all the date components or Ecom_ShipTo to encompass all the ship to components that the consumer is willing to provide. The marshalling and unmarshalling of the components of such aggregates depends on the data transfer protocol used.
フィールドができるように、最小データ・エントリ・サイズと共に列挙する。埋め込みアンダースコア（「_」）文字によって示されるように、これらのフィールドは、階層的に編成されていることに留意されたいです。商人伝達機構への適切な消費者は、要求にこれを使用して、消費者が提供する意思があるコンポーネントにすべての船を包含するすべての日付コンポーネントまたはEcom_ShipToを包含するようEcom_Payment_Card_ExpDateなどの凝集を、送信することができます。そのような凝集体の成分のマーシャリング及びアンマーシャリングは、使用されるデータ転送プロトコルに依存します。
IMPORTANT NOTE: "MIN" in the table below is the MINIMUM DATA SIZE TO ALLOW FOR ON DATA ENTRY. It is NOT the minimum size for valid contents of the field and merchant software should, in most cases, be prepared to receive a longer or shorter value. Merchant dealing with areas where, for example, the state/province name or phone number is longer than the "Min" given below must obviously permit longer data entry. In some cases, however, there is a maximum size that makes sense and where this is the case, it is documented in a Note for the field.
重要：以下の表の「MIN」はONデータ入力を可能にするための最小データサイズです。これは、有効なフィールドの内容と商人のソフトウェアの最小サイズは、ほとんどの場合、長いか短い値を受け取るように準備されるべきではありません。分野を扱う商人はどこ、例えば、州/地方名や電話番号が明らかになりましデータ入力を許可する必要があります下記の「分」よりも長くなっています。いくつかのケースでは、しかし、理にかなっていると、これが事実である場合、それはフィールドの注記に記載されている最大サイズがあります。
FIELD NAME Min Notes
フィールド名ミンノート
ship to title Ecom_ShipTo_Postal_Name_Prefix 4 ( 1) ship to first name Ecom_ShipTo_Postal_Name_First 15 ship to middle name Ecom_ShipTo_Postal_Name_Middle 15 ( 2) ship to last name Ecom_ShipTo_Postal_Name_Last 15 ship to name suffix Ecom_ShipTo_Postal_Name_Suffix 4 ( 3) ship to street line1 Ecom_ShipTo_Postal_Street_Line1 20 ( 4) ship to street line2 Ecom_ShipTo_Postal_Street_Line2 20 ( 4) ship to street line3 Ecom_ShipTo_Postal_Street_Line3 20 ( 4) ship to city Ecom_ShipTo_Postal_City 22 ship to state/province Ecom_ShipTo_Postal_StateProv 2 ( 5) ship to zip/postal code Ecom_ShipTo_Postal_PostalCode 14 ( 6) ship to country Ecom_ShipTo_Postal_CountryCode 2 ( 7) ship to phone Ecom_ShipTo_Telecom_Phone_Number 10 ( 8) ship to email Ecom_ShipTo_Online_Email 40 ( 9)
ファーストネームのタイトルEcom_ShipTo_Postal_Name_Prefixに出荷4（1）船は姓Ecom_ShipTo_Postal_Name_Last名サフィックスEcom_ShipTo_Postal_Name_Suffix 4（3）船舶ストリートLINE1 Ecom_ShipTo_Postal_Street_Line1 20（4）船の通りに15船にミドルネームEcom_ShipTo_Postal_Name_Middle 15（2）船に15船をEcom_ShipTo_Postal_Name_First LINE2 Ecom_ShipTo_Postal_Street_Line2 20（4）船舶ストリートLINE3 Ecom_ShipTo_Postal_Street_Line3 20都市Ecom_ShipTo_Postal_City〜（4）船14（6）船舶国Ecom_ShipTo_Postal_CountryCode 2（7）船へ/郵便番号Ecom_ShipTo_Postal_PostalCodeを圧縮するための州/県Ecom_ShipTo_Postal_StateProv 2（5）船22船に電話Ecom_ShipTo_Telecom_Phone_Number 10 Ecom_ShipTo_Online_Email 40（9）を電子メールで送信する（8）船へ
bill to title Ecom_BillTo_Postal_Name_Prefix 4 ( 1) bill to first name Ecom_BillTo_Postal_Name_First 15 bill to middle name Ecom_BillTo_Postal_Name_Middle 15 ( 2) bill to last name Ecom_BillTo_Postal_Name_Last 15 bill to name suffix Ecom_BillTo_Postal_Name_Suffix 4 ( 3) bill to street line1 Ecom_BillTo_Postal_Street_Line1 20 ( 4) bill to street line2 Ecom_BillTo_Postal_Street_Line2 20 ( 4) bill to street line3 Ecom_BillTo_Postal_Street_Line3 20 ( 4) bill to city Ecom_BillTo_Postal_City 22 bill to state/province Ecom_BillTo_Postal_StateProv 2 ( 5) bill to zip/postal code Ecom_BillTo_Postal_PostalCode 14 ( 6) bill to country Ecom_BillTo_Postal_CountryCode 2 ( 7) bill to phone Ecom_BillTo_Telecom_Phone_Number 10 ( 8) bill to email Ecom_BillTo_Online_Email 40 ( 9)
最初の名前に紙幣がミドルネームEcom_BillTo_Postal_Name_Middle 15紙幣をEcom_BillTo_Postal_Name_First紙幣タイトルにEcom_BillTo_Postal_Name_Prefix 4は、（1）15（2）姓の紙幣通りLINE1 Ecom_BillTo_Postal_Street_Line1 20通り〜（4）紙幣の名前サフィックスEcom_BillTo_Postal_Name_Suffix 4（3）紙幣15紙幣をEcom_BillTo_Postal_Name_Last LINE2 Ecom_BillTo_Postal_Street_Line2 20（4）紙幣ストリートLINE3 Ecom_BillTo_Postal_Street_Line3 20都市Ecom_BillTo_Postal_City〜（4）紙幣/郵便Ecom_BillTo_Postal_PostalCode 14（6）紙幣国Ecom_BillTo_Postal_CountryCode 2（7）請求書に圧縮する州/県Ecom_BillTo_Postal_StateProv 2（5）紙幣22の紙幣へ電話Ecom_BillTo_Telecom_Phone_Number 10 Ecom_BillTo_Online_Email 40（9）を電子メールで送信する（8）法案へ
receiptTo title Ecom_ReceiptTo_Postal_Name_Prefix 4 ( 1) receiptTo first name Ecom_ReceiptTo_Postal_Name_First 15 receiptTo middle name Ecom_ReceiptTo_Postal_Name_Middle 15 ( 2) receiptTo last name Ecom_ReceiptTo_Postal_Name_Last 15 receiptTo name suffix Ecom_ReceiptTo_Postal_Name_Suffix 4 ( 3) receiptTo street line1 Ecom_ReceiptTo_Postal_Street_Line1 20 ( 4) receiptTo street line2 Ecom_ReceiptTo_Postal_Street_Line2 20 ( 4) receiptTo street line3 Ecom_ReceiptTo_Postal_Street_Line3 20 ( 4) receiptTo city Ecom_ReceiptTo_Postal_City 22 receiptTo state/province Ecom_ReceiptTo_Postal_StateProv 2 ( 5) receiptTo postal code Ecom_ReceiptTo_Postal_PostalCode 14 ( 6) receiptTo country Ecom_ReceiptTo_Postal_CountryCode 2 ( 7) receiptTo phone Ecom_ReceiptTo_Telecom_Phone_Number 10 ( 8) receiptTo email Ecom_ReceiptTo_Online_Email 40 ( 9)
receiptToタイトルEcom_ReceiptTo_Postal_Name_Prefix 4は、（1）第一の名前をreceiptTo 15 receiptToミドルネームをEcom_ReceiptTo_Postal_Name_First Ecom_ReceiptTo_Postal_Name_Middle 15（2）receiptTo姓15 receiptTo名サフィックスEcom_ReceiptTo_Postal_Name_Suffix 4（3）receiptTo通りLINE1 Ecom_ReceiptTo_Postal_Street_Line1 20（4）receiptTo通りLINE2 Ecom_ReceiptTo_Postal_Street_Line2 20（4）receiptToをEcom_ReceiptTo_Postal_Name_LastストリートLINE3 Ecom_ReceiptTo_Postal_Street_Line3 20（4）receiptTo市内Ecom_ReceiptTo_Postal_City 22 receiptToの州/県Ecom_ReceiptTo_Postal_StateProv 2（5）receiptTo郵便Ecom_ReceiptTo_Postal_PostalCode 14（6）receiptTo国Ecom_ReceiptTo_Postal_CountryCode 2（7）receiptTo電話Ecom_ReceiptTo_Telecom_Phone_Number 10（8）receiptTo電子メールEcom_ReceiptTo_Online_Email 40（9）
name on card Ecom_Payment_Card_Name 30 (10)
カードEcom_Payment_Card_Name 30（10）に名前を付けます
card type Ecom_Payment_Card_Type 4 (11) card number Ecom_Payment_Card_Number 19 (12) card verification value Ecom_Payment_Card_Verification 4 (13)
カード型Ecom_Payment_Card_Type 4（11）カード番号Ecom_Payment_Card_Number 19（12）カード検証値Ecom_Payment_Card_Verification 4（13）
card expire date day Ecom_Payment_Card_ExpDate_Day 2 (14) card expire date month Ecom_Payment_Card_ExpDate_Month 2 (15) card expire date year Ecom_Payment_Card_ExpDate_Year 4 (16)
カードは、日付の月のEcom_Payment_Card_ExpDate_Month 2（15）カード有効期限が切れる日付年Ecom_Payment_Card_ExpDate_Year 4（16）2（14）カードの有効期限が切れる日付の日のEcom_Payment_Card_ExpDate_Dayを期限切れ
card protocols Ecom_Payment_Card_Protocol 20 (17)
カードプロトコルEcom_Payment_Card_Protocol 20（17）
consumer order ID Ecom_ConsumerOrderID 20 (18)
消費者の注文ID Ecom_ConsumerOrderID 20（18）
schema version Ecom_SchemaVersion 30 (19)
スキーマバージョンEcom_SchemaVersion 30（19）
end transaction flag Ecom_TransactionComplete - (20)
エンドトランザクションフラグEcom_TransactionComplete - （20）
FIELD NAME Min Notes
フィールド名ミンノート
IMPORTANT NOTE: "MIN" in the table above is the MINIMUM DATA SIZE TO ALLOW FOR ON DATA ENTRY. It is NOT the minimum size for valid contents of the field and merchant software should, in most cases, be prepared to receive a longer or shorter value. Merchant dealing with areas where, for example, the state/province name or phone number is longer than the "Min" given below must obviously permit longer data entry. In some cases, however, there is a maximum size that makes sense and this is documented in a Note for the field.
重要な注意：上記の表の「MIN」はONデータ入力を可能にするための最小データサイズです。これは、有効なフィールドの内容と商人のソフトウェアの最小サイズは、ほとんどの場合、長いか短い値を受け取るように準備されるべきではありません。分野を扱う商人はどこ、例えば、州/地方名や電話番号が明らかになりましデータ入力を許可する必要があります下記の「分」よりも長くなっています。いくつかのケースでは、しかし、理にかなって最大サイズがあり、これはフィールドの注記に記載されています。
( 1) For example: Mr., Mrs., Ms., Dr. This field is commonly not used.
（1）例えば：ミスター、ミセス、さん、博士は、このフィールドは一般的に使用されていません。
( 2) May also be used for middle initial
（2）また、ミドルネームのイニシャルのために使用することができます
( 3) For example: Ph.D., Jr. (Junior), 3rd, Esq. (Esquire). This field is commonly not used.
（3）例えば：博士、ジュニア（ジュニア）、3、ESQ。 （エスクァイア）。このフィールドは、一般的に使用されていません。
( 4) Address lines must be filled in the order line1, then line2, last line3.
（4）アドレスラインは、次にLINE2、LINE3最後、注文LINE1に充填されなければなりません。
( 5) 2 characters are the minimum for the US and Canada, other countries may require longer fields. For the US use 2 character US Postal state abbreviation.
（5）2つの文字は、米国およびカナダのための最小値は、他の国は長いフィールドが必要な場合があります。私たちのために2文字の米国郵便状態の略語を使用します。
( 6) Minimum field lengths for Postal Code will vary based on international market served. Use 5 character or 5+4 ZIP for the US and 6 character postal code for Canada. The size given, 14, is believed to be the maximum required anywhere in the world.
（6）郵便番号の最小フィールド長は、国際市場によって異なります務めました。 5文字またはカナダのために5 + 4米国のためのZIPおよび6文字の郵便番号を使用してください。サイズ与えられ、14は、世界のどこにでも必要な最大であると考えられています。
( 7) Use [ISO 3166] standard two letter codes <http://www.din.de/gremien/nas/nabd/iso3166ma/codlstp1.html> for country names.
（7）国名に[ISO 3166]標準的な2つの文字のコード<http://www.din.de/gremien/nas/nabd/iso3166ma/codlstp1.html>を使用してください。
( 8) 10 digits are the minimum for numbers local to the North American Numbering Plan (<http://www.nanpa.com>: US, Canada and a number of smaller Caribbean and Pacific nations (but not Cuba)), other countries may require longer fields. Telephone numbers are complicated by differing international access codes, variant punctuation of area/city codes within countries, confusion caused by the fact that the international access code in the NANP region is usually the same as the "country code" for that area (1), etc. It will probably be necessary to use heuristics or human examination based on the telephone number and addresses given to figure out how to actually call a customer. It is recommend that an "x" be placed before extension numbers.
、その他：（8）10桁の数字は、北米番号計画（米国、カナダ、小さなカリブ海と太平洋諸国の数（ただしキューバ）<http://www.nanpa.com>）へのローカル番号の最小値です国は、長いフィールドが必要な場合があります。電話番号は、NANP地域の国際アクセスコードは、通常、そのエリアの「国コード」（1）と同じであることに起因国際アクセスコード、国内のエリア/都市コードのバリアント句読点、混乱が異なることにより、複雑さなどおそらく、実際に顧客を呼び出す方法を把握するために与えられた電話番号とアドレスに基づいて、経験則や人間の検査を使用する必要があります。 「x」は、内線番号の前に配置することをお勧めします。
( 9) For example: jsmith@example.com
（9）例えば：jsmith@example.com
(10) The name of the cardholder.
（10）カード所有者の名前。
(11) Use the first 4 letters of the association name: American Express=AMER; Diners Club=DINE; Discover=DISC; JCB=JCB; Mastercard=MAST; Visa=VISA.
（11）関連の名前の最初の4つの文字を使用：アメリカンエクスプレス= AMERと、ダイナースクラブ= DINE。 = DISC発見。 JCB = JCB;マスター= MAST。ビザ= VISA。
(12) Includes the check digit at end but no spaces or hyphens [ISO 7812]. The Min given, 19, is the longest number permitted under the ISO standard.
（12）は、最後にチェックデジットが含まれていますが、スペースやハイフン[ISO 7812]。与えられた分、19は、ISO規格の下で認め最長の数です。
(13) An additional cardholder verification number printed on the card (but not embossed or recorded on the magnetic stripe) such as American Express' CIV, MasterCard's CVC2, and Visa's CVV2 values.
（13）追加のカード保有者検証番号は、アメリカン・エキスプレスCIV、MasterCardのCVC2、およびVisaのCVV2値としてカードに印刷（しかし、エンボス加工や磁気ストライプに記録されていません）。
(14) The day of the month. Values: 1-31
（14）月の日。値：1-31
(15) The month of the year. Jan - 1, Feb - 2, March - 3, etc.; Values: 1-12
（15）年の月。月 - 1、2月 - 2年3月 - 3、など。値：1-12
(16) The value in the wallet cell is always four digits, e.g., 1999, 2000, 2001, ...
ウォレット・セル（16）の値は常に4桁、例えば、1999、2000、2001、...
(17) A space separated list of protocols available in connection with the specified card. Initial list of case insensitive tokens: none, set, & setcert. "Set" indicates usable with SET protocol (i.e., is in a SET wallet) but does not have a SET certificate. "Setcert" indicates same but does have a set certificate. "None" indicates that automatic field fill is operating but there is no SET wallet or the card is not entered in any SET wallet.
（17）空間は、指定されたカードに関連して利用可能なプロトコルのリストを分離しました。大文字小文字を区別しないトークンの初期リスト：なし、セット、＆setcert。 「設定」SETプロトコル（すなわち、SET財布にある）と共に使用可能示すが、SET証明書を有していません。 「Setcertは」同じ示したが、設定された証明書を持っています。 「なし」自動フィールドの塗りつぶしが動作していることを示していないが、財布やカードがいずれかのSETウォレットに入力されていない何のSETはありません。
(18) A unique order ID generated by the consumer software.
（18）消費者のソフトウェアによって生成された一意の注文ID。
(19) URI indicating version of this set of fields. Usually a hidden field. Equal to "http://www.ecml.org/version/1.0" for this version.
（19）URIフィールドのこのセットのバージョンを示します。通常は隠しフィールド。このバージョンの「http://www.ecml.org/version/1.0」に等しいです。
(20) A flag to indicate that this web-page/aggregate is the final one for this transaction. Usually a hidden field.
（20）このウェブページ/集合体がこのトランザクションの最終的なものであることを示すフラグ。通常は隠しフィールド。
The information called for by many of these fields is sensitive and should be protected if being sent over the public Internet or through other channels where it can be observed. Mechanisms for such protection are not specified herein but channel encryption such as SSL/TLS [RFC 2246] or IPSec [RFC 2411] would be appropriate in many cases.
これらのフィールドの多くによって要求される情報には敏感であり、公共のインターネットまたはそれを観察することができる他のチャンネルを介して送信された場合に保護されなければなりません。このような保護のメカニズムは、ここで指定されていないが、チャネルの暗号化など、SSL / TLS [RFC 2246]またはIPSec [RFC 2411]のように、多くの場合に適切であろう。
User control over release of such information is needed to protect the user's privacy.
そのような情報のリリースを超えるユーザーコントロールは、ユーザーのプライバシーを保護するために必要とされます。
Any multi-web-page or other multi-aggregate field fill in or data provision mechanism should check for the Ecom_TransactionComplete field and cease automated fill when it is encountered until fill is further authorized.
またはデータ提供メカニズムにおける任意のマルチウェブページまたは他のマルチ集計フィールドの塗りつぶしはEcom_TransactionCompleteフィールドをチェックし、塗りつぶしがさらに認可されるまでに遭遇したとき、自動塗りつぶしを中止すべきです。
References
リファレンス
ISO 3166 - Codes for the representation of names of countries, <http://www.din.de/gremien/nas/nabd/iso3166ma>
ISO 3166 - 国の名前の表現のためのコード、<http://www.din.de/gremien/nas/nabd/iso3166ma>
ISO 7812 - Identification card - Identification of issuers - Part 1: Numbering system
ISO 7812 - 識別カード - 発行者の識別 - パート1：ナンバリングシステム
HTTP4.0 - HTML 4.0 Specification, <http://www.w3.org/TR/REC-html40>
HTTP4.0 - HTML 4.0仕様、<http://www.w3.org/TR/REC-html40>
RFC 2026 - Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
RFC 2026 - ブラドナーの、S.、 "インターネット標準化プロセス - リビジョン3"、BCP 9、RFC 2026、1996年10月。
RFC 2246 - Dierks, T. and C. Allen, "The TLS Protocol: Version 1.0", RFC 2246, January 1999.
RFC 2246 - ダークス、T.とC.アレン、 "TLSプロトコル：バージョン1.0"、RFC 2246、1999年1月。
RFC 2411 - Thayer, R., Doraswany, N. and R. Glenn, "IP Security: Document Roadmap", RFC 2411, November 1998.
RFC 2411 - セイヤー、R.、Doraswany、N.とR.グレン、 "IPセキュリティ：ドキュメントロードマップ"、RFC 2411、1998年11月。
IOTP - Internet Open Trading Protocol, being specified in the IETF TRADE working group, D. Burdett
IOTP - インターネットオープン取引プロトコルは、IETF TRADEワーキンググループ、D.バーデットで指定されています
SET - Secure Electronic Transaction, <http://www.setco.org/set_specifications.html>
SET - セキュアな電子取引、<http://www.setco.org/set_specifications.html>
XML - Extensible Markup Language (XML) 1.0, <http://www.w3.org/TR/1998/REC-xml-19980210>, T. Bray, J. Paoli, C. M. Sperberg-McQueen
XML - 拡張マークアップ言語（XML）1.0 <http://www.w3.org/TR/1998/REC-xml-19980210>、T.ブレイ、J.パオリ、C. M. Sperberg-マックイーン
Authors' Addresses
著者のアドレス
Donald E. Eastlake, 3rd IBM, J1-N63 17 Skyline Drive Hawthorne, NY 10532 USA
ドナルドE.イーストレイク、第三IBM、J1-N63 17スカイラインドライブホーソーン、NY 10532 USA
Phone: +1-914-784-7913 Fax: +1-914-784-3833 EMail: dee3@us.ibm.com
電話：+ 1-914-784-7913ファックス：+ 1-914-784-3833 Eメール：dee3@us.ibm.com
Ted Goldstein Brodia Networks, Inc. 221 Main Street, Suite 1530 San Francisco, CA 94105 USA
テッド・ゴールドスタインBrodiaネットワークス株式会社221メインストリート、スイート1530、サンフランシスコ、CA 94105 USA
Phone: +1 415-495-3100 x222 Fax: +1 415-495-3177 EMail: tgoldstein@brodia.com
電話：+1 415-495-3100 x222ファックス：+1 415-495-3177電子メール：tgoldstein@brodia.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。