[要約] RFC 3106は、ECML v1.1のフィールド仕様に関する情報を提供します。このRFCの目的は、電子商取引におけるデータフィールドの一貫性と相互運用性を確保することです。
Network Working Group D. Eastlake
Request for Comments: 3106 Motorola
Obsoletes: 2706 T. Goldstein
Category: Informational Brodia
April 2001
ECML v1.1: Field Specifications for E-Commerce
ECML V1.1：電子商取引のフィールド仕様
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 (2001). All Rights Reserved.
Copyright（c）The Internet Society（2001）。無断転載を禁じます。
IESG Note:
IESGノート：
This document specifies version 1.1 of ECML and obsoletes RFC 2706 which specifies version 1.0 of ECML. Both version 1.0 and 1.1 of ECML are products of the ECML alliance which is described in section 1.1 of this document. The reader should note that version 2.0 of ECML is under development (as of the publication of this RFC) in the IETF in the TRADE Working Group.
このドキュメントは、ECMLのバージョンRFC 2706のバージョン1.1とECMLのバージョン1.0を指定します。ECMLのバージョン1.0と1.1の両方は、このドキュメントのセクション1.1で説明されているECMLアライアンスの製品です。読者は、ECMLのバージョン2.0が（このRFCの公開時点で）貿易ワーキンググループの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. In addition, some fields are defined for merchant to consumer communication.
顧客は、特に初めてそこに行くときに、購入またはその他の取引を完了するために、インターネットマーチャントサイトにかなりの量の情報を入力することが頻繁に必要です。情報フィールドの標準セットは、電子コマースモデリング言語（ECML）の最初のバージョンとして定義されているため、このタスクは、フィールドを埋めることができるウォレットソフトウェアなど、より簡単に自動化できます。手動のデータ入力ケースであっても、かなりの数がこれらの標準フィールドを採用している場合、顧客はさまざまな商人サイトであまり混乱しません。さらに、一部の分野は、商人から消費者コミュニケーションのために定義されています。
Acknowledgements
謝辞
The following persons, in alphabetic order, contributed substantially to the material herein:
次の人は、アルファベットの順序で、ここでの資料に実質的に貢献しました。
George Burne Joe Coco Jon Parsons James Salsman David Shepherd Kevin Weller
ジョージ・バーン・ジョー・ココ・ジョン・パーソンズジェームズ・サルスマン・デイビッド・シェパード・ケビン・ウェラー
Table of Contents
目次
1. Introduction.................................................. 2
1.1 The ECML Alliance............................................ 3
1.2 Relationship to Other Standards.............................. 4
1.3 Areas Deferred to Future Versions............................ 4
2. Field Definitions and DTD..................................... 4
2.1 Field List and Descriptions.................................. 4
2.1.1 Field List................................................. 5
2.1.2 Field Foot Notes........................................... 7
2.2 Use in HTML.................................................. 10
2.3 An ECML 1.1 XML DTD.......................................... 11
3. Using The Fields.............................................. 13
3.1 Presentation of the Fields................................... 13
3.2 Methods and Flow of Setting the Fields....................... 14
3.3 HTML Example................................................ 14
4. Security and Privacy Considerations........................... 16
References....................................................... 16
Appendix: Changes from ECML 1.0.................................. 18
Authors' Addresses............................................... 19
Full Copyright Statement......................................... 20
Today, numerous merchants are successfully conducting business on the Internet using HTML-based forms. The data formats used in these forms vary 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ベースのフォームを使用してインターネット上でビジネスを成功裏に行っています。これらの形式で使用されるデータ形式は、商人によって大幅に異なります。エンドユーザーは、多様性が混乱し、これらの形を手動で埋めるプロセスが退屈であると感じています。その結果、約3分の2の約3分の2が埋め込まれている間に放棄された多くの商人形態が発生します。
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 think about and complete a merchant's form every time. Digital wallets that fill forms have been successfully built into browsers, as proxy servers, 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>) 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（Electronic Commerce Modeling Language、<www.ecml.org>）は、複数のベンダーからの電子ウォレットがWebフォームに記入できるようにするWebマーチャント向けの一連の簡単なガイドラインを提供します。最終的なことは、より多くの消費者がウェブ上の買い物を簡単で説得力があると感じるということです。
Version 1.1 has been enhanced over Version 1.0 [RFC 2706] as described in the appendix to this document. These enhancements include support for communication from the merchant to the wallet. This information can be used by the wallet to present transaction information and possibly signed receipts. The format of the signatures for receipts is not specified in this document.
このドキュメントの付録に記載されているように、バージョン1.1はバージョン1.0 [RFC 2706]で強化されました。これらの機能強化には、商人から財布へのコミュニケーションへのサポートが含まれます。この情報は、ウォレットによってトランザクション情報を提示し、署名された領収書を提示するために使用できます。領収書の署名の形式は、このドキュメントでは指定されていません。
Multiple wallets and multiple merchants interoperably support ECML. This is an open standard. ECML is designed to be simple. Neither Version 1.0 nor Version 1.1 of the project add new technology to the web. A merchant can adopt ECML and gain the support of these multiple Wallets by making very simple changes to their site. Use of ECML requires no license.
複数のウォレットと複数の商人がECMLを相互にサポートします。これはオープン標準です。ECMLはシンプルになるように設計されています。プロジェクトのバージョン1.0もバージョン1.1もWebに新しいテクノロジーを追加しません。商人は、ECMLを採用し、サイトに非常に簡単な変更を加えることで、これらの複数の財布のサポートを獲得できます。ECMLの使用には、ライセンスが必要ありません。
The set of fields documented herein was developed by the ECML Alliance (www.ecml.org) which now includes, in alphabetic order, the fifteen Steering Committee members listed below and numerous General Members some of whom are listed on the ECML web site.
本明細書に文書化された一連のフィールドは、ECML Alliance（www.ecml.org）によって開発されました。これには、以下にリストされている15人の運営委員会メンバーが含まれ、その一部はECML Webサイトにリストされている多くの一般メンバーが含まれています。
1. American Express (www.americanexpress.com> 2. AOL (www.aol.com) 3. Brodia (www.brodia.com) 4. Compaq (www.compaq.com) 5. CyberCash (www.cybercash.com) 6. Discover (www.discovercard.com) 7. FSTC (www.fstc.org) 8. IBM (www.ibm.com) 9. Mastercard (www.mastercard.com) 10. Microsoft (www.microsoft.com) 11. Novell (www.novell.com> 12. SETCo (www.setco.org) 13. Sun Microsystems (www.sun.com) 14. Trintech (www.trintech.com> 15. Visa International (www.visa.com)
1. American Express（www.americanexpress.com> 2. AOL（www.aol.com）3。Brodia（www.brodia.com）4。Compaq（www.compaq.com）5。Cybercash（www.cybercash.com）6。発見（www.discovercard.com）7。fstc（www.fstc.org）8。ibm（www.ibm.com）9。mastercard（www.mastercard.com）10。Microsoft（www.microsoft.com）11。Novell（www.novell.com> 12. Setco（www.setco.org）13。Sun Microsystems（www.sun.com）14。Trintech（www.trintech.com> 15. Visa International（www.visaa.com）
The ECML fields were initially derived from and are consistent with the W3C P3P base data schema at
ECMLフィールドは最初に由来し、W3C P3Pベースデータスキーマと一致しています
<http://www.w3.org/TR/WD-P3P/basedata.html>.
<http://www.w3.org/tr/wd-p3p/basedata.html>。
ECML Version 1.1 is not a replacement or alternative to SSL/TLS [RFC 2246], SET [SET], XML [XML], or IOTP [RFC 2801]. These are important standards that provide functionality such as non-repudiatable transactions, automatable payment scheme selection, and smart card support.
ECMLバージョン1.1は、SSL/TLS [RFC 2246]、SET [SET]、XML [XML]、またはIOTP [RFC 2801]の代替または代替ではありません。これらは、繰り返し不可能なトランザクション、自動化可能な支払いスキーム選択、スマートカードサポートなどの機能を提供する重要な標準です。
ECML may be used with any payment mechanism. It simply allows a merchant to publish consistent simple web forms. Information on the use of the ECML fields with W3C P3P protocol is available at <http://www.w3.org/TR/P3P-for-ecommerce> which also includes some proposed extension fields. These extension fields may be included in a future version of ECML.
ECMLは、任意の支払いメカニズムとともに使用できます。単に、商人が一貫したシンプルなWebフォームを公開することを可能にします。W3C P3Pプロトコルを使用したECMLフィールドの使用に関する情報は、いくつかの提案された拡張フィールドも含まれる<http://www.w3.org/tr/p3p-for-ecommerce>で入手できます。これらの拡張フィールドは、ECMLの将来のバージョンに含まれる場合があります。
Considerations for business purchasing cards, non-card payment mechanisms, wallet activation, privacy related mechanisms, additional payment mechanisms, currency exchange, and any sort of "negotiation" were among the areas deferred to consideration in future versions. Hidden or other special fields were minimized.
事業購入カード、非カード支払いメカニズム、財布のアクティベーション、プライバシー関連メカニズム、追加の支払いメカニズム、通貨交換、およびあらゆる種類の「交渉」に関する考慮事項は、将来のバージョンで考慮される分野の1つでした。隠されたまたは他の特別なフィールドが最小化されました。
The ECML Standard is primarily the definition and naming of fields. These fields can be encoded in a variety of syntaxes and protocols.
ECML標準は、主にフィールドの定義と命名です。これらのフィールドは、さまざまな構文とプロトコルでエンコードできます。
Section 2.1 below lists and describes the fields, Section 2.2 gives additional notes on HTML usage of the fields, and Section 2.3 provides an XML DTD for use with the fields.
以下のセクション2.1には、フィールドをリストおよび説明し、セクション2.2にフィールドのHTML使用に関する追加のメモを示し、セクション2.3はフィールドで使用するXML DTDを提供します。
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 data 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 labeling, marshalling, unmarshalling of the components of such aggregates depends on the data transfer protocol used.
フィールドは、許可する最小データ入力サイズとともに以下にリストされています。これらのフィールドは、埋め込まれたアンダースコア（ "_"）文字で示されるように、階層的に整理されていることに注意してください。適切なデータ送信メカニズムは、これを使用してecom_payment_card_expdateなどの集約を要求して送信して、すべての日付コンポーネントまたはecom_shipを網羅して、消費者が提供するコンポーネントにすべての船を含めることができます。このような凝集体のコンポーネントのラベル、マーシャリング、非群れは、使用されるデータ転送プロトコルに依存します。
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.
重要な注意：以下の表の「最小」は、データ入力を可能にする最小データサイズです。フィールドの有効なコンテンツの最小サイズではなく、ほとんどの場合、より長いまたはより短い値を受け取るように準備する必要があります。たとえば、州/州の名前または電話番号が「最小」よりも長い領域を扱う商人は、明らかに長いデータ入力を可能にする必要があります。ただし、場合によっては、理にかなっている最大サイズがあり、これが当てはまる場合、フィールドのメモに文書化されています。
The following fields are used to communicate from the customer to the merchant:
次のフィールドは、顧客から商人への通信に使用されます。
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 company name Ecom_ShipTo_Postal_Company 20
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)
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 company name Ecom_BillTo_Postal_Company 20
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)
receipt to (32)
receipt to title Ecom_ReceiptTo_Postal_Name_Prefix 4 ( 1)
receipt to first name Ecom_ReceiptTo_Postal_Name_First 15
receipt to middle name Ecom_ReceiptTo_Postal_Name_Middle 15 ( 2)
receipt to last name Ecom_ReceiptTo_Postal_Name_Last 15
receipt to name suffix Ecom_ReceiptTo_Postal_Name_Suffix 4 ( 3)
receipt to company name Ecom_ReceiptTo_Postal_Company 20
receipt to street line1 Ecom_ReceiptTo_Postal_Street_Line1 20 ( 4)
receipt to street line2 Ecom_ReceiptTo_Postal_Street_Line2 20 ( 4)
receipt to street line3 Ecom_ReceiptTo_Postal_Street_Line3 20 ( 4)
receipt to city Ecom_ReceiptTo_Postal_City 22
receipt to state/province Ecom_ReceiptTo_Postal_StateProv 2 ( 5)
receipt to postal code Ecom_ReceiptTo_Postal_PostalCode 14 ( 6)
receipt to country Ecom_ReceiptTo_Postal_CountryCode 2 ( 7)
receipt to phone Ecom_ReceiptTo_Telecom_Phone_Number 10 ( 8)
receipt to email Ecom_ReceiptTo_Online_Email 40 ( 9)
name on card 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)
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)
card protocols Ecom_Payment_Card_Protocol 20 (17)
consumer order ID Ecom_ConsumerOrderID 20 (18)
消費者注文IDECOM_CONSUMERORDERID 20（18）
user ID Ecom_User_ID 40 (19)
user password Ecom_User_Password 20 (19)
schema version Ecom_SchemaVersion 30 (20)
wallet id Ecom_WalletID 40 (21)
end transaction flag Ecom_TransactionComplete - (22)The following fields are used to communicate from the merchant to the consumer:
エンドトランザクションフラグecom_transactioncomplete-（22）次のフィールドは、商人から消費者への通信に使用されます。
FIELD NAME Min Notes
merchant home domain Ecom_Merchant 128 (23)
processor home domain Ecom_Processor 128 (24)
transaction identifier Ecom_Transaction_ID 128 (25)
transaction URL inquiry Ecom_Transaction_Inquiry 500 (26)
transaction amount Ecom_Transaction_Amount 128 (27)
transaction currency Ecom_Transaction_CurrencyCode 3 (28)
transaction date Ecom_Transaction_Date 80 (29)
transaction type Ecom_Transaction_Type 40 (30)
transaction signature Ecom_Transaction_Signature 160 (31)
end transaction flag Ecom_TransactionComplete - (22)
エンドトランザクションフラグecom_transactioncomplete-（22）
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.
重要な注意：上記の表の「最小」は、データ入力を可能にする最小データサイズです。フィールドの有効なコンテンツの最小サイズではなく、ほとんどの場合、より長いまたはより短い値を受け取るように準備する必要があります。たとえば、州/州の名前または電話番号が「最小」よりも長い領域を扱う商人は、明らかに長いデータ入力を可能にする必要があります。ただし、場合によっては、理にかなった最大サイズがあり、これはフィールドのメモに文書化されています。
( 1) For example: Mr., Mrs., Ms., Dr. This field is commonly not used.
（1）たとえば、ミスター、ミセス、Ms、博士、この分野は一般的には使用されていません。
( 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）例：Ph.D.、Jr。（ジュニア）、3番目、Esq。（エスクイア）。このフィールドは一般的に使用されていません。
( 4) Address lines must be filled in the order line1, then line2, and last line3.
（4）アドレスラインは、次にline2、および最後のline3に記入する必要があります。
( 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個の郵便番号を使用し、カナダには6文字の郵便番号を使用します。指定されたサイズ、14は、世界のどこでも最大で必要な最大であると考えられています。
( 7) Use [ISO 3166] standard two letter codes. See <http://www.din.de/gremien/nas/nabd/iso3166ma/index.html> for country names.
（7）[ISO 3166]標準の2文字コードを使用します。<http://www.din.de/gremien/nas/nabd/iso3166ma/index.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:
（11）協会名の最初の4文字を使用します。
AMER American Express BANK Bankcard (Australia) DC DC (Japan) DINE Diners Club DISC Discover JCB JCB MAST Mastercard NIKO Nikos (Japan) SAIS Saison (Japan) UC UC (Japan) UCAR UCard (Taiwan) VISA Visa
Amer American Express BankCard（Australia）DC DC（日本）Dine Diners Club Disc Discover JCB JCB Mast MasterCard Niko Nikos（Japan）Sais Saison（日本）UC UC（日本）UCAR UCARD（TAIWAN）VISA 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）American ExpressのCiv、MasterCardのCVC2、VisaのCVV2値など、カードに印刷された追加のカード所有者検証番号（磁気ストライプにエンボスまたは記録されていません）。
(14) The day of the month. Values: 1-31. A leading zero is ignored so, for example, 07 is valid for the seventh day of the month.
（14）月の日。値：1-31。主要なゼロは無視されるため、たとえば、07は月の7日目に有効です。
(15) The month of the year. Jan - 1, Feb - 2, March - 3, etc.; Values: 1-12. A leading zero is ignored so, for example, 07 is valid for July.
（15）今年の月。1月 - 2月1日 - 3月2日 - 3など。値：1-12。先行ゼロは無視されるため、たとえば07は7月に有効です。
(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:
（17）指定されたカードに関連して利用可能なプロトコルのスペース分離リスト。ケースの鈍感なトークンの初期リスト：
none set setcert iotp echeck simcard phoneid
なしsetcert iotp echeck simcard phoneid
"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. "iotp" indicates the IOTP protocol [RFC 2801] is supported at the customer. "echeck" indicates that the eCheck protocol [eCheck] is supported at the customer. "simcard" indicates use the transaction instrument built into a Cellphone subscriber for identification. "phoneid" indicates use the transaction instrument of a phone bill instrument. "None" indicates that automatic field fill is operating but there is no SET wallet or the card is not entered in any SET wallet.
「セット」は、セットプロトコルで使用可能なものを示します（つまり、セットウォレットに含まれています）が、セット証明書はありません。「SetCert」は同じことを示しますが、設定された証明書があります。「IOTP」は、IOTPプロトコル[RFC 2801]が顧客でサポートされていることを示しています。「echeck」は、echeckプロトコル[echeck]が顧客でサポートされていることを示しています。「Simcard」は、識別のために携帯電話サブスクライバーに組み込まれたトランザクション機器を使用することを示します。「PhoneID」は、電話請求書の取引機器を使用することを示しています。「なし」は、自動フィールドフィルが動作していることを示していますが、セットウォレットはなく、カードがセットウォレットに入力されていません。
(18) A unique order ID generated by the consumer software.
（18）消費者ソフトウェアによって生成された一意の注文ID。
(19) The user ID and password fields are used in cases where the user has a pre-established account with the merchant.
（19）ユーザーIDおよびパスワードフィールドは、ユーザーが販売者と事前に確立されたアカウントを持っている場合に使用されます。
(20) URI indicating version of this set of fields. Usually a hidden field. Equal to "http://www.ecml.org/version/1.1" for this version.
（20）このフィールドセットのバージョンを示すURI。通常、隠されたフィールド。このバージョンの「http://www.ecml.org/version/1.1」に等しくなります。
(21) A string to identify the source and version of the form fill software that is acting on behalf of the user. Should contain company and/or product name and version. Example "Wallets Inc., SuperFill, v42.7". Usually a hidden field.
（21）ユーザーに代わって作用しているフォームフィルソフトウェアのソースとバージョンを識別する文字列。会社および/または製品名とバージョンを含める必要があります。例「Wallets Inc.、Superfill、V42.7」。通常、隠されたフィールド。
(22) A flag to indicate that this web-page/aggregate is the final one for this transaction. Usually a hidden field.
（22）このWebページ/集計がこのトランザクションの最終的なものであることを示すフラグ。通常、隠されたフィールド。
(23) Merchant domain name such as www.merchant.example. This is usually a hidden field.
（23）www.merchant.exampleなどの商人ドメイン名。これは通常、隠されたフィールドです。
(24) Gateway transaction processor who is actually accepting the payment on behalf of the merchant in home domain such as www.processor.example. This is usually a hidden field.
（24）www.processor.exampleなどのホームドメインの商人に代わって実際に支払いを受け入れているゲートウェイトランザクションプロセッサ。これは通常、隠されたフィールドです。
(25) A Transaction identification string whose format is specific to the processor. This is usually a hidden field.
（25）形式がプロセッサに固有のトランザクション識別文字列。これは通常、隠されたフィールドです。
(26) A URL that can be invoke to inquire about the transaction. This is usually a hidden field.
（26）トランザクションについて問い合わせるために呼び出すことができるURL。これは通常、隠されたフィールドです。
(27) The amount of the transaction in ISO currency format. This is two integer numbers with a period in between but no other currency marks (such as a $ dollar sign). This is usually a hidden field.
（27）ISO通貨形式のトランザクションの量。これは2つの整数数ですが、その間に期間がありますが、他の通貨マーク（$ Dollar Signなど）はありません。これは通常、隠されたフィールドです。
(28) This is the three letter ISO currency code. For example, for US dollars it is USD. This is usually a hidden field.
（28）これは3文字ISO通貨コードです。たとえば、米ドルの場合は米ドルです。これは通常、隠されたフィールドです。
(29) ISO Transaction date. This is usually a hidden field.
（29）ISOトランザクション日。これは通常、隠されたフィールドです。
(30) The type of the transaction (either debit or credit) if known. This is usually a hidden field.
（30）既知の場合のトランザクション（デビットまたはクレジットのいずれか）のタイプ。これは通常、隠されたフィールドです。
(31) The signature of the encoded certificate. This is usually a hidden field.
（31）エンコードされた証明書の署名。これは通常、隠されたフィールドです。
(32) The Receipt To fields are used when the Bill To entity, location, or address and the Receipto entity, location, or address are different. For example, when using some forms of Corporate Purchasing Cards or Agent Purchasing Cards, the individual card holder would be in the Receipt To fields and the corporate or other owner would be in the Bill To fields.
（32）フィールドへの領収書は、請求書がエンティティ、場所、または住所への請求書、領収書の実体、場所、または住所が異なる場合に使用されます。たとえば、企業の購入カードまたはエージェント購入カードを使用する場合、個々のカード所有者はフィールドへの領収書に載っており、企業または他の所有者はフィールドへの請求書に載っています。
The normal use of ECML in HTML is as a form with input field names identical to those given in section 2.1 above. In general, <INPUT> tags with type text, hidden, and password must be supported as must <SELECT> tags.
HTMLでのECMLの通常の使用は、上記のセクション2.1で与えられたものと同一の入力フィールド名を持つフォームとしてです。一般に、型テキスト、非表示、およびパスワードを備えた<inupt>タグは、<elect>タグと同様にサポートする必要があります。
Internationalization in HTML is limited. The information available with the HTML form Method as to character set and language SHOULD be used.
HTMLの国際化は限られています。文字セットと言語に関するHTMLフォームメソッドで利用可能な情報を使用する必要があります。
Below is an XML DTD that can be used for the XML encoding of ECML v1.1 Fields.
以下は、ECML V1.1フィールドのXMLエンコードに使用できるXML DTDです。
For internationalization of [XML] ECML, use the general XML character encoding provisions, which mandate support of UTF-8 and UTF-16 and permit support of other character sets, and the xml:lang attribute which may be used to specify language information.
[XML] ECMLの国際化には、UTF-8およびUTF-16のサポートを義務付け、他の文字セットのサポートを許可する一般的なXML文字エンコード条項を使用し、言語情報の指定に使用できるXML：Lang属性を使用します。
<!-- Electronic Commerce Modeling Language 1.1 -->
<!ELEMENT Ecom ( #PCDATA | ShipTo | BillTo | ReceiptTo | Payment |
User | Transaction | TransactionComplete )* >
<!ATTLIST Ecom
id ID #IMPLIED
ConsumerOrderID CDATA #IMPLIED
Merchant CDATA #IMPLIED
Processor CDATA #IMPLIED
SchemaVersion ( "http://www.ecml.org/version/1.0" |
"http://www.ecml.org/version/1.1" )
#IMPLIED
WalletID CDATA #IMPLIED >
<!ELEMENT ShipTo ( #PCDATA | Postal | Telecom | Online )* >
<!ATTLIST ShipTo
id ID #IMPLIED >
<!ELEMENT BillTo ( #PCDATA | Postal | Telecom | Online )* >
<!ATTLIST BillTo
id ID #IMPLIED >
<!ELEMENT ReceiptTo ( #PCDATA | Postal | Telecom | Online )* >
<!ATTLIST ReceiptTo
id ID #IMPLIED >
<!ELEMENT Postal ( #PCDATA | Name | Company |
Street | City | StateProv )* >
<!ATTLIST Postal
id ID #IMPLIED
PostalCode NMTOKEN #IMPLIED
CountryCode NMTOKEN #IMPLIED >
<!ELEMENT Name EMPTY >
<!ATTLIST Name
id ID #IMPLIED
Prefix NMTOKEN #IMPLIED
First NMTOKEN #IMPLIED
Middle NMTOKEN #IMPLIED
Last NMTOKEN #IMPLIED
Suffix NMTOKEN #IMPLIED >
<!ELEMENT Street EMPTY >
<!ATTLIST Street
id ID #IMPLIED
Line1 CDATA #REQUIRED
Line2 CDATA #IMPLIED
Line3 CDATA #IMPLIED >
<!ELEMENT Company #PCDATA >
<!ELEMENT City #PCDATA >
<!ELEMENT StateProv #PCDATA >
<!ELEMENT Telecom ( #PCDATA | Phone )* >
<!ELEMENT Phone EMPTY >
<!ATTLIST Phone
id ID #IMPLIED
Number CDATA #REQUIRED >
<!ELEMENT Online ( #PCDATA | Email )* >
<!ELEMENT Email EMPTY >
<!ATTLIST Email
id ID #IMPLIED
Address CDATA #REQUIRED >
<!ELEMENT Payment Card>
<!ELEMENT Card ExpDate >
<!ATTLIST Card
id ID #IMPLIED
Name CDATA #IMPLIED
Type NMTOKEN #IMPLIED
Number NMTOKEN #REQUIRED
Protocols NMTOKENS #IMPLIED
Verification NMTOKEN #IMPLIED >
<!ELEMENT ExpDate EMPTY >
<!ATTLIST ExpDate
id ID #IMPLIED
Day NMTOKEN #IMPLIED
Month NMTOKEN #REQUIRED
Year NMTOKEN #REQUIRED >
<!ELEMENT User ( #PCDATA | UserID | Password )* >
<!ATTLIST User
id ID #IMPLIED >
<!ELEMENT UserID #PCDATA >
<!ELEMENT Password #PCDATA >
<!ELEMENT Transaction ( #PCDATA | TransactionID | Inquiry |
TransDate | Signature )* >
<!ATTLIST Transaction
id ID #IMPLIED
Amount CDATA #IMPLIED
Currency NMTOKEN #IMPLIED
Type NMTOKEN #IMPLIED >
<!ELEMENT TransactionComplete EMPTY>
To conform to this document, the field names must be structured and named as close to the structure and naming listed in Section 2 above as permitted by the transaction protocol in use. Note: this does not impose any restriction on the user visible labeling of fields, just on their names as used in communication.
このドキュメントに準拠するには、フィールド名を構造化し、使用中のトランザクションプロトコルで許可されているように、上記のセクション2にリストされている構造と命名の近くに指定する必要があります。注：これは、コミュニケーションで使用されている名前だけで、フィールドの可視ラベル付けにユーザーに制限を課すことはありません。
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 interaction or web page, others may ask for parts of the information at different times in multiple interactions or different web 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つのインタラクションまたはWebページで必要な情報を要求する場合があり、他の人は複数のインタラクションまたは異なるWebページで異なる時間に情報の一部を求めることができます。たとえば、以前に情報を「出荷」を要求することが一般的であるため、支払い方法情報の前に送料を計算できます。一部の商人は、要求するすべての情報を提供する必要がある場合があり、他の情報は多くの情報をオプションにすることを要求する場合があります。等。
There is no way with Version 1.0 or 1.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.0または1.1では、商人が必須と考えるフィールドを示す方法はありません。顧客ソフトウェアの観点から見ると、すべてのフィールドは完了するためのオプションです。ただし、販売者は、必要なフィールドが完了していない場合、エラーを発生させるか、情報のリクエストを再提出する場合があります。
It is entirely up to the merchant when and which, if any, of the merchant to consumer fields it presents.
それは完全に商人次第です。
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] form (see section 2.2). Other possibilities are to use the IOTP Authenticate transaction [RFC 2801], an [XML] exchange, or proprietary protocols.
顧客と商人の間には、商人が消費者が提供できる分野を示すことができるさまざまなコミュニケーション方法があります。おそらく、現在展開されているソフトウェアで最も使いやすいのは、[HTML]フォームのフィールドとしてです（セクション2.2を参照）。その他の可能性は、IOTP認証トランザクション[RFC 2801]、[XML]交換、または独自のプロトコルを使用することです。
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. Because some wallets may require user activation, there should be at least one user visible Ecom field on every page with any Ecom fields present that are to be filled in. It is also 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フィールドの外観は、フィールドを埋めることができる施設を開始するために使用できるトリガーの例です。一部のウォレットにはユーザーのアクティベーションが必要になる場合があるため、すべてのページに少なくとも1人のユーザーが表示されるECOMフィールドがあるはずです。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 interactions or 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 interaction or 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 HTML form 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.1">
<br>
<INPUT type="submit" value="submit"> <INPUT type="reset">
</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_Merchant" value="www.merchant.example">
<INPUT type="hidden" name ="Ecom_Processor"
value="www.processor.example">
<INPUT type="hidden" name="Ecom_Transaction_ID" value="EF123456">
<INPUT type="hidden" name="Ecom_Transaction_Inquiry"
value="http://www.merchant.example/cgi-bin/inquire?ID=EF123456">
<INPUT type="hidden" name="Ecom_Transaction_Amount" value="789.00">
<INPUT type="hidden" name="Ecom_Transaction_Currency" value="USD">
<INPUT type="hidden" name="Ecom_Transaction_Date" value="July 14 2000">
<INPUT type="hidden" name="Ecom_Transaction_Type" value="credit">
<INPUT type="hidden" name="Ecom_Transaction_Signature"
value="ig6rh4;;20dfna00s34hj10s--s-45j30-22z92l-frwds-85">
<INPUT type="hidden" name="Ecom_TransactionComplete">
<INPUT type="hidden" name="Ecom_SchemaVersion"
value="http://www.ecml.org/version/1.1">
</FORM>
</BODY>
</HTML>
4. Security and Privacy Considerations
The information called for by many of these fields is sensitive and should be secured 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 TLS/SSL [RFC 2246] or IPSec [RFC 2411] would be appropriate in many cases.
これらのフィールドの多くが求める情報は敏感であり、パブリックインターネットまたはそれが観察できる他のチャネルを介して送信される場合は保護する必要があります。このような保護のメカニズムは本明細書では指定されていませんが、多くの場合、TLS/SSL [RFC 2246]やIPSEC [RFC 2411]などのチャネル暗号化が適切です。
User control over release of such information is needed to protect the user's privacy.
ユーザーのプライバシーを保護するには、そのような情報のリリースをユーザー制御する必要があります。
A wallet that is installed on a shared or public terminal should be configurable such that the ECML memory of address and other contact information is fully disabled. This is vital to protect the privacy of library patrons, students, and customers using public terminals, and children who might, for example, use a form on a public terminal without realizing that their information is being stored.
共有端末またはパブリック端末に取り付けられているウォレットは、アドレスのECMLメモリおよびその他の連絡先情報が完全に無効になるように構成可能である必要があります。これは、図書館の常連客、学生、公開ターミナルを使用している顧客、たとえば情報が保存されていることを認識せずに公開ターミナルでフォームを使用する可能性のある子供のプライバシーを保護するために不可欠です。
When contact information is stored, the operator should have an option to protect the information with a password, without which the information might be unavailable, even to someone who has access to the file(s) in which it is being stored. This would also allow for a convenient method for multiple people to use their own ECML information from the same browser.
連絡先情報が保存されている場合、オペレーターは、保存されているファイルにアクセスできる人にとっても、情報が利用できない可能性があるパスワードで情報を保護するオプションを持つ必要があります。これにより、複数の人が同じブラウザから独自のECML情報を使用する便利な方法が可能になります。
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
参考文献
[eCheck] <http://www.echeck.org>
[HTML] HTML 3.2 Reference Specification <http://www.w3.org/TR/REC-html32.html>, D. Raggett, January 1997.
[HTML] HTML 3.2参照仕様<http://www.w3.org/tr/rec-html32.html>、D。Raggett、1997年1月。
[IANA] Internet Assigned Numbers Authority, Official Names for Character Sets, ed. Keld Simonsen et al. <ftp://ftp.isi.edu/in-notes/iana/assignments/character-sets>.
[IANA]インターネットに割り当てられた数字の権限、キャラクターセットの公式名、編Keld Simonsen等。<ftp://ftp.isi.edu/in-notes/iana/assignments/character-sets>。
[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/iso3166mma>
[ISO 7812] "Identification card - Identification of issuers - Part 1: Numbering system".
[ISO 7812]「識別カード - 発行者の識別 - パート1：番号付けシステム」。
[RFC 1766] Alvestrand, H., "Tags for the Identification of Languages", BCP 47, RFC 3066, January 2001.
[RFC 1766] Alvestrand、H。、「言語の識別のためのタグ」、BCP 47、RFC 3066、2001年1月。
[RFC 2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[RFC 2026] Bradner、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] Dierks、T。およびC. Allen、「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] Thayer、R.、Doraswany、N。and R. Glenn、「IP Security：Document Roadmap」、RFC 2411、1998年11月。
[RFC 2706] Eastlake, D. and T. Goldstein, "ECML v1: Field Names for E-Commerce", RFC 2706, September 1999.
[RFC 2706]イーストレイク、D。およびT.ゴールドスタイン、「ECML V1：eコマースのフィールド名」、RFC 2706、1999年9月。
[RFC 2801] Burdett, D., "Internet Open Trading Protocol - IOTP Version 1.0", RFC 2801, April 2000.
[RFC 2801] Burdett、D。、「インターネットオープントレーディングプロトコル-IOTPバージョン1.0」、RFC 2801、2000年4月。
[SET] Secure Electronic Transaction, <http://www.setco.org/set_specifications.html>
[セット]安全な電子トランザクション、<http://www.setco.org/set_spifications.html>
[XML] Extensible Markup Language (XML) 1.0 (Second Edition), <http://www.w3.org/TR/REC-xml>, T. Bray, J. Paoli, C. M. Sperberg-McQueen, E. Maler.
[XML]拡張可能なマークアップ言語（XML）1.0（第2版）、<http://www.w3.org/tr/rec-xml>、T。Bray、J。Paoli、C。M。Sperberg-Mcqueen、E。Maler。
Appendix: Changes from ECML 1.0
付録：ECML 1.0からの変更
ECML 1.0 is documented in [RFC 2706].
ECML 1.0は[RFC 2706]で文書化されています。
(1) Fields added for consumer to merchant transmission as listed below. * indicated multiple values. Adding fields is a backward compatible change.
(1) 以下にリストされているように、消費者から商人への送信に追加されたフィールド。*複数の値を示します。フィールドを追加することは、後方互換の変更です。
Ecom_*_Postal_Company Ecom_User_ID Ecom_User_Password Ecom_WalletID
ecom _*_ postal_company ecom_user_id ecom_user_password ecom_walletid
(2) Change Ecom_SchemaVersion field value to "http://www.ecml.org/version/1.1".
(2) ecom_schemaversionフィールド値を「http://www.ecml.org/version/1.1」に変更します。
(3) Addition of XML DTD.
(3) XML DTDの追加。
(4) Add "iotp", "echeck", "simcard", and "phoneid" as allowed tokens in Ecom_Payment_Card_Protocol.
(4) ecom_payment_card_protocolで許可されているトークンとして、「iotp」、「echeck」、「simcard」、および「phoneId」を追加します。
(5) Specify that a leading zero is permitted in day and month number fields.
(5) 先日および月数フィールドで主要なゼロが許可されていることを指定します。
(6) Change "Security Considerations" section to "Security and Privacy Considerations" and add material.
(6) 「セキュリティ上の考慮事項」を「セキュリティとプライバシーの考慮事項」に変更し、資料を追加します。
(7) Add internationalization material to HTML and XML subsections of Section 2.
(7) セクション2のHTMLおよびXMLサブセクションに国際化資料を追加します。
(8) Enumerate HTML form elements that must be supported (Section 2.2) including SELECT.
(8) selectを含むサポートする必要があるHTMLフォーム要素（セクション2.2）を列挙します。
(9) Add more credit card brand codes.
(9) クレジットカードブランドコードを追加します。
(10) Add fields for merchant to consumer transmissions as follows:
（10）次のように、マーチャントのフィールドを消費者に送信するためのフィールドを追加します。
Ecom_Merchant Ecom_Processor Ecom_Transaction_*
ecom_merchant ecom_processor ecom_transaction_*
Authors' Addresses
著者のアドレス
Donald E. Eastlake, 3rd Motorola, M2-450 20 Cabot Boulevard Mansfield, MA 02048
ドナルドE.イーストレイク、第3モトローラ、M2-450 20キャボットブルバードマンスフィールド、マサチューセッツ州02048
Phone: +1-508-261-5434
Fax: +1-508-261-4447
EMail: Donald.Eastlake@motorola.com
Ted Goldstein Brodia 221 Main Street, Suite 1530 San Francisco, CA 94105 USA
テッドゴールドスタインブロディア221メインストリート、スイート1530サンフランシスコ、カリフォルニア94105 USA
Phone: +1 415-495-3100 x222
Fax: +1 415-495-3177
EMail: tgoldstein@brodia.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright（c）The Internet Society（2001）。無断転載を禁じます。
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エディター機能の資金は現在、インターネット協会によって提供されています。