[要約] RFC 4112は、ECMLバージョン2の仕様に関する要約です。ECMLは電子商取引のモデリング言語であり、この仕様はそのバージョン2の機能と構文を定義しています。目的は、ECMLを使用して電子商取引のプロトコルやデータの交換を効率的に行うためのガイドラインを提供することです。
Network Working Group D. Eastlake 3rd
Request for Comments: 4112 Motorola Laboratories
Updates: 3106 June 2005
Category: Standards Track
Electronic Commerce Modeling Language (ECML) Version 2 Specification
電子コマースモデリング言語（ECML）バージョン2仕様
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（2005）。
Abstract
概要
Electronic commerce frequently requires a substantial exchange of information in order to complete a purchase or other transaction, especially the first time the parties communicate. A standard set of hierarchically-organized payment-related information field names in an XML syntax is defined so that this task can be more easily automated. This is the second version of an Electronic Commerce Modeling Language (ECML) and is intended to meet the requirements of RFC 3505.
電子商取引は、購入またはその他の取引を完了するために、特に当事者が最初に通信するために、かなりの情報交換を必要とすることがよくあります。XML構文の階層的に組織された支払い関連情報フィールド名の標準セットが定義されているため、このタスクをより簡単に自動化できます。これは、電子商取引モデリング言語（ECML）の2番目のバージョンであり、RFC 3505の要件を満たすことを目的としています。
Table of Contents
目次
1. Introduction ....................................................2
2. Field Definitions, DTD, and Schema ..............................3
2.1. Field List and Descriptions ................................3
2.1.1. The Field List ......................................4
2.1.2. Field Footnotes .....................................7
2.2. Exemplar XML Syntax .......................................12
2.2.1. ECML v2 XML DTD ....................................13
2.2.2. ECML v2 XML Schema .................................18
3. Usage Notes for ECML v2 ........................................26
3.1. Presentation of the Fields ................................26
3.2. Methods and Flow of Setting the Fields ....................27
4. Security and Privacy Considerations ............................28
5. IANA Considerations ............................................29
5.1. ECML v2 Schema Template ...................................29
5.2. ECML v2 URN Template ......................................29
5.2.1. Sub-registration of v2.0 ...........................30
5.3. IANA Registries ...........................................30
6. Acknowledgements ...............................................30
A. Appendix: Changes from v1.1 to v2 ..............................31
Normative References ..............................................31
Informative References ............................................32
Numerous parties are conducting business on the Internet using ad hoc fields and forms. The data formats and structure can vary considerably from one party to another. Where forms are filled out manually, some users find the diversity confusing, and the process of manually filling in these forms can be tedious and error prone.
アドホックフィールドとフォームを使用して、インターネット上で多くの当事者がビジネスを行っています。データ形式と構造は、当事者ごとに大きく異なる場合があります。フォームが手動で記入される場合、一部のユーザーは多様性が混乱していると感じ、これらのフォームを手動で埋めるプロセスは退屈でエラーが発生しやすい場合があります。
Software tools, including electronic wallets, can help this situation. Such tools can assist in conducting online transactions by storing billing, shipping, payment, preference, and similar information and using this information to complete the data sets required by interactions automatically. For example, software that fills out forms has 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 more automated transaction software has been hampered by the lack of standards.
電子財布を含むソフトウェアツールは、この状況を助けることができます。このようなツールは、請求、配送、支払い、好み、および同様の情報を保存し、この情報を使用して対話に必要なデータセットを自動的に完了することにより、オンライントランザクションの実施に役立ちます。たとえば、フォームに記入するソフトウェアは、プロキシサーバーとして、ブラウザへのヘルパーアプリケーションとして、ブラウザープラグインとして、およびサーバーベースのアプリケーションとして、ブラウザへのヘルパーアプリケーションとして、ブラウザーに正常に組み込まれています。しかし、より自動化されたトランザクションソフトウェアの急増は、基準の欠如によって妨げられています。
ECML (Electronic Commerce Modeling Language) provides a set of hierarchical payment-oriented data structures that will enable automated software, including electronic wallets from multiple vendors, to supply and query for needed data in a more uniform manner.
ECML（Electronic Commerce Modeling Language）は、複数のベンダーからの電子ウォレットを含む自動化されたソフトウェアを可能にする階層的な支払い指向のデータ構造のセットを提供します。
Version 2.0 extends ECML Versions 1.0 [RFC2706] and 1.1 [RFC3106] as described in the appendix to this document. These enhancements include support for additional payment mechanisms and transaction information and use of XML as the exemplar syntax.
バージョン2.0は、このドキュメントの付録に記載されているように、ECMLバージョン1.0 [RFC2706]および1.1 [RFC3106]を拡張します。これらの拡張機能には、追加の支払いメカニズムとトランザクション情報のサポート、およびXMLの模範的な構文としての使用が含まれます。
ECML is designed to provide a simple baseline useful in a variety of contexts. Likely uses for ECML v2 are consumer payment information input and business-to-business transactions. At this time, the first is still likely to occur through HTML forms. The second is more likely to use XML documents.
ECMLは、さまざまなコンテキストで役立つ単純なベースラインを提供するように設計されています。ECML V2の使用は、消費者支払い情報の入力および企業間取引です。現時点では、最初はHTMLフォームを介して発生する可能性があります。2つ目は、XMLドキュメントを使用する可能性が高くなります。
The ECML fields were initially derived from the W3C P3P base data schema [P3P.BASE] by the ECML Alliance as described in [RFC2706, RFC3106]. Technical development and change control of ECML was then transferred to the IETF. In version 2, ECML is extended by the fields in a W3C P3P Note related to eCommerce [P3P.ECOM], by [ISO8583], and other sources. Its primary exemplar form is now an XML syntax.
ECMLフィールドは、[RFC2706、RFC3106]に記載されているように、ECMLアライアンスによって最初にW3C P3Pベースデータスキーマ[P3P.Base]から導出されました。次に、ECMLの技術開発と変更制御がIETFに転送されました。バージョン2では、ECMLは、eコマース[P3P.ECOM]、[ISO8583]、およびその他のソースに関連するW3C P3Pノートのフィールドによって拡張されます。その主要な模範形式は現在、XML構文になりました。
ECML v2 is the definition and naming of a hierarchically structured set of fields and the provision of an optional XML syntax for their transmission. These fields can be encoded in other syntaxes. Regardless of the encoding used, the fields can be transmitted via a variety of protocols.
ECML V2は、階層的に構造化されたフィールドセットの定義と命名、およびその伝送用のオプションのXML構文の提供です。これらのフィールドは、他の構文でエンコードできます。使用されるエンコーディングに関係なく、フィールドはさまざまなプロトコルを介して送信できます。
Section 2.1 below lists and describes the fields, Section 2.2.1 provides an XML DTD for use with the fields, and Section 2.2.2 provides an XML schema.
以下のセクション2.1には、フィールドをリストおよび説明します。セクション2.2.1は、フィールドで使用するXML DTDを示し、セクション2.2.2はXMLスキーマを提供します。
To conform to this document, field names must be named and hierarchically structured as closely to the structure and naming listed below as is practical given the syntax and transaction protocol in use. (NOTE: This does not impose any restriction on human visible labeling of fields, just on their name or names and structure as used in on-the-wire communication.)
このドキュメントに準拠するには、使用中の構文とトランザクションプロトコルを考慮して、以下にリストされている構造と命名に密接に密接に指定され、階層的に構成されている必要があります。（注：これは、ワイヤ通信で使用されている名前や名前と構造だけに、フィールドの人間の可視ラベリングに制限を課すものではありません。）
The fields are listed below, along with the minimum data entry size allowed. Implementations may accept larger data sizes, if doing so makes sense, and, for some applications, they will need to allow for larger data sizes.
フィールドは、許可されている最小データ入力サイズとともに以下にリストされています。実装は、より大きなデータサイズを受け入れる場合があります。そうすることで理にかなっている場合、いくつかのアプリケーションでは、より大きなデータサイズを許可する必要があります。
Note that these fields are hierarchically organized as indicated in this table 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 of a set of card expiry date components) or Ecom_ShipTo (to encompass all the ship-to address components that a consumer is willing to provide). The labeling, marshalling, and unmarshalling of the components of such aggregates depend on the data transfer protocol used. The suggested syntax is XML as specified in Section 2.2.
これらのフィールドは、この表に示されているように、組み込みのアンダースコア（ "_"）文字によって階層的に整理されていることに注意してください。適切なデータ送信メカニズムは、これを使用して、ecom_payment_card_expdate（カード有効期限のセットのセットをすべて含めるために）またはecom_shipto（消費者が提供するすべての船舶と住所コンポーネントを含む）などの集約を要求して送信する場合があります。このような凝集体のコンポーネントのラベル付け、マーシャリング、および非群れは、使用されるデータ転送プロトコルに依存します。提案された構文は、セクション2.2で指定されているようにXMLです。
The table below is the ECML v2 field list.
以下の表は、ECML V2フィールドリストです。
The NAME column gives the structured string name of each field as explained above. The MIN column below is the minimum data size that MUST be allowed for on data entry. It is NOT the minimum size for valid contents of the field, and merchant software should, in many cases, be prepared to receive a longer or shorter value. Merchants dealing with areas where, for example, the state/province name or phone number is longer than the MIN given below obviously must permit longer data entry. In some cases, however, there is a maximum size that makes sense, and where this is the case, it is usually documented in a Note for the field.
名前列は、上記のように各フィールドの構造化された文字列名を示します。以下の最小列は、データ入力で許可する必要がある最小データサイズです。これは、フィールドの有効なコンテンツの最小サイズではなく、多くの場合、マーチャントソフトウェアはより長いまたはより短い値を受け取る準備をする必要があります。たとえば、州/州の名前または電話番号が以下の最小よりも長い分野を扱う商人は、明らかに長いデータ入力を許可する必要があります。ただし、場合によっては、理にかなっている最大サイズがあり、これが当てはまる場合、通常、フィールドのメモに文書化されています。
The following fields are typically 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 (54)
ship to middle name Ecom_ShipTo_Postal_Name_Middle 15 ( 2)
ship to last name Ecom_ShipTo_Postal_Name_Last 15 (54)
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 (54)
bill to middle name Ecom_BillTo_Postal_Name_Middle 15 ( 2)
bill to last name Ecom_BillTo_Postal_Name_Last 15 (54)
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 (54) receipt to middle name Ecom_ReceiptTo_Postal_Name_Middle 15 ( 2) receipt to last name Ecom_ReceiptTo_Postal_Name_Last 15 (54) 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)
（32）ecom_receiptto_postal_name_prefix 4（1）領収書への領収書ecom_receiptto_postal_name_first 15（54）領収書ecom_postal_name_middle 15（2）ecom_ecom_ceptto_postal_name_last 15（5）領収書ecom_postal_postal_name_las _POSTAL_NAME_SUFFIX 4（3）領収書会社名ecom_receiptto_postal_company 20ストリートラインへの領収書ecom_receiptto_postal_strete_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 issuer number Ecom_Payment_Card_IssueNumber 2 (53)
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 valid date day Ecom_Payment_Card_ValidFrom_Day 2 (14)
card valid date month Ecom_Payment_Card_ValidFrom_Month 2 (15)
card valid date year Ecom_Payment_Card_ValidFrom_Year 4 (16)
card protocols Ecom_Payment_Card_Protocol 20 (17)
loyalty card name Ecom_Loyalty_Card_Name 30 (10)
loyalty card type Ecom_Loyalty_Card_Type 20 (52)
loyalty card number Ecom_Loyalty_Card_Number 40 (34)
loyalty card verification Ecom_Loyalty_Card_Verification 4 (13)
loyalty card expire day Ecom_Loyalty_Card_ExpDate_Day 2 (14)
loyalty card expire month Ecom_Loyalty_Card_ExpDate_Month 2 (15)
loyalty card expire year Ecom_Loyalty_Card_ExpDate_Year 2 (16)
loyalty card valid day Ecom_Loyalty_Card_ValidFrom_Day 2 (14)
loyalty card valid month Ecom_Loyalty_Card_ValidFrom_Month 2 (15)
loyalty card valid year Ecom_Loyalty_Card_ValidFrom_Year 4 (16)
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)
user certificate Ecom_User_Certificate_URL 128 (55)
user data country Ecom_UserData_Country 2 ( 7)
user data language Ecom_UserData_Language 30 (33)
user data gender Ecom_UserData_Gender 1 (36)
user data birth day Ecom_UserData_BirthDate_Day 2 (14)
user data birth month Ecom_UserData_BirthDate_Month 2 (15)
user data birth year Ecom_UserData_BirthDate_Year 4 (16)
user data preferences Ecom_UserData_Preferences 60 (34)
schema version Ecom_SchemaVersion 30 (20)
wallet id Ecom_WalletID 40 (21)
wallet URL Ecom_Wallet_Location 128 (35)
customer device ID Ecom_Device_ID 20 (37)
customer device type Ecom_Device_Type 20 (38)
end transaction flag Ecom_TransactionComplete - (22)
エンドトランザクションフラグecom_transactioncomplete-（22）
The following fields are typically 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 24 (30)
transaction signature Ecom_Transaction_Signature 160 (31)
end transaction flag Ecom_TransactionComplete - (22)
エンドトランザクションフラグecom_transactioncomplete-（22）
The following fields are used to communicate between the merchant and a processor acting for the merchant (such a processor is commonly called an acquirer and is frequently a bank):
次のフィールドは、商人と商人のために作用するプロセッサの間で通信するために使用されます（このようなプロセッサは一般に取得者と呼ばれ、頻繁に銀行です）：
FIELD NAME Min Notes
merchant identifier Ecom_Merchant_ID 8
merchant terminal Ecom_Merchant_Terminal_ID 8 (39)
merchant terminal data Ecom_Merchant_Terminal_Data 128
transaction process code Ecom_Transaction_ProcessingCode 6 (40)
transaction reference Ecom_Transaction_Reference_ID 12
transaction acquirer Ecom_Transaction_Acquire_ID 13 (41)
transaction forward Ecom_Transaction_Forward_ID 13 (42)
transaction trace Ecom_Transaction_Trace_Audit 6 (43)
transaction effective date Ecom_Transaction_Effective_Date 4 (44)
transaction CID Ecom_Transaction_CID 8
transaction POS Ecom_Transaction_POSCode 12 (45)
transaction private use Ecom_Transaction_PrivateUseData 166
transaction response Ecom_Transaction_ResponseData 27
transaction approval code Ecom_Transaction_ApprovalCode 12 (46)
transaction retrieval code Ecom_Transaction_RetrievalCode 128
transaction response action Ecom_Transaction_ActionCode 13 (47)
transaction reason Ecom_Transaction_ReasonCode 4
transaction AAV Ecom_Transaction_AAV 3
transaction settlement date Ecom_Transaction_Settle_Date 4 (48)
transaction capture date Ecom_Transaction_Capture_Date 4 (49)
transaction Track 1 Ecom_Transaction_Track1 39 (50)
transaction Track 2 Ecom_Transaction_Track2 39 (51)
(1) For example: Mr., Mrs., Ms., Dr. This field is commonly omitted.
(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 omitted.
(3) 例：Ph.D.、Jr。（ジュニア）、3番目、Esq。（エスクイア）。このフィールドは一般的に省略されています。
(4) Address lines must be filled in the order line1, then line2, and last line3. Thus, for example, it is an error for line1 to be null if line2 or line3 is not.
(4) アドレスラインは、次にline2、およびlast line3の順序で入力する必要があります。したがって、たとえば、line2またはline3がそうでない場合、line1がnullになることはエラーです。
(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 according to the international market served. Use 5-character postal code 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 [ISO3166] standard two letter country codes.
(7) [ISO3166]標準の2文字の国コードを使用します。
(8) 10 digits are the minimum for numbers within the North American Numbering Plan (<http://www.nanpa.com>: It includes the US, Canada and a number of Caribbean and smaller 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, etc. Although it is desirable for telephone numbers to be in standard international format [E.164], it may be necessary to use heuristics or human examination based on the telephone number and addresses given to figure out how to call a customer, since people may enter local formatted numbers without area/access codes. It is recommend that an "x" be placed before extension numbers and that the "x" and extension number appear after all other parts of the number.
(8) 10桁は、北米の番号付け計画内の数値の最小値です（<http://www.nanpa.com>：米国、カナダ、多くのカリブ海および小型の太平洋諸国が含まれていますが、キューバは含まれていません）。他の国では、より長いフィールドが必要になる場合があります。電話番号は、国際的なアクセスコードが異なること、国内の地域/都市コードのさまざまな句読点などによって複雑になります。電話番号は標準的な国際形式[e.164]であることが望ましいが、ヒューリスティックまたは人間を使用する必要があるかもしれない顧客に電話する方法を把握するために指定された電話番号と住所に基づいた試験。エリア/アクセスコードなしでローカルフォーマットされた番号を入力する可能性があるためです。拡張番号の前に「x」を配置し、「x」と拡張番号が数字の他のすべての部分の後に表示されることをお勧めします。
(9) For example: jsmith@example.com
(9) 例：jsmith@example.com
(10) The name of the cardholder as it appears on the card.
（10）カードに表示されるカード所有者の名前。
(11) Case insensitive. Use up to the first 4 letters of the association name (see also Note 102):
（11）症例は鈍感です。協会名の最初の4文字まで使用します（注102も参照）：
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 the end but no spaces or hyphens [ISO7812]. The min given, 19, is the longest number permitted under the ISO standard.
（12）最後のチェックディジットを含むが、スペースやハイフンはありません[ISO7812]。与えられた最小19は、ISO標準で許可されている最長数です。
(13) An additional cardholder verification number printed on the card (but not embossed or recorded on the magnetic stripe) such as the American Express CIV, MasterCard CVC2, and Visa 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. The following is the initial list of case-insensitive tokens:
（17）指定されたカードに関連して利用可能なプロトコルのスペース分離リスト。以下は、ケースに依存しないトークンの初期リストです。
none set setcert iotp echeck simcard phoneid
なしsetcert iotp echeck simcard phoneid
"Set" indicates that the card is usable with SET protocol (i.e., it is in a SET wallet) but that it does not have a SET certificate [SET]. "Setcert" indicates that the card is usable with SET and has a set certificate [SET]. "iotp" indicates that the IOTP protocol [RFC2801] is supported at the customer. "echeck" indicates that the eCheck protocol [eCheck] is supported at the customer. "simcard" indicates an ability to use the transaction instrument built into a Cellphone subscriber for identification. "phoneid" indicates use for the transaction of a billable phone number. "None" indicates that automatic field fill is operating but that there is no further information.
「セット」は、カードがセットプロトコルで使用可能であることを示します（つまり、セットウォレットにあります）が、セット証明書[セット]がないことを示します。「SetCert」は、カードがセットで使用可能であり、セット証明書[セット]を持っていることを示します。「IOTP」は、IOTPプロトコル[RFC2801]が顧客でサポートされていることを示しています。「echeck」は、echeckプロトコル[echeck]が顧客でサポートされていることを示しています。「Simcard」は、識別のために携帯電話のサブスクライバーに組み込まれたトランザクション機器を使用する機能を示しています。「PhoneID」は、請求可能な電話番号の取引の使用を示しています。「なし」は、自動フィールドフィルが動作しているが、それ以上の情報がないことを示しています。
(18) A unique order ID string generated by the consumer software.
（18）消費者ソフトウェアによって生成された一意の注文ID文字列。
(19) The user ID and password fields can be used if the user has a pre-established account with the merchant to which access is authenticated by such values. For that use, one would expect an application to require exactly one user ID, and one password field be present.
（19）ユーザーがそのような値によってアクセスが認証される商人と事前に確立されたアカウントを持っている場合、ユーザーIDおよびパスワードフィールドを使用できます。その使用のために、アプリケーションが正確に1つのユーザーIDを必要とすると予想され、1つのパスワードフィールドが存在します。
(20) URI [RFC3986] indicating version of this set of fields. Equal to "urn:ietf:params:ecml:v2.0" for this version. See Section 5. (See also Note 101.)
（20）URI [RFC3986]この一連のフィールドのバージョンを示す。このバージョンの「urn：ietf：params：ecml：v2.0」に等しくなります。セクション5を参照してください（注101も参照してください。）
(21) A string to identify the source and version of form fill software that is acting on behalf of a user. Should contain company and/or product name and version; for example, "Wallets Inc., SuperFill, v42.7". (See also Note 101.)
（21）ユーザーに代わって作用しているフォームフィルソフトウェアのソースとバージョンを識別する文字列。会社および/または製品名とバージョンを含める必要があります。たとえば、「Wallets Inc.、Superfill、V42.7」。（注101も参照してください。）
(22) A flag to indicate that this web-page/aggregate is the final one for this transaction. (See also Note 101.)
（22）このWebページ/集計がこのトランザクションの最終的なものであることを示すフラグ。（注101も参照してください。）
(23) The merchant domain name [RFC1034], such as www.merchant.example. (See also Note 101.)
（23）www.merchant.exampleなどの商人ドメイン名[RFC1034]。（注101も参照してください。）
(24) The domain name [RFC1034] of the gateway transaction processor that is actually accepting the payment on behalf of the merchant, such as www.processor.example. (See also Note 101.)
（24）www.processor.exampleなど、商人に代わって実際に支払いを受け入れているゲートウェイトランザクションプロセッサのドメイン名[RFC1034]。（注101も参照してください。）
(25) A Transaction identification string whose format is specific to the processor.
（25）形式がプロセッサに固有のトランザクション識別文字列。
(26) A URL [RFC3986] that can be invoked to inquire about the transaction. (See also Note 100.)
（26）トランザクションについて問い合わせるために呼び出すことができるURL [RFC3986]。（注100も参照してください。）
(27) The amount of the transaction in ISO currency format [ISO4217]. This is two integer numbers with a period in between but with no other currency mark (such as a "$" dollar sign).
（27）ISO通貨形式のトランザクションの量[ISO4217]。これは2つの整数数であり、その間に期間がありますが、他の通貨マーク（「$」ドルの標識など）はありません。
(28) This is the three-letter ISO currency code [ISO4217]. For example, US dollars is USD.
（28）これは3文字のISO通貨コード[ISO4217]です。たとえば、米ドルは米ドルです。
(29) ISO Transaction date.
（29）ISOトランザクション日。
(30) The type of the transaction, if known. Currently a value from the following list:
（30）既知の場合、トランザクションのタイプ。現在、次のリストからの値：
debit credit
デビットクレジット
(31) A digital signature, base64 encoded [RFC2045]. (See also Note 101.)
（31）デジタル署名、base64エンコード[RFC2045]。（注101も参照してください。）
(32) The ReceiptTo fields are used when the BillTo entity, location, or address and the ReceiptTo 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 ReceiptTo fields, and the corporate or other owner would be in the BillTo fields.
（32）Billtoエンティティ、場所、または住所、および領収書への領収書、場所、または住所が異なる場合、フィールドへの領収書が使用されます。たとえば、企業の購入カードまたはエージェント購入カードを使用する場合、個々のカード所有者はフィールドに領収書に入り、企業または他の所有者はビルトフィールドにいます。
(33) An IETF Language Tag, as defined in [RFC3066].
（33）[RFC3066]で定義されているIETF言語タグ。
(34) User preferences, as specified by the merchant. (See also Note 102.)
（34）マーチャントが指定したユーザー設定。（注102も参照してください。）
(35) The Uniform Resource Locator [RFC3986] for accessing the customer's "wallet" software. (See also Note 100)
（35）顧客の「ウォレット」ソフトウェアにアクセスするためのユニフォームリソースロケーター[RFC3986]。（注100も参照）
(36) A single capital letter: M=male, F=Female, U=Unknown [ISO5218].
（36）単一の大文字：M =男性、F =女性、U =不明[ISO5218]。
(37) An immutable device identification or serial number. (See also Note 102.)
（37）不変のデバイスの識別またはシリアル番号。（注102も参照してください。）
(38) User understandable device brand name. (See also Note 102)
（38）ユーザーの理解可能なデバイスブランド名。（注102も参照）
(39) [ISO8583] field "card acceptor terminal identification".
（39）[ISO8583]フィールド「カードアクセプターターミナル識別」。
(40) [ISO8583] field "processing code".
（40）[ISO8583]フィールド「処理コード」。
(41) [ISO8583] field "acquiring institution identification code".
（41）[ISO8583]フィールド「機関識別コードの取得」。
(42) [ISO8583] field "forwarding institution identification code".
（42）[ISO8583]フィールド「転送機関識別コード」。
(43) [ISO8583] field "system trace audit field".
（43）[ISO8583]フィールド「システムトレース監査フィールド」。
(44) [ISO8583] field "date effective".
（44）[ISO8583]フィールド「日付効果」。
(45) [ISO8583] field "point of sale date code".
（45）[ISO8583]フィールド「販売ポイントコード」。
(46) [ISO8583] field "approval code".
（46）[ISO8583]フィールド「承認コード」。
(47) [ISO8583] field "action code".
（47）[ISO8583]フィールド「アクションコード」。
(48) [ISO8583] field "date settlement".
（48）[ISO8583]フィールド「日付決済」。
(49) [ISO8583] field "date capture".
（49）[ISO8583]フィールド「日付キャプチャ」。
(50) [ISO8583] field "trace 1 data".
（50）[ISO8583]フィールド「トレース1データ」。
(51) [ISO8583] field "trace 2 data".
（51）[ISO8583]フィールド「TRACE 2データ」。
(52) User-recognizable loyalty card brand name. Values for this field are not controlled, and there is no IANA or other registry for them. (See also Note 102.)
（52）ユーザー認識可能なロイヤルティカードブランド名。このフィールドの値は制御されておらず、それらにはIANAまたは他のレジストリがありません。（注102も参照してください。）
(53) The card issuer number required by the UK-based Switch and Solo acquirers.
（53）英国を拠点とするスイッチとソロ取得者が必要とするカード発行者番号。
(54) The field names "first_name" and "last_name" have been retained for compatibility with earlier versions of ECML. However, "last_name" should be understood to refer to family or inherited names(s), whereas "first_name" is the first given or non-inherited name and "middle_name" is the subsequent given or non-inherited name or names, if any.
（54）ECMLの以前のバージョンとの互換性のために、「First_name」と「last_name」というフィールド名が保持されています。ただし、「last_name」は家族または継承された名前を参照することを理解する必要がありますが、「first_name」は最初の名前または非相続名であり、「middle_name」は後続の与えられた名前または非譲渡名です。。
(55) The Uniform Resource Locator [RFC3986] for accessing the user's X.509v3 certificate encoded as binary DER. (See also Note 100.)
（55）ユーザーのX.509V3証明書にバイナリDerとしてエンコードされたX.509V3証明書にアクセスするためのユニフォームリソースロケーター[RFC3986]。（注100も参照してください。）
Meta Notes (referenced by other notes)
メタノート（他のメモが参照）
(100) ECML, a basic field-naming and structuring convention, does not impose any particular requirements on these URLs. It is to be expected that most applications that make use of ECML will impose such limitations and perform checking to be sure that provided URLs conform to such limitations before attempting to invoke them.
（100）基本的なフィールドアナミングおよび構造化規則であるECMLは、これらのURLに特定の要件を課していません。ECMLを使用するほとんどのアプリケーションは、そのような制限を課し、チェックを実行して、提供されたURLがそれらを呼び出す前にそのような制限に適合することを確認することが期待されます。
(101) This is a field that, when presented in a web page, is usually hidden.
（101）これは、Webページに提示された場合、通常は隠されているフィールドです。
(102) An ASCII [ASCII] character string with no leading or trailing white space.
（102）主要または後続の空白のないASCII [ASCII]文字文字列。
The following sections provide an XML DTD and an XML Schema that express the ECML fields with ECML v2 naming and ECML v2 hierarchical structure. In case of conflict between this DTD and Schema, the Schema should prevail. Note that the ECML v2 naming and structure may be used in non-XML syntaxes.
次のセクションでは、ECML V2命名とECML V2階層構造でECMLフィールドを表現するXML DTDとXMLスキーマを提供します。このDTDとスキーマの間に競合した場合、スキーマが勝つはずです。ECML V2の命名と構造は、非XML構文で使用できることに注意してください。
The ECML v2 XML syntax is deliberately liberal because it is assumed that specific applications making use of ECML will impose their own additional constraints.
ECML V2 XML構文は、ECMLを使用する特定のアプリケーションが独自の追加の制約を課すと想定されるため、意図的にリベラルです。
For internationalization of ECML, use the general XML character-encoding provisions [XML] (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.
ECMLの国際化には、一般的なXML文字エンコード条項[XML]（UTF-8およびUTF-16のサポートを義務付け、他の文字セットのサポートを許可）とXML：Lang属性を使用して、言語を指定するために使用できます。情報。
The following is an XML DTD for ECML v2.
以下は、ECML V2のXML DTDです。
<!-- Electronic Commerce Modeling Language v2 -->
<!ELEMENT Ecom ( #PCDATA | ShipTo | BillTo | ReceiptTo | Payment |
Loyalty | User | Merchant | Transaction |
TransactionComplete )* >
<!ATTLIST Ecom
id ID #IMPLIED
ConsumerOrderID CDATA #IMPLIED
Merchant CDATA #IMPLIED
Mode (Query|Assert) #IMPLIED
Processor CDATA #IMPLIED
SchemaVersion (urn:ietf:params:ecml:v2.0)
#IMPLIED
WalletID CDATA #IMPLIED
WalletLocation CDATA #IMPLIED >
<!ELEMENT ShipTo ( #PCDATA | Postal | Telecom | Online )* >
<!ATTLIST ShipTo
id ID #IMPLIED
Mode (Query|Assert) #IMPLIED >
<!ELEMENT BillTo ( #PCDATA | Postal | Telecom | Online )* >
<!ATTLIST BillTo
id ID #IMPLIED
Mode (Query|Assert) #IMPLIED >
<!ELEMENT ReceiptTo ( #PCDATA | Postal | Telecom | Online )* >
<!ATTLIST ReceiptTo
id ID #IMPLIED
Mode (Query|Assert) #IMPLIED >
<!ELEMENT Postal ( #PCDATA | Name | Company |
Street | City | StateProv )* >
<!ATTLIST Postal
id ID #IMPLIED
PostalCode NMTOKEN #IMPLIED
Mode (Query|Assert) #IMPLIED
CountryCode NMTOKEN #IMPLIED >
<!ELEMENT Name EMPTY >
<!ATTLIST Name
id ID #IMPLIED
Mode (Query|Assert) #IMPLIED
Prefix NMTOKEN #IMPLIED
First NMTOKEN #IMPLIED
Middle NMTOKEN #IMPLIED
Last NMTOKEN #IMPLIED
Suffix NMTOKEN #IMPLIED >
<!ELEMENT Street EMPTY >
<!ATTLIST Street
id ID #IMPLIED
Mode (Query|Assert) #IMPLIED
Line1 CDATA #REQUIRED
Line2 CDATA #IMPLIED
Line3 CDATA #IMPLIED >
<!ELEMENT Company (#PCDATA) >
<!ATTLIST Company
Mode (Query|Assert) #IMPLIED >
<!ELEMENT City (#PCDATA) >
<!ATTLIST City
Mode (Query|Assert) #IMPLIED >
<!ELEMENT StateProv (#PCDATA) >
<!ATTLIST StateProv
Mode (Query|Assert) #IMPLIED >
<!ELEMENT Telecom ( #PCDATA | Phone )* >
<!ATTLIST Telecom
Mode (Query|Assert) #IMPLIED >
<!ELEMENT Phone EMPTY >
<!ATTLIST Phone
id ID #IMPLIED
Mode (Query|Assert) #IMPLIED
Number CDATA #REQUIRED >
<!ELEMENT Online ( #PCDATA | Email )* >
<!ATTLIST Online
Mode (Query|Assert) #IMPLIED >
<!ELEMENT Email EMPTY >
<!ATTLIST Email
id ID #IMPLIED
Mode (Query|Assert) #IMPLIED
Address CDATA #REQUIRED >
<!ELEMENT Payment (Card) >
<!ATTLIST Payment
Mode (Query|Assert) #IMPLIED >
モード（クエリ| assert）#implied>
<!ELEMENT Card (ExpDate, ValidDate?) >
<!ATTLIST Card
id ID #IMPLIED
Mode (Query|Assert) #IMPLIED
Name CDATA #IMPLIED
Type NMTOKEN #IMPLIED
Number NMTOKEN #REQUIRED
Protocols NMTOKENS #IMPLIED
Verification NMTOKEN #IMPLIED
Issuer NMTOKEN #IMPLIED >
<!ELEMENT Loyalty (ExpDate?, ValidDate?) >
<!ATTLIST Loyalty
id ID #IMPLIED
Mode (Query|Assert) #IMPLIED
Name CDATA #IMPLIED
Type NMTOKEN #IMPLIED
Number NMTOKEN #REQUIRED
Verification NMTOKEN #IMPLIED >
<!ELEMENT ExpDate EMPTY >
<!ATTLIST ExpDate
id ID #IMPLIED
Mode (Query|Assert) #IMPLIED
Day NMTOKEN #IMPLIED
Month NMTOKEN #REQUIRED
Year NMTOKEN #REQUIRED >
<!ELEMENT ValidDate EMPTY >
<!ATTLIST ValidDate
id ID #IMPLIED
Mode (Query|Assert) #IMPLIED
Day NMTOKEN #IMPLIED
Month NMTOKEN #IMPLIED
Year NMTOKEN #REQUIRED >
<!ELEMENT User ( #PCDATA | UserID | Password )* >
<!ATTLIST User
id ID #IMPLIED
Mode (Query|Assert) #IMPLIED
CertificateURL CDATA #IMPLIED
DataCountry NMTOKEN #IMPLIED
DataLanguage CDATA #IMPLIED >
<!ELEMENT UserID (#PCDATA) >
<!ATTLIST UserID
Mode (Query|Assert) #IMPLIED >
モード（クエリ| assert）#implied>
<!ELEMENT Password (#PCDATA) >
<!ATTLIST Password
Mode (Query|Assert) #IMPLIED >
<!ELEMENT Merchant (Terminal) >
<!ATTLIST Merchant
Mode (Query|Assert) #IMPLIED
id ID #IMPLIED >
<!ELEMENT Terminal EMPTY >
<!ATTLIST Terminal
Id ID #IMPLIED
Mode (Query|Assert) #IMPLIED
Data CDATA #IMPLIED >
<!ELEMENT Transaction ( #PCDATA | Id | Code | Date | Data |
Inquiry | Signature )* >
<!ATTLIST Transaction
Amount CDATA #IMPLIED
Currency NMTOKEN #IMPLIED
Mode (Query|Assert) #IMPLIED
Type NMTOKEN #IMPLIED >
<!ELEMENT Id EMPTY >
<!ATTLIST Id
Id ID #IMPLIED
Mode (Query|Assert) #IMPLIED
CID NMTOKEN #IMPLIED
Reference NMTOKEN #IMPLIED
Acquire NMTOKEN #IMPLIED
Forward NMTOKEN #IMPLIED >
<!ELEMENT Code EMPTY >
<!ATTLIST Code
Mode (Query|Assert) #IMPLIED
Processing CDATA #IMPLIED
Approval NMTOKEN #IMPLIED
Retrieval NMTOKEN #IMPLIED
Action NMTOKEN #IMPLIED
Reason NMTOKEN #IMPLIED
POS NMTOKEN #IMPLIED >
<!ELEMENT Date (Effective?, Settle?, Capture?) >
<!ATTLIST Date
Mode (Query|Assert) #IMPLIED
id ID #IMPLIED >
<!ELEMENT Effective EMPTY >
<!ATTLIST Effective
id ID #IMPLIED
Mode (Query|Assert) #IMPLIED
Day NMTOKEN #REQUIRED
Month NMTOKEN #REQUIRED
Year NMTOKEN #REQUIRED >
<!ELEMENT Settle EMPTY >
<!ATTLIST Settle
id ID #IMPLIED
Mode (Query|Assert) #IMPLIED
Day NMTOKEN #REQUIRED
Month NMTOKEN #REQUIRED
Year NMTOKEN #REQUIRED >
<!ELEMENT Capture EMPTY >
<!ATTLIST Capture
id ID #IMPLIED
Mode (Query|Assert) #IMPLIED
Day NMTOKEN #REQUIRED
Month NMTOKEN #REQUIRED
Year NMTOKEN #REQUIRED >
<!ELEMENT Data (#PCDATA | Trace | PrivateUse | Response |
AAV | Track1 | Track2 )* >
<!ATTLIST Data
Mode (Query|Assert) #IMPLIED >
<!ELEMENT Trace (#PCDATA) >
<!ATTLIST Trade
id ID #IMPLIED
Mode (Query|Assert) #IMPLIED >
<!ELEMENT PrivateUse (#PCDATA) >
<!ATTLIST PrivateUse
id ID #IMPLIED
Mode (Query|Assert) #IMPLIED >
<!ELEMENT Response (#PCDATA) >
<!ATTLIST Response
id ID #IMPLIED
Mode (Query|Assert) #IMPLIED >
<!ELEMENT AAV (#PCDATA) >
<!ATTLIST AAV
id ID #IMPLIED
Mode (Query|Assert) #IMPLIED >
<!ELEMENT Track1 (#PCDATA) >
<!ATTLIST Track1
id ID #IMPLIED
Mode (Query|Assert) #IMPLIED >
<!ELEMENT Track2 (#PCDATA) >
<!ATTLIST Track2
id ID #IMPLIED
Mode (Query|Assert) #IMPLIED >
<!ELEMENT Inquiry (#PCDATA) >
<!ATTLIST Inquiry
id ID #IMPLIED
Mode (Query|Assert) #IMPLIED >
<!ELEMENT Signature (#PCDATA) >
<!ATTLIST Signature
id ID #IMPLIED
Mode (Query|Assert) #IMPLIED >
<!ELEMENT TransactionComplete EMPTY >
The following is an XML Schema for ECML v2.
以下は、ECML V2のXMLスキーマです。
<?xml version="1.0" encoding="utf-8"?>
<!-- Electronic Commerce Modeling Language v2 -->
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified">
<xs:attribute name="Mode">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="Query"/>
<xs:enumeration value="Assert"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="id" type="xs:ID"/>
<xs:complexType name="EcomSimpleText">
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute ref="Mode" use="optional"/>
<xs:attribute ref="id" use="optional"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:element name="Ecom">
<xs:complexType mixed="true">
<xs:choice minOccurs="0" maxOccurs="unbounded">
<xs:element ref="ShipTo"/>
<xs:element ref="BillTo"/>
<xs:element ref="ReceiptTo"/>
<xs:element ref="Payment"/>
<xs:element ref="Loyalty"/>
<xs:element ref="User"/>
<xs:element ref="Merchant"/>
<xs:element ref="Transaction"/>
<xs:element ref="TransactionComplete"/>
</xs:choice>
<xs:attribute ref="Mode" use="optional"/>
<xs:attribute ref="id" use="optional"/>
<xs:attribute name="ConsumerOrderID" use="optional"/>
<xs:attribute name="Merchant" use="optional"/>
<xs:attribute name="Processor" use="optional"/>
<xs:attribute name="SchemaVersion" type="xs:string"
fixed="urn:ietf:params:ecml:v2.0"/>
<xs:attribute name="WalletID" use="optional"/>
<xs:attribute name="WalletLocation" type="xs:anyURI"
use="optional"/>
</xs:complexType>
</xs:element>
<xs:element name="ShipTo">
<xs:complexType mixed="true">
<xs:choice minOccurs="0" maxOccurs="unbounded">
<xs:element ref="Postal"/>
<xs:element ref="Telecom"/>
<xs:element ref="Online"/>
</xs:choice>
<xs:attribute ref="Mode" use="optional"/>
<xs:attribute ref="id" use="optional"/>
</xs:complexType>
</xs:element>
<xs:element name="BillTo">
<xs:complexType mixed="true">
<xs:choice minOccurs="0" maxOccurs="unbounded">
<xs:element ref="Postal"/>
<xs:element ref="Telecom"/>
<xs:element ref="Online"/>
</xs:choice>
<xs:attribute ref="Mode" use="optional"/>
<xs:attribute ref="id" use="optional"/>
</xs:complexType>
</xs:element>
<xs:element name="ReceiptTo">
<xs:complexType mixed="true">
<xs:choice minOccurs="0" maxOccurs="unbounded">
<xs:element ref="Postal"/>
<xs:element ref="Telecom"/>
<xs:element ref="Online"/>
</xs:choice>
<xs:attribute ref="Mode" use="optional"/>
<xs:attribute ref="id" use="optional"/>
</xs:complexType>
</xs:element>
<xs:element name="Postal">
<xs:complexType mixed="true">
<xs:choice minOccurs="0" maxOccurs="unbounded">
<xs:element ref="Name"/>
<xs:element ref="Company"/>
<xs:element ref="Street"/>
<xs:element ref="City"/>
<xs:element ref="StateProv"/>
</xs:choice>
<xs:attribute ref="Mode" use="optional"/>
<xs:attribute ref="id" use="optional"/>
<xs:attribute name="PostalCode" type="xs:NMTOKEN"
use="optional"/>
<xs:attribute name="CountryCode" type="xs:NMTOKEN"
use="optional"/>
</xs:complexType>
</xs:element>
<xs:element name="Telecom">
<xs:complexType mixed="true">
<xs:sequence maxOccurs="unbounded">
<xs:element name="Phone">
<xs:complexType>
<xs:attribute ref="Mode" use="optional"/>
<xs:attribute ref="id" use="optional"/>
<xs:attribute name="Number"/>
</xs:complexType>
</xs:element>
</xs:sequence>
<xs:attribute ref="Mode" use="optional"/>
</xs:complexType>
</xs:element>
<xs:element name="Online">
<xs:complexType mixed="true">
<xs:sequence maxOccurs="unbounded">
<xs:element name="Email">
<xs:complexType>
<xs:attribute ref="Mode" use="optional"/>
<xs:attribute ref="id" use="optional"/>
<xs:attribute name="Address"/>
</xs:complexType>
</xs:element>
</xs:sequence>
<xs:attribute ref="Mode" use="optional"/>
</xs:complexType>
</xs:element>
<xs:element name="Payment">
<xs:complexType>
<xs:sequence>
<xs:element name="Card">
<xs:complexType>
<xs:sequence>
<xs:element ref="ExpDate"/>
<xs:element ref="ValidDate" minOccurs="0"/>
</xs:sequence>
<xs:attribute ref="Mode" use="optional"/>
<xs:attribute ref="id" use="optional"/>
<xs:attribute name="Name" use="optional"/>
<xs:attribute name="Type" type="xs:NMTOKEN"
use="optional"/>
<xs:attribute name="Number" type="xs:decimal"/>
<xs:attribute name="Protocols" type="xs:NMTOKENS"
use="optional"/>
<xs:attribute name="Verification"
type="xs:NMTOKEN" use="optional"/>
<xs:attribute name="Issuer" type="xs:NMTOKEN"
use="optional"/>
</xs:complexType>
</xs:element>
</xs:sequence>
<xs:attribute ref="Mode" use="optional"/>
</xs:complexType>
</xs:element>
<xs:element name="Loyalty">
<xs:complexType>
<xs:sequence>
<xs:element ref="ExpDate"/>
<xs:element ref="ValidDate" minOccurs="0"/>
</xs:sequence>
<xs:attribute ref="Mode" use="optional"/>
<xs:attribute ref="id" use="optional"/>
<xs:attribute name="Name" use="optional"/>
<xs:attribute name="Type" type="xs:NMTOKEN"
use="optional"/>
<xs:attribute name="Number" type="xs:NMTOKEN"/>
<xs:attribute name="Verification" type="xs:NMTOKEN"
use="optional"/>
</xs:complexType>
</xs:element>
<xs:element name="ExpDate">
<xs:complexType>
<xs:attribute ref="Mode" use="optional"/>
<xs:attribute ref="id" use="optional"/>
<xs:attribute name="Day" type="xs:positiveInteger"/>
<xs:attribute name="Month" type="xs:positiveInteger"/>
<xs:attribute name="Year" type="xs:positiveInteger"/>
</xs:complexType>
</xs:element>
<xs:element name="ValidDate">
<xs:complexType>
<xs:attribute ref="Mode" use="optional"/>
<xs:attribute ref="id" use="optional"/>
<xs:attribute name="Day" type="xs:positiveInteger"/>
<xs:attribute name="Month" type="xs:positiveInteger"/>
<xs:attribute name="Year" type="xs:positiveInteger"/>
</xs:complexType>
</xs:element>
<xs:element name="User">
<xs:complexType mixed="true">
<xs:choice minOccurs="0" maxOccurs="unbounded">
<xs:element ref="UserID"/>
<xs:element ref="Password"/>
</xs:choice>
<xs:attribute ref="Mode" use="optional"/>
<xs:attribute ref="id" use="optional"/>
<xs:attribute name="CertificateURL" type="xs:anyURI"
use="optional"/>
<xs:attribute name="DataCountry" type="xs:NMTOKEN"
use="optional"/>
<xs:attribute name="DataLanguage" type="xs:language"
use="optional"/>
</xs:complexType>
</xs:element>
<xs:element name="Transaction">
<xs:complexType mixed="true">
<xs:choice minOccurs="0" maxOccurs="unbounded">
<xs:element ref="Id"/>
<xs:element ref="Code"/>
<xs:element ref="Date"/>
<xs:element ref="Data"/>
<xs:element ref="Inquiry"/>
<xs:element ref="Signature"/>
</xs:choice>
<xs:attribute ref="Mode" use="optional"/>
<xs:attribute name="Currency" type="xs:NMTOKEN"
use="optional"/>
<xs:attribute name="Type" type="xs:NMTOKEN"
use="optional"/>
</xs:complexType>
</xs:element>
<xs:element name="Date">
<xs:complexType>
<xs:sequence>
<xs:element ref="Effective" minOccurs="0"/>
<xs:element ref="Settle" minOccurs="0"/>
<xs:element ref="Capture" minOccurs="0"/>
</xs:sequence>
<xs:attribute ref="Mode" use="optional"/>
<xs:attribute ref="id" use="optional"/>
</xs:complexType>
</xs:element>
<xs:element name="Data">
<xs:complexType mixed="true">
<xs:choice minOccurs="0" maxOccurs="unbounded">
<xs:element ref="Trace"/>
<xs:element ref="PrivateUse"/>
<xs:element ref="Response"/>
<xs:element ref="AAV"/>
<xs:element ref="Track1"/>
<xs:element ref="Track2"/>
</xs:choice>
<xs:attribute ref="Mode" use="optional"/>
</xs:complexType>
</xs:element>
<xs:element name="Merchant">
<xs:complexType>
<xs:sequence>
<xs:element name="Terminal">
<xs:complexType>
<xs:attribute ref="Mode" use="optional"/>
<xs:attribute ref="id" use="optional"/>
<xs:attribute name="Data" use="optional"/>
</xs:complexType>
</xs:element>
</xs:sequence>
<xs:attribute ref="Mode" use="optional"/>
<xs:attribute ref="id" use="optional"/>
</xs:complexType>
</xs:element>
<xs:element name="AAV" type="EcomSimpleText"/>
<xs:element name="Capture">
<xs:complexType>
<xs:attribute ref="Mode" use="optional"/>
<xs:attribute ref="id" use="optional"/>
<xs:attribute name="Day" type="xs:NMTOKEN"/>
<xs:attribute name="Month" type="xs:NMTOKEN"/>
<xs:attribute name="Year" type="xs:NMTOKEN"/>
</xs:complexType>
</xs:element>
<xs:element name="City" type="EcomSimpleText"/>
<xs:element name="Code">
<xs:complexType>
<xs:attribute ref="Mode" use="optional"/>
<xs:attribute name="Processing" use="optional"/>
<xs:attribute name="Approval" type="xs:NMTOKEN"
use="optional"/>
<xs:attribute name="Retrieval" type="xs:NMTOKEN"
use="optional"/>
<xs:attribute name="Action" type="xs:NMTOKEN"
use="optional"/>
<xs:attribute name="Reason" type="xs:NMTOKEN"
use="optional"/>
<xs:attribute name="POS" type="xs:NMTOKEN"
use="optional"/>
</xs:complexType>
</xs:element>
<xs:element name="Company" type="EcomSimpleText"/>
<xs:element name="Effective">
<xs:complexType>
<xs:attribute ref="Mode" use="optional"/>
<xs:attribute ref="id" use="optional"/>
<xs:attribute name="Day" type="xs:NMTOKEN"/>
<xs:attribute name="Month" type="xs:NMTOKEN"/>
<xs:attribute name="Year" type="xs:NMTOKEN"/>
</xs:complexType>
</xs:element>
<xs:element name="Id">
<xs:complexType>
<xs:attribute ref="Mode" use="optional"/>
<xs:attribute ref="id" use="optional"/>
<xs:attribute name="CID" type="xs:NMTOKEN"
use="optional"/>
<xs:attribute name="Reference" type="xs:NMTOKEN"
use="optional"/>
<xs:attribute name="Acquire" type="xs:NMTOKEN"
use="optional"/>
<xs:attribute name="Forward" type="xs:NMTOKEN"
use="optional"/>
</xs:complexType>
</xs:element>
<xs:element name="Inquiry">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:anyURI">
<xs:attribute ref="Mode" use="optional"/>
<xs:attribute ref="id" use="optional"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:element name="Name">
<xs:complexType>
<xs:attribute ref="Mode" use="optional"/>
<xs:attribute ref="id" use="optional"/>
<xs:attribute name="Prefix" type="xs:NMTOKEN"
use="optional"/>
<xs:attribute name="First" type="xs:NMTOKEN"
use="optional"/>
<xs:attribute name="Middle" type="xs:NMTOKEN"
use="optional"/>
<xs:attribute name="Last" type="xs:NMTOKEN"
use="optional"/>
<xs:attribute name="Suffix" type="xs:NMTOKEN"
use="optional"/>
</xs:complexType>
</xs:element>
<xs:element name="Password" type="EcomSimpleText"/>
<xs:element name="PrivateUse" type="EcomSimpleText"/>
<xs:element name="Response" type="EcomSimpleText"/>
<xs:element name="Settle">
<xs:complexType>
<xs:attribute ref="Mode" use="optional"/>
<xs:attribute ref="id" use="optional"/>
<xs:attribute name="Day" type="xs:NMTOKEN"/>
<xs:attribute name="Month" type="xs:NMTOKEN"/>
<xs:attribute name="Year" type="xs:NMTOKEN"/>
</xs:complexType>
</xs:element>
<xs:element name="Signature">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute ref="Mode" use="optional"/>
<xs:attribute ref="id" use="optional"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:element name="StateProv" type="EcomSimpleText"/>
<xs:element name="Street">
<xs:complexType>
<xs:attribute ref="Mode" use="optional"/>
<xs:attribute ref="id" use="optional"/>
<xs:attribute name="Line1"/>
<xs:attribute name="Line2" use="optional"/>
<xs:attribute name="Line3" use="optional"/>
</xs:complexType>
</xs:element>
<xs:element name="Trace" type="EcomSimpleText"/>
<xs:element name="Track1" type="EcomSimpleText"/>
<xs:element name="Track2" type="EcomSimpleText"/>
<xs:element name="TransactionComplete">
<xs:complexType/>
</xs:element>
<xs:element name="UserID" type="EcomSimpleText"/>
</xs:schema>
This section provides a general usage guide for ECML v2.
このセクションでは、ECML V2の一般的な使用ガイドを提供します。
ECML v2 merely names fields and specifies their content and hierarchical organization. It does not constrain the order or completeness of communication of or query for these fields.
ECML V2は、単にフィールドに名前を付けて、コンテンツと階層組織を指定します。これらのフィールドの通信またはクエリの順序または完全性を制約しません。
Some parties may wish to provide or ask for more information, and some for less by omitting fields. Some may ask for the information they want in one interaction or web page, and 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 that the shipping cost can be computed before the payment method information. Some parties may require that all the information they request be provided whereas others may make much of the information optional. Other variations are likely.
一部の当事者は、より多くの情報を提供または要求したい場合があり、一部はフィールドを省略することで少ない場合があります。1つのインタラクションまたはWebページで必要な情報を求める人もいれば、複数のインタラクションや異なるWebページで、さまざまな時期に情報の一部を要求する人もいます。たとえば、支払い方法情報の前に送料を計算できるように、以前に「出荷」情報を要求することが一般的です。一部の当事者は、要求するすべての情報を提供することを要求する場合がありますが、他の関係者は多くの情報をオプションにすることができます。他のバリエーションが可能性があります。
Every element may be flagged as a query or assertion by including, when XML syntax is in use, the optional Mode attribute with the value "Query" or "Assert" respectively. The Mode attribute effects all descendant elements until overridden by a lower level element with a Mode attribute. Thus it is easy to indicate that all of the elements in an ECML v2 structure are present as queries or assertions.
すべての要素は、XML構文が使用されている場合、それぞれ値「クエリ」または「アサート」を持つオプションモード属性を含めることにより、クエリまたはアサーションとしてフラグを立てることができます。モード属性は、モード属性を持つ低レベルの要素によってオーバーライドされるまで、すべての子孫要素に影響します。したがって、ECML V2構造のすべての要素がクエリまたはアサーションとして存在することを示すのは簡単です。
Query elements may have data content. Such content SHOULD be interpreted as a default value to be returned if no better value is known.
クエリ要素にはデータコンテンツがある場合があります。このようなコンテンツは、より良い値がわかっていない場合は、返されるデフォルト値として解釈する必要があります。
There is no way with Version 2.0 of ECML to indicate what query fields a party considers mandatory to be answered. From this point of view, all fields queried are optional to complete. However, a party 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 that it considers erroneous.
ECMLのバージョン2.0には、パーティーが必須と考えるクエリフィールドが答えられると考える方法を示す方法はありません。この観点から、クエリされたすべてのフィールドは完了するためにオプションです。ただし、当事者は、フィールドが誤っていると考える方法でフィールドが完了した場合と同じように、必要なフィールドが完了していない場合、情報のリクエストを誤り、または再提出する場合があります。
A variety of methods of communication is possible between the parties by which each can indicate what fields it wants the other to provide. Probably the easiest method for currently deployed mass software is through fields in an [HTML] form. Other possibilities include using an [XML] exchange, the IOTP Authenticate transaction [RFC2801], or proprietary protocols.
それぞれが他の人に提供するフィールドを示すことができる当事者間で、さまざまなコミュニケーション方法が可能です。おそらく、現在展開されているマスソフトウェアの最も簡単な方法は、[HTML]フォームのフィールドを使用することです。その他の可能性には、[XML] Exchangeの使用、IOTP認証トランザクション[RFC2801]、または独自のプロトコルの使用が含まれます。
So that browser software can tell what version it is dealing with, it is REQUIRED that the Ecom_SchemaVersion field be included in every transaction when ECML is being used on the web. Ecom_SchemaVersion SHOULD appear on every web page that has any Ecom fields. It is usually a hidden field in HTML Forms.
ブラウザソフトウェアがどのバージョンを扱っているかを知ることができるように、ECMLがWebで使用されている場合、すべてのトランザクションにecom_schemaversionフィールドを含める必要があります。ecom_schemaversionは、ECOMフィールドを持つすべてのWebページに表示される必要があります。通常、HTMLフォームの隠されたフィールドです。
User action or the appearance of the Ecom_SchemaVersion field are examples of triggers that can be used to initiate a facility capable of providing information in response to an ECML-based query or of using information from ECML assertions. Because some web software may require user activation, it is RECOMMENDED that there be at least one user-visible Ecom field on every web page with any Ecom fields present when ECML is used via the web.
ユーザーアクションまたはECOM_Schemaversionフィールドの外観は、ECMLベースのクエリに応じて情報を提供できる施設またはECMLアサーションからの情報を使用できる施設を開始できるトリガーの例です。一部のWebソフトウェアはユーザーのアクティブ化が必要になる場合があるため、ECMLをWebを介して使用する場合、ECOMフィールドが存在するすべてのWebページに、少なくとも1つのユーザー可視ECOMフィールドがあることをお勧めします。
Under some circumstances, communications can proceed very slowly, so it may not be clear to an automated processing function when it is finished receiving ECML fields on a web page or the like. For this reason, it is RECOMMENDED that the Ecom_SchemaVersion field be the last Ecom field on a web page.
状況によっては、通信が非常にゆっくりと進行する可能性があるため、WebページなどでECMLフィールドの受信が終了したときに自動処理機能が明確ではない場合があります。このため、ecom_schemaversionフィールドは、Webページの最後のECOMフィールドになることをお勧めします。
Transfer or 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 provide personal data beyond the end of the transaction with a particular business. For this reason, the Ecom_TransactionComplete field, which is normally hidden when it is part of an HTML Form, 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-interaction automated logic receives a hint as to when to stop if it chooses to check for this field.
情報の転送またはリクエストは、いくつかのインタラクションまたはWebページにわたって延長できます。さらなる規定がなければ、施設は各ページで再起動するか、特定のビジネスでトランザクションの終了を超えて個人データを提供し続けることにより、プライバシーに違反する可能性がある可能性があります。このため、HTMLフォームの一部であるときに通常隠されているecom_transactioncompleteフィールドが提供されます。ECOM_SCHEMAVERSIONフィールドの直前に、トランザクションに関与する最後のインタラクションまたはWebページに表示されることをお勧めします。そのため、マルチ相互作用自動化されたロジックは、このフィールドをチェックすることを選択した場合にいつ停止するかについてのヒントを受け取ります。
The information called for by many of these fields is sensitive. It should be protected from unauthorized modification and kept confidential if it is stored in a location or transmitted over a channel where it might otherwise be observed. In addition, the authenticity of the information will be a concern in many systems.
これらのフィールドの多くが求める情報は敏感です。不正な変更から保護され、場所に保存されている場合、または他の方法で観察される可能性のあるチャネル上に送信された場合は、機密を維持する必要があります。さらに、情報の信頼性は多くのシステムで懸念事項になります。
Mechanisms for such protection and authentication are not specified herein but might, depending on circumstances, include object security protocols (such as XMLDSIG [RFC3275], XML encryption [XMLENC], or CMS [RFC3852]), or channel security (such as TLS [RFC2246] or IPSec [RFC2411]). Systems in which an ECML field or fields are stored and later forwarded will likely find object security the most appropriate.
このような保護と認証のメカニズムは本明細書では指定されていませんが、状況に応じて、オブジェクトセキュリティプロトコル（XMLDSIG [RFC3275]、XML暗号化[XMLENC]、またはCMS [RFC3852]など）、またはチャネルセキュリティ（TLSなど）が含まれる場合があります。RFC2246]またはIPSEC [RFC2411]）。ECMLフィールドまたはフィールドが保存され、後で転送されるシステムは、オブジェクトセキュリティが最も適切である可能性があります。
When information is being requested from a user, the user's control over the release of such information is needed to protect the user's privacy.
ユーザーから情報が要求されている場合、ユーザーのプライバシーを保護するために、そのような情報のリリースに対するユーザーの制御が必要です。
Software that is installed on shared or public terminals should be configurable so that memory of any sensitive or individual identity information is fully disabled. This is vital to protect the privacy of library patrons, students, and customers using public terminals, and of children who might, for example, use a form on a public terminal without realizing that their information is being stored.
共有端末またはパブリック端末にインストールされているソフトウェアは、機密情報または個人のアイデンティティ情報のメモリが完全に無効になるように構成可能である必要があります。これは、図書館の常連客、学生、公開ターミナルを使用している顧客、たとえば情報が保存されていることに気付かずに公開ターミナルでフォームを使用する可能性のある子供のプライバシーを保護するために不可欠です。
When sensitive or individual identification information is stored, the operator or user should have an option to protect the information; for example, with a password without which the information will be unavailable, even to someone who has access to the file(s) in which it is being stored.
機密情報または個別識別情報が保存されている場合、オペレーターまたはユーザーには情報を保護するオプションが必要です。たとえば、情報が利用できないパスワードを使用すると、保存されているファイルにアクセスできる人にとっても。
Any multi-page/screen 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フィールドをチェックし、充填がさらに承認されるまで遭遇したときに自動化された塗りつぶしを停止する必要があります。
It should be remembered that default, hidden, and other values transferred to another party may be maliciously modified before being returned.
別の当事者に転送されたデフォルト、非表示、およびその他の値は、返される前に悪意を持って変更される可能性があることを覚えておく必要があります。
The sections below provide for:
以下のセクションでは、次のことを示しています。
1. registration of the ECML v2 XML schema contained in this document,
1. このドキュメントに含まれるECML V2 XMLスキーマの登録、
2. a version URN for ECML versions,
2. ECMLバージョン用のバージョンURN、
3. the subsidiary registration of particular ECML versions and the specific registration of Version 2.0, and
3. 特定のECMLバージョンの子会社登録とバージョン2.0の特定の登録、および
4. three additional IANA registries for elements appearing in three ECML v2 fields.
4. 3つのECML V2フィールドに表示される要素の3つの追加のIANAレジストリ。
The ECML v2 schema give in Section 2.2.2 above is registered as follows:
上記のセクション2.2.2にあるECML V2スキーマは、次のように登録されています。
URI: urn:ietf:params:xml:schema:ECMLv2
Registrant Contact: The IESG <iesg@ietf.org>
XML: The XML Schema in Section 2.2.2 above.
XML：上記のセクション2.2.2のXMLスキーマ。
As specified by the template below from [RFC3553], urn:ietf:params:ecml is permanently registered with sub-registration via RFC publication.
[RFC3553]から以下のテンプレートで指定されているように、urn：IETF：PARAMS：ECMLは、RFC出版物を介してサブ登録に永続的に登録されています。
Registry name: urn:ietf:params:ecml
Specification: RFC 4112
仕様：RFC 4112
Repository: RFC 4112
リポジトリ：RFC 4112
Index value: Values subordinate to urn:ietf:params:ecml are registered by RFC publication. As provided in [RFC3553], once such a value is registered, it may never change.
インデックス値：urnに従属する値：ietf：params：ecmlはRFC出版物によって登録されています。[RFC3553]で提供されているように、そのような値が登録されると、変更されない可能性があります。
The subordinate value "v2.0" is hereby permanently registered so that the URN
下位値「v2.0」は、urnが永久に登録されているため、
urn:ietf:params:ecml:v2.0
is used to indicate an ECML field or fields that conform to this specification. Although it is not anticipated that deeper values subordinate to this URN will need to be registered, if necessary, they are registered by IESG approval.
この仕様に準拠するECMLフィールドまたはフィールドを示すために使用されます。このurに従属するより深い値を登録する必要があることは予想されていませんが、必要に応じて、IESGの承認によって登録されています。
There are three fields described in Section 2.1.2 that require the establishment of IANA registries as described below:
以下に説明するように、IANAレジストリの確立を必要とするセクション2.1.2に記載されている3つのフィールドがあります。
Ecom_Payment_Card_Type A registry of case-insensitive alphanumeric ASCII [ASCII] card-type designations from one to four characters in length with no white space. See Section 2.1.2, Note 11, for the initial 12 designations. Designations are added based on expert approval. Applicants for registration will normally be required already to have an ISO Issuer Identification Number (IIN) or set of IINs.
ECOM_PAYMENT_CARD_TYPE空白のない長さの1〜4文字のケース非感受性の英数字ASCII [ASCII]カードタイプの指定のレジストリ。最初の12の指定については、セクション2.1.2、注11を参照してください。指定は、専門家の承認に基づいて追加されます。通常、登録の申請者は、ISO発行者識別番号（IIN）またはIINのセットを持つために、すでに必要です。
Ecom_Payment_Card_Protocol This field holds a space-separated list of protocols designated by case-insensitive alphanumeric ASCII [ASCII] tokens from this registry or holds the token "none". See Section 2.1.2, note 17, for the initial seven registered tokens (including "none") and further information. Tokens are added to the registry based on expert approval.
ecom_payment_card_protocolこのフィールドには、このレジストリからケース感受性の英数字ASCII [ASCII]トークンによって指定されたプロトコルのスペース分離リストを保持するか、トークンを「なし」に保持します。最初の7つの登録トークン（「なし」を含む）および詳細情報については、セクション2.1.2、注17を参照してください。トークンは、専門家の承認に基づいてレジストリに追加されます。
Ecom_Transaction_Type A case-insensitive alphabetic ASCII [ASCII] value indicating the type of transaction. See Section 2.1.2, note 30, for the initial two registered values. Values are added based on expert approval.
ECOM_TRANSACTION_TYPEトランザクションのタイプを示すケース非感受性アルファベットASCII [ASCII]値。最初の2つの登録値については、セクション2.1.2、注30を参照してください。値は、専門家の承認に基づいて追加されます。
The following, listed is alphabetic order, have contributed to the material herein: Ray Bellis, Steve Bellovin, Scott Hollenbeck, Russ Housley, Jon Parsons, Lauri Piikivi, David Shepherd, and James J. Peter.
以下は、アルファベット順にリストされており、レイベリス、スティーブベロビン、スコットホレンベック、ラスハウズリー、ジョンパーソンズ、ラウリピイキヴィ、デビッドシェパード、ジェームズJ.ピーターなど、この資料に貢献しています。
A. Appendix: Changes from v1.1 to v2
A.付録：V1.1からV2への変更
Substantial rewording of text to change the emphasis from HTML Form Fields to XML Syntax.
HTMLフォームフィールドからXML構文への強調を変更するためのテキストの実質的な言い換え。
Addition of the merchant -> processor fields.
マーチャントの追加 - >プロセッサフィールド。
Addition of the Ecom_Wallet_Location and Ecom_User_Certificate_URL fields.
ECOM_WALLET_LOCATIONおよびECOM_USER_CERTIFIFITATE_URLフィールドの追加。
Addition of the "Mode" attribute.
「モード」属性の追加。
Addition of the ECom_Payment_Card_IssueNumber, Loyalty Card fields, Device ID, Valid From, and User Data fields.
ecom_payment_card_issueNumber、ロイヤルティカードフィールド、デバイスID、有効、ユーザーデータフィールドの追加。
Addition of an XML schema.
XMLスキーマの追加。
Some minor fixes related to telephone numbers.
電話番号に関連するいくつかの小さな修正。
Addition of IANA Considerations section.
IANAの考慮事項の追加セクション。
Updating of RFC references for obsoleted RFCs.
廃止されたRFCのRFC参照の更新。
Normative References
引用文献
[ASCII] USA Standard Code for Information Interchange, X3.4 American National Standards Institute; New York, 1968.
[ASCII]情報交換のためのUSA標準コード、x3.4 American National Standards Institute;ニューヨーク、1968年。
[E.164] ITU-T Recommendation E.164/I.331 (05/97): The International Public Telecommunication Numbering Plan. 1997.
[E.164] ITU-Tの推奨事項E.164/i.331（05/97）：国際的な電気通信番号計画。1997年。
[ISO3166] "Codes for the representation of names of countries and their subdivisions -- Part 1: Country codes", ISO 3166-1, 1997.
[ISO3166]「国の名前とその細分化の表現のためのコード - パート1：国コード」、ISO 3166-1、1997。
[ISO4217] "Codes for the representation of currencies and funds", ISO 4217, 2001.
[ISO4217]「通貨と資金の表現のためのコード」、ISO 4217、2001。
[ISO5218] "Information interchange -- Representation of human sexes", ISO 5218, 1977.
[ISO5218]「情報交換 - 人間の性別の表現」、ISO 5218、1977。
[ISO7812] "Identification card - Identification of issuers - Part 1: Numbering system", ISO 7812-1, 2000.
[ISO7812]「識別カード - 発行者の識別 - パート1：番号付けシステム」、ISO 7812-1、2000。
[ISO8583] "Financial transaction card originated messages - Interchange message specifications - Part 1: Messages, elements and code values", ISO 8583-1, 2001.
[ISO8583]「金融トランザクションカードはメッセージを発信しました - メッセージの仕様を交換する - パート1：メッセージ、要素、コード値」、ISO 8583-1、2001。
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[RFC2045] Freed、N。およびN. Borenstein、「多目的インターネットメールエクステンション（MIME）パート1：インターネットメッセージボディの形式」、RFC 2045、1996年11月。
[RFC3066] Alvestrand, H., "Tags for the Identification of Languages", BCP 47, RFC 3066, January 2001.
[RFC3066] Alvestrand、H。、「言語の識別のためのタグ」、BCP 47、RFC 3066、2001年1月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「ユニフォームリソース識別子（URI）：ジェネリック構文」、STD 66、RFC 3986、2005年1月。
[XML] Extensible Markup Language (XML) 1.0 (Third Edition), Yergeau, F., Bray, T., Paoli, J., Sperberg-McQueen, C. M., Maler, E., and F. Yergeau, February 2004, <http://www.w3.org/TR/REC-xml>.
[XML]拡張可能なマークアップ言語（XML）1.0（第3版）、Yergeau、F.、Bray、T.、Paoli、J.、Sperberg-Mcqueen、C。M.、Maler、E。、およびF. Yergeau、2004年2月、<http://www.w3.org/tr/rec-xml>。
Informative References
参考引用
[eCheck] <http://www.echeck.org>
[HTML] "HTML 3.2 Reference Specification", D. Raggett, January 1997, <http://www.w3.org/TR/REC-html32.html>.
[HTML] "HTML 3.2参照仕様"、D。Raggett、1997年1月、<http://www.w3.org/tr/rec-html32.html>。
[P3P.BASE] "The Platform for Privacy Preferences 1.0 (P3P1.0) Specification", Cranor, L., Langheinrich, M., Marchiori, M., Presler-Marshall, M., and J. Reagle, December 2000, <http://www.w3.org/TR/WD-P3P/>.
[P3P.Base]「プライバシー設定のプラットフォーム1.0（P3P1.0）仕様」、Cranor、L.、Langheinrich、M.、Marchiori、M.、Presler-Marshall、M.、およびJ. Reagle、2000年12月、<http://www.w3.org/tr/wd-p3p/>。
[P3P.ECOM] "Using P3P for E-Commerce", Coco, J., Klien, S., Schutzer, D., Yen, S., and A. Slater, November 1999, <http://www.w3.org/TR/P3P-for-ecommerce>.
[P3P.Ecom]「eコマースにP3Pを使用する」、Coco、J.、Klien、S.、Schutzer、D.、Yen、S。、およびA. Slater、1999年11月、<http：//www.w3.org/tr/p3p-for-ecommerce>。
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[RFC1034] Mockapetris、P。、「ドメイン名 - 概念と施設」、STD 13、RFC 1034、1987年11月。
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[RFC2246] Dierks、T。およびC. Allen、「TLSプロトコルバージョン1.0」、RFC 2246、1999年1月。
[RFC2411] Thayer, R., Doraswamy, N., and R. Glenn, "IP Security Document Roadmap", RFC 2411, November 1998.
[RFC2411] Thayer、R.、Doraswamy、N。、およびR. Glenn、「IP Security Document Roadmap」、RFC 2411、1998年11月。
[RFC2706] Eastlake 3rd, D. and T. Goldstein, "ECML v1: Field Names for E-Commerce", RFC 2706, October 1999.
[RFC2706] Eastlake 3rd、D。およびT. Goldstein、「ECML V1：E-Commerceのフィールド名」、RFC 2706、1999年10月。
[RFC2801] Burdett, D., "Internet Open Trading Protocol - IOTP Version 1.0", RFC 2801, April 2000.
[RFC2801] Burdett、D。、「インターネットオープントレーディングプロトコル-IOTPバージョン1.0」、RFC 2801、2000年4月。
[RFC3106] Eastlake 3rd, D. and T. Goldstein, "ECML v1.1: Field Specifications for E-Commerce", RFC 3106, April 2001.
[RFC3106] EastLake 3rd、D。およびT. Goldstein、「ECML V1.1：eコマースのフィールド仕様」、RFC 3106、2001年4月。
[RFC3275] Eastlake 3rd, D., Reagle, J., and D. Solo, "(Extensible Markup Language) XML-Signature Syntax and Processing", RFC 3275, March 2002.
[RFC3275] EastLake 3rd、D.、Reagle、J。、およびD. Solo、 "（拡張可能なマークアップ言語）XML-Signature構文と処理"、RFC 3275、2002年3月。
[RFC3553] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An IETF URN Sub-namespace for Registered Protocol Parameters", BCP 73, RFC 3553, June 2003.
[RFC3553] Mealling、M.、Masinter、L.、Hardie、T。、およびG. Klyne、「登録プロトコルパラメーターのIETF URNサブネームスペース」、BCP 73、RFC 3553、2003年6月。
[RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852, July 2004.
[RFC3852] Housley、R。、「暗号化メッセージ構文（CMS）」、RFC 3852、2004年7月。
[SET] Secure Electronic Transaction, <http://www.setco.org/set_specifications.html>.
[セット]安全な電子トランザクション、<http://www.setco.org/set_spifications.html>。
[XMLENC] "XML Encryption Syntax and Processing", Eastlake 3rd, D. and J. Reagle, December 2002, <http://www.w3.org/TR/xmlenc-core/>.
[xmlenc] "xml暗号化構文と処理"、Eastlake 3rd、D。and J. Reagle、2002年12月、<http://www.w3.org/tr/xmlenc-core/>。
Author's Address
著者の連絡先
Donald E. Eastlake 3rd Motorola Laboratories 155 Beaver Street Milford, MA 01757 USA
ドナルドE.イーストレイク第3モトローラ研究所155ビーバーストリートミルフォード、マサチューセッツ州01757 USA
Phone: 1-508-786-7554 (work) 1-508-634-2066 (home) EMail: Donald.Eastlake@motorola.com
電話：1-508-786-7554（作業）1-508-634-2066（ホーム）メール：donald.eastlake@motorola.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（2005）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。