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