RFC 3106 - ECML v1.1: Field Specifications for E-Commerce 日本語訳

URL : https://tools.ietf.org/html/rfc3106
タイトル : RFC 3106 - ECML V1.1：E-Commerceのフィールド仕様
翻訳編集 : 自動生成

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

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.

このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。

著作権表示

著作権（C）インターネット協会（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のバージョン1.1を指定し、ECMLのバージョン1.0を指定するRFC 2706を廃止します。両方のバージョン1.0およびECMLの1.1は、この文書のセクション1.1に記載されているECML提携の製品です。読者はECMLのそのバージョン2.0に注意しなければならないTRADEワーキンググループにおけるIETFにおいて（このRFCの出版物のような）開発中です。

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

1. Introduction

1. はじめに

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ベースのフォームを使用してインターネット上でビジネスを行っています。これらのフォームで使用されるデータ形式は、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 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（電子商取引モデリング言語、<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はプロジェクトのウェブに新しい技術を追加します。商人はECMLを採用し、自分のサイトに非常に単純な変更を加えることにより、これらの複数の財布の支持を得ることができます。 ECMLの使用にはライセンスは必要ありません。

1.1 The ECML Alliance

1.1 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アライアンス（www.ecml.org）によって開発された、15人の運営委員会のメンバーは以下のとおりといくつかの多数の一般的なメンバーはECMLのウェブサイトに記載されています。

             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)

13.サン・マイクロシステムズ（www.sun.com）14 Trintech（www.trintech.com> 15.ビザ・インターナショナル（www.visa.com）

1.2 Relationship to Other Standards

他の標準に1.2の関係

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>.

＜ｈっｔｐ：／／ｗっｗ。ｗ３。おｒｇ／ＴＲ／ＷＤーＰ３Ｐ／ばせだた。ｈｔｍｌ＞。

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]ではありません。これらは、非repudiatable取引、自動化、支払方式選択、およびスマートカードのサポートなどの機能を提供し、重要な規格です。

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の将来のバージョンに含まれていてもよいです。

1.3 Areas Deferred to Future Versions

1.3エリアは、将来のバージョンに延期します

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.

ビジネス購買カード、非カード決済の仕組み、財布の活性化、プライバシー関連のメカニズム、追加の支払いメカニズム、外貨両替、「交渉」の任意の並べ替えのための考慮事項は、将来のバージョンでは考慮に延期エリアの中にありました。隠された、または他の特別なフィールドが最小化されました。

2. Field Definitions and DTD

2.フィールド定義とDTD

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を提供します。

2.1 Field List and Descriptions

2.1フィールドリストと説明

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_ShipToを包含するようEcom_Payment_Card_ExpDateなどの凝集を、送信することができます。標識は、マーシャリングは、そのような凝集体の成分のアンマーシャリングは、使用されるデータ転送プロトコルに依存します。

2.1.1 Field List

2.1.1フィールドリスト

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データ入力を可能にするための最小データサイズです。これは、有効なフィールドの内容と商人のソフトウェアの最小サイズは、ほとんどの場合、長いか短い値を受け取るように準備されるべきではありません。分野を扱う商人はどこ、例えば、州/地方名や電話番号が明らかになりましデータ入力を許可する必要があります下記の「分」よりも長くなっています。いくつかのケースでは、しかし、理にかなっていると、これが事実である場合、それはフィールドの注記に記載されている最大サイズがあります。

         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)

ファーストネームのタイトルEcom_ShipTo_Postal_Name_Prefixに出荷4（1）船は姓Ecom_ShipTo_Postal_Name_Last 4（3）会社名Ecom_ShipTo_Postal_Companyに船20船Ecom_ShipTo_Postal_Street_Line1 20通りのLINE1に名前サフィックスEcom_ShipTo_Postal_Name_Suffix 15船にミドルネームEcom_ShipTo_Postal_Name_Middle 15（2）船に15船をEcom_ShipTo_Postal_Name_First （4）船を通りLINE2 Ecom_ShipTo_Postal_Street_Line2 20（4）船の通りLINE3 Ecom_ShipTo_Postal_Street_Line3 20（4）船の都市Ecom_ShipTo_Postal_City 22船の州/県Ecom_ShipTo_Postal_StateProv 2（5）/郵便番号を圧縮する船は国に14（6）船をEcom_ShipTo_Postal_PostalCode電話Ecom_ShipTo_Telecom_Phone_Number 10（8）船にEcom_ShipTo_Postal_CountryCode 2（7）船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)

最初の名前にタイトルEcom_BillTo_Postal_Name_Prefixに法案4は、（1）法案は姓Ecom_BillTo_Postal_Name_Last 4（3）会社名Ecom_BillTo_Postal_Companyに法案20代Ecom_BillTo_Postal_Street_Line1 20通りのLINE1に名前サフィックスEcom_BillTo_Postal_Name_Suffixに15代のミドルネームEcom_BillTo_Postal_Name_Middle 15（2）請求書に15法案をEcom_BillTo_Postal_Name_FirstストリートLINE2 Ecom_BillTo_Postal_Street_Line2 20ストリートLINE3 Ecom_BillTo_Postal_Street_Line3 20（4）紙幣（4）紙幣（4）国へ/郵便番号Ecom_BillTo_Postal_PostalCode 14（6）紙幣を圧縮するための州/県Ecom_BillTo_Postal_StateProv 2（5）紙幣市内Ecom_BillTo_Postal_Cityに紙幣22紙幣電話Ecom_BillTo_Telecom_Phone_Number 10 Ecom_BillTo_Online_Email 40（9）メール〜（8）紙幣にEcom_BillTo_Postal_CountryCode 2（7）紙幣

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)

表題Ecom_ReceiptTo_Postal_Name_Prefix 4（32）領収書に領収書（1）最初の名前にレシートがミドルネームに15領収書をEcom_ReceiptTo_Postal_Name_FirstはEcom_ReceiptTo_Postal_Name_Middle 15（2）姓のレシートは、会社名Ecom_ReceiptTo_Postal_Companyに名前サフィックスEcom_ReceiptTo_Postal_Name_Suffix 4（3）領収書20領収書15領収書をEcom_ReceiptTo_Postal_Name_LastストリートLINE1 Ecom_ReceiptTo_Postal_Street_Line1 20（4）受領ストリートLINE3 Ecom_ReceiptTo_Postal_Street_Line3 20州/県Ecom_ReceiptTo_Postal_StateProv 2郵便番号Ecom_ReceiptTo_Postal_PostalCode 14（5）受信する（4）都市Ecom_ReceiptTo_Postal_Cityに受領22受信する通りLINE2 Ecom_ReceiptTo_Postal_Street_Line2 20（4）受信する（6） Ecom_ReceiptTo_Online_Email 40を電子メールで送信するために国Ecom_ReceiptTo_Postal_CountryCode 2電話Ecom_ReceiptTo_Telecom_Phone_Number 10（8）受信に（7）領収書に領収書（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) 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_Type 4（11）カード番号Ecom_Payment_Card_Number 19（12）カード検証値Ecom_Payment_Card_Verification 4（13）カード（14）日付日Ecom_Payment_Card_ExpDate_Day 2期限切れカード（15）日付月Ecom_Payment_Card_ExpDate_Month 2期限切れカード（16）日付年Ecom_Payment_Card_ExpDate_Year 4期限切れ

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）

user ID Ecom_User_ID 40 (19) user password Ecom_User_Password 20 (19)

ユーザID Ecom_User_ID 40（19）ユーザパスワードEcom_User_Password 20（19）

schema version Ecom_SchemaVersion 30 (20)

スキーマバージョンEcom_SchemaVersion 30（20）

wallet id Ecom_WalletID 40 (21)

財布のID Ecom_WalletID 40（21）

end transaction flag Ecom_TransactionComplete - (22)

エンドトランザクションフラグEcom_TransactionComplete - （22）

The following fields are used to communicate from the merchant to the consumer:

次のフィールドは、消費者に商人からの通信に使用されています。

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)

商人のホームドメインEcom_Merchant 128（23）、プロセッサホームドメインEcom_Processor 128（24）トランザクション識別子Ecom_Transaction_ID 128（25）トランザクションURL照会Ecom_Transaction_Inquiry 500（26）取引金額Ecom_Transaction_Amount 128（27）取引通貨Ecom_Transaction_CurrencyCode 3（28）取引日のEcom_Transaction_Date 80（ 29）取引タイプEcom_Transaction_Type 40（30）、トランザクション署名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.

重要な注意：上記の表の「MIN」はONデータ入力を可能にするための最小データサイズです。これは、有効なフィールドの内容と商人のソフトウェアの最小サイズは、ほとんどの場合、長いか短い値を受け取るように準備されるべきではありません。分野を扱う商人はどこ、例えば、州/地方名や電話番号が明らかになりましデータ入力を許可する必要があります下記の「分」よりも長くなっています。いくつかのケースでは、しかし、理にかなって最大サイズがあり、これはフィールドの注記に記載されています。

2.1.2 Field Foot Notes

2.1.2フィールドフットノート

( 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, and last line3.

（4）アドレスラインは、注文LINE1およびLINE2、及び最後の行3に充填されなければなりません。

( 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. 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

(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. A leading zero is ignored so, for example, 07 is valid for the seventh day of the month.

（14）月の日。値：1-31。先行ゼロは、たとえば、07月の第七日のために有効なので、無視されます。

(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月 - 2年3月 - 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

"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.

「設定」SETプロトコル（すなわち、SET財布にある）と共に使用可能示すが、SET証明書を有していません。「Setcertは」同じ示したが、設定された証明書を持っています。「IOTP」はIOTPプロトコル[RFC 2801]顧客に支持されていることを示します。「イーチェック」は、イーチェックプロトコル[イーチェック】顧客に支持されていることを示しています。「Simcardのは、」識別のための携帯電話の加入者に組み込まれたトランザクションの楽器を使用して示します。「phoneidなどは、」電話料金計器のトランザクション楽器を使用示します。「なし」自動フィールドの塗りつぶしが動作していることを示していないが、財布やカードがいずれかのSETウォレットに入力されていない何のSETはありません。

(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）ユーザのために機能しているフォーム充填ソフトウェアのソースバージョンを識別するための文字列。会社および/または製品名とバージョンを含める必要があります。例「財布（株）、スーパーフィル、v42.7」。通常は隠しフィールド。

(22) A flag to indicate that this web-page/aggregate is the final one for this transaction. Usually a hidden field.

（22）このウェブページ/集合体がこのトランザクションの最終的なものであることを示すフラグ。通常は隠しフィールド。

(23) Merchant domain name such as www.merchant.example. This is usually a hidden field.

このようwww.merchant.exampleなど（23）マーチャントドメイン名。これは、通常は隠しフィールドです。

(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.

実際に、このようなwww.processor.exampleなどホームドメインに商人に代わって支払いを受け付けている（24）ゲートウェイ・トランザクション・プロセッサ。これは、通常は隠しフィールドです。

(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つの整数です。これは、通常は隠しフィールドです。

(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通貨コードです。例えば、米ドルのためにそれはUSDです。これは、通常は隠しフィールドです。

(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）エンティティ、位置、またはアドレスとReceiptoエンティティ、位置、又はアドレス案が異なる場合にフィールドに領収書が使用されます。企業購買カードまたはエージェントの購買カードのいくつかのフォームを使用している場合たとえば、個々のカードホルダーは、フィールドに領収書になりますし、企業や他の所有者がフィールドにビルにあるであろう。

2.2 Use in HTML

HTML 2.2の使用

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で与えられたものと同一の入力フィールド名を持つフォームの通りです。一般的には、<INPUT>型テキスト、隠された、およびパスワードを使用して、タグは<SELECT>タグを必須としてサポートする必要があります。

Internationalization in HTML is limited. The information available with the HTML form Method as to character set and language SHOULD be used.

HTMLでの国際化には限界があります。文字セットと言語についてのHTMLフォームのメソッドで入手可能な情報を使用する必要があります。

2.3 An ECML 1.1 XML DTD

2.zアンETSML 1.1 CML DTD

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の国際化のために、一般的なXMLの文字エンコーディングに関する規定、UTF-8、UTF-16の任務のサポートを使用し、他の文字セットのサポートを可能とし、XMLは：langは言語情報を指定するために使用することができる属性。

<！ - 電子商取引モデリング言語1.1 - >

<!ELEMENT ShipTo ( #PCDATA | Postal | Telecom | Online )* > <!ATTLIST ShipTo id ID #IMPLIED >

<！ELEMENT shipTo要素（#PCDATA |郵便|テレコム|オンライン）*> <！ATTLIST shipTo要素のID ID #IMPLIED>

<!ELEMENT BillTo ( #PCDATA | Postal | Telecom | Online )* > <!ATTLIST BillTo id ID #IMPLIED >

<！ELEMENT BillTo（#PCDATA |郵便|テレコム|オンライン）*> <！ATTLIST BillTo IDのID #IMPLIED>

<!ELEMENT ReceiptTo ( #PCDATA | Postal | Telecom | Online )* > <!ATTLIST ReceiptTo id ID #IMPLIED >

<ELEMENT郵便！（#PCDATA |名前|会社|ストリート|市| StateProv）*> <！ATTLIST郵便番号ID #IMPLIED郵便番号NMTOKEN #IMPLIED国番号NMTOKEN #IMPLIED>

<!ELEMENT Name EMPTY > <!ATTLIST Name id ID #IMPLIED Prefix NMTOKEN #IMPLIED First NMTOKEN #IMPLIED

<！ELEMENT名EMPTY> <！ATTLIST名ID ID #IMPLIEDプレフィックスNMTOKEN #IMPLIEDまず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ストリートEMPTY> <！ATTLISTストリートID ID #IMPLIEDライン1 CDATA #REQUIRED回線2 CDATA #IMPLIED LINE3 CDATA #IMPLIED>

<!ELEMENT Company #PCDATA >

<！ELEMENT会社#PCDATA>

<!ELEMENT City #PCDATA >

<！ELEMENT市#PCDATA>

<!ELEMENT StateProv #PCDATA >

<！ELEMENT StateProv #PCDATA>

<!ELEMENT Telecom ( #PCDATA | Phone )* >

<！ELEMENTテレコム（#PCDATA |電話）*>

<!ELEMENT Phone EMPTY > <!ATTLIST Phone id ID #IMPLIED Number CDATA #REQUIRED >

<！ELEMENT電話EMPTY> <！ATTLIST電話番号ID #IMPLIED数CDATA #REQUIRED>

<!ELEMENT Online ( #PCDATA | Email )* >

<！ELEMENTオンライン（#PCDATA |メール）*>

<!ELEMENT Email EMPTY > <!ATTLIST Email id ID #IMPLIED Address CDATA #REQUIRED >

<！ELEMENTメールEMPTY> <！ATTLISTの電子メールID ID #IMPLIED住所CDATA #REQUIRED>

<!ELEMENT Payment Card>

<！ELEMENT支払いカード>

<!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> <！ATTLISTのカードID ID #IMPLIED名CDATA #IMPLIEDタイプNMTOKEN #IMPLIED数NMTOKEN #REQUIREDプロトコルNMTOKENS #IMPLIED検証NMTOKEN #IMPLIED>

<!ELEMENT ExpDate EMPTY > <!ATTLIST ExpDate id ID #IMPLIED Day NMTOKEN #IMPLIED Month NMTOKEN #REQUIRED Year NMTOKEN #REQUIRED >

<！ELEMENT EXPDATE EMPTY> <！ATTLIST EXPDATE IDのID #IMPLIED日NMTOKEN #IMPLIED月NMTOKEN #REQUIRED年NMTOKEN #REQUIRED>

<!ELEMENT User ( #PCDATA | UserID | Password )* > <!ATTLIST User id ID #IMPLIED >

<！ELEMENTユーザー（#PCDATA |ユーザーID |パスワード）*> <ATTLISTユーザーID ID #IMPLIED！>

<!ELEMENT UserID #PCDATA >

<！ELEMENTユーザーID #PCDATA>

<!ELEMENT Password #PCDATA >

<！ELEMENTパスワード#PCDATA>

<!ELEMENT Transaction ( #PCDATA | TransactionID | Inquiry | TransDate | Signature )* > <!ATTLIST Transaction id ID #IMPLIED Amount CDATA #IMPLIED Currency NMTOKEN #IMPLIED Type NMTOKEN #IMPLIED >

<！ELEMENTトランザクション（#PCDATA | TRANSACTIONID |お問い合わせ| TRANSDATE |署名）*> <！ATTLISTトランザクションID ID #IMPLIED金額CDATA #IMPLIED通貨NMTOKEN #IMPLIEDタイプNMTOKEN #IMPLIED>

<!ELEMENT TransactionComplete EMPTY>

<！ELEMENT TransactionComplete EMPTY>

3. Using The Fields

3.フィールドを使用

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節に記載されている構造と命名の近くに構造化し、名前を付ける必要があります。注意：通信に使用されるように、これはちょうど彼らの名前の上に、フィールドのユーザー見えるラベルには何の制限もありません。

3.1 Presentation of the Fields

フィールドの3.1プレゼンテーション

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.

プレゼンテーションの順番や方法に関しては何の必要な意味はありません。いくつかの商人は、フィールドを省略することにより、いくつかの少ない、より多くの情報のためにお願いしたいことがあります。いくつかの商人は他の人が、複数の相互作用または異なるWebページで異なる時間に情報の一部を求めることができる、彼らは1つの相互作用またはウェブページで必要な情報を求めることができます。例えば、以前の情報「に船」を求めるのが一般的ですので、送料は支払方法の情報の前に、計算することができます。いくつかの商人は他の多くの情報をオプションにしながら、彼らが要求するすべての情報が提供されることが必要な場合があります。等。

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.

商人が必須と考えるものフィールドを示すためにバージョン1.0またはECMLの1.1方法はありません。顧客のソフトウェアの観点から、すべてのフィールドを完了するためにオプションです。それは必要とし、いくつかのフィールドが完了していない場合は、商人は、それがフィールドが、それは誤ったと考える方法で終了している場合と同じように、情報のエラーや再現在の要求を与えることができます。

It is entirely up to the merchant when and which, if any, of the merchant to consumer fields it presents.

それは完全に商人とき、それが提示民生分野への商人の、もしあれば、次第です。

3.2 Methods and Flow of Setting the Fields

3.2フィールドの設定方法と流れ

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.

商人は、彼らは消費者が提供できることを望むものフィールドを示すことができたことで、顧客と商人の間で可能な通信の様々な方法があります。おそらく、現在配備ソフトウェアのために使用するのが最も簡単には（セクション2.2を参照）[HTML]フォームのフィールドとしてです。他の可能性は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フィールドの外観は、フィールドに入力することが可能な機能を開始するために使用することができるトリガの例です。いくつかの財布は、ユーザの活性化を必要とするかもしれないので、内に充填されるべき存在する任意のECOMのフィールドを持つすべてのページに、少なくとも1人のユーザ可視ECOMフィールドがなければならない。また、通常、隠しフィールドである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 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フィールドの前に、トランザクションに関与し、最後の対話やウェブページに表示されることをお勧めします。

3.3 HTML Example

3.3 HTMLの例

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

<HTML> <HEAD> <TITLE> ECOMフィールドの例</ TITLE> </ HEAD> <BODY> <FORM ACTION = "http://ecom.example.com" 方法= "POST">カード情報を入力してください。<カード上にp>あなたの名前

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

<input type = "text" NAME = "Ecom_Payment_Card_Name" SIZE = 40> <BR>カード番号の<input type = "text" NAME = "Ecom_Payment_Card_Number" SIZE = 19> <BR>有効期限（MM YY）<INPUTの種類= "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">の<input type = "隠れた" 名前= "Ecom_SchemaVersion" 値= "http://www.ecml.org/version/1.1"> <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_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>

<HTML> <HEAD> <TITLE> ECOMトランザクションの完全な例</ TITLE> </ HEAD> <BODY> <FORM>ご注文ありがとうございます。それは数日中に出荷されます。 <入力タイプ= "隠れた" NAME = "Ecom_Merchant" 値= "www.merchant.example">の<input type = "隠れた" NAME = "Ecom_Processor" 値= "www.processor.example">の<input type = "隠れ"名前=" Ecom_Transaction_ID」値= "EF123456"> <INPUTの種類= "隠し" 名= "Ecom_Transaction_Inquiry" 値= "HTTP：？//www.merchant.example/cgi-bin/inquire ID = EF123456"> <INPUT TYPE = "隠された" 名前= "Ecom_Transaction_Amount" 値= "789.00"> <INPUTの種類= "隠し" 名= "Ecom_Transaction_Currency" 値= "USD"> <INPUTの種類= "隠し" 名= "Ecom_Transaction_Date" 値= "7月14 2000 "> <INPUTの種類=" 隠し "名= "Ecom_Transaction_Type" 値= "信用"> <INPUTの種類= "隠し" 名= "Ecom_Transaction_Signature" 値は=" ig6rh4 ;; 20dfna00s34hj10s - S-45j30-22z92l-frwds -85 ">の<input type =" 隠れた」NAME = "Ecom_TransactionComplete">の<input type = "隠れた" NAME = "Ecom_SchemaVersion" 値= "http://www.ecml.org/version/1.1"> </ FORM > </ BODY> </ HTML>

4. Security and Privacy Considerations

4.セキュリティとプライバシーの考慮事項

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>

【イーチェック<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シモンセンら。 <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/iso3166ma>

[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]ブラドナーの、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月。

[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-Commerceのフィールド名"、RFC 2706、1999年9月。

[RFC 2801] Burdett, D., "Internet Open Trading Protocol - IOTP Version 1.0", RFC 2801, April 2000.

[RFC 2801]バーデット、D.、 "インターネットオープン取引プロトコル - IOTPバージョン1.0"、RFC 2801、2000年4月。

[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 (Second Edition), <http://www.w3.org/TR/REC-xml>, T. Bray, J. Paoli, C. M. Sperberg-McQueen, E. Maler.

[XML]拡張マークアップ言語（XML）1.0（第二版）、<http://www.w3.org/TR/REC-xml>、T.ブレイ、J.パオリ、C. M. Sperberg-マックイーン、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

(2) Change Ecom_SchemaVersion field value to "http://www.ecml.org/version/1.1".

（2） "http://www.ecml.org/version/1.1" に変更Ecom_SchemaVersionフィールド値を。

(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"、 "ラジコンおもちゃ"、 "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を含む（セクション2.2）をサポートしなければならない列挙HTMLフォーム要素。

(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_*

Authors' Addresses

著者のアドレス

Donald E. Eastlake, 3rd Motorola, M2-450 20 Cabot Boulevard Mansfield, MA 02048

ドナルドE.イーストレイク、第三モトローラ、M2-450 20キャボット大通りマンスフィールド、MA 02048

Phone: +1-508-261-5434 Fax: +1-508-261-4447 EMail: Donald.Eastlake@motorola.com

電話：+ 1-508-261-5434ファックス：+ 1-508-261-4447 Eメール：Donald.Eastlake@motorola.com

Ted Goldstein Brodia 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

完全な著作権声明

著作権（C）インターネット協会（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 Editor機能のための基金は現在、インターネット協会によって提供されます。