rfc3106.txt
来自「RFC 的详细文档！」· 文本 代码 · 共 1,124 行 · 第 1/3 页
TXT
1,124 行
a hidden field, be included on every web page that has any Ecom
fields.
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.
Merchant requests for information can extend over several
interactions or web pages. Without further provision, a facility
could either require re-starting on each page or possibly violate or
appear to violate privacy by continuing to fill in fields for pages
beyond with end of the transaction with a particular merchant. For
this reason the Ecom_TransactionComplete field, which is normally
hidden, is provided. It is recommended that it appear on the last
interaction or web page involved in a transaction, just before an
Ecom_SchemaVersion field, so that multi-web-page automated field fill
in logic could know when to stop if it chooses to check for this
field.
3.3 HTML Example
An example HTML form might be as follows:
<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
Eastlake & Goldstein Informational [Page 14]
RFC 3106 ECom Field Names April 2001
<INPUT type="text" name="Ecom_Payment_Card_Name" SIZE=40>
<br>The card number
<INPUT type="text" name="Ecom_Payment_Card_Number" SIZE=19>
<br>Expiration date (MM YY)
<INPUT type="text" name="Ecom_Payment_Card_ExpDate_Month" SIZE=2>
<INPUT type="text" name="Ecom_Payment_Card_ExpDate_Year" SIZE=4>
<INPUT type="hidden" name="Ecom_Payment_Card_Protocol">
<INPUT type="hidden" name="Ecom_SchemaVersion"
value="http://www.ecml.org/version/1.1">
<br>
<INPUT type="submit" value="submit"> <INPUT type="reset">
</FORM>
</BODY>
</HTML>
After all of the pages are submitted, the merchant will reply with a
confirmation page informing both the user and the wallet that the
transaction is complete.
<HTML>
<HEAD>
<title> eCom Transaction Complete Example </title>
</HEAD>
<BODY>
<FORM>
Thank you for your order. It will be shipped in several days.
<INPUT type="hidden" name="Ecom_Merchant" value="www.merchant.example">
<INPUT type="hidden" name ="Ecom_Processor"
value="www.processor.example">
<INPUT type="hidden" name="Ecom_Transaction_ID" value="EF123456">
<INPUT type="hidden" name="Ecom_Transaction_Inquiry"
value="http://www.merchant.example/cgi-bin/inquire?ID=EF123456">
<INPUT type="hidden" name="Ecom_Transaction_Amount" value="789.00">
<INPUT type="hidden" name="Ecom_Transaction_Currency" value="USD">
<INPUT type="hidden" name="Ecom_Transaction_Date" value="July 14 2000">
<INPUT type="hidden" name="Ecom_Transaction_Type" value="credit">
<INPUT type="hidden" name="Ecom_Transaction_Signature"
value="ig6rh4;;20dfna00s34hj10s--s-45j30-22z92l-frwds-85">
<INPUT type="hidden" name="Ecom_TransactionComplete">
<INPUT type="hidden" name="Ecom_SchemaVersion"
value="http://www.ecml.org/version/1.1">
</FORM>
</BODY>
</HTML>
Eastlake & Goldstein Informational [Page 15]
RFC 3106 ECom Field Names April 2001
4. Security and Privacy Considerations
The information called for by many of these fields is sensitive and
should be secured if being sent over the public Internet or through
other channels where it can be observed. Mechanisms for such
protection are not specified herein but channel encryption such as
TLS/SSL [RFC 2246] or IPSec [RFC 2411] would be appropriate in many
cases.
User control over release of such information is needed to protect
the user's privacy.
A wallet that is installed on a shared or public terminal should be
configurable such that the ECML memory of address and other contact
information is fully disabled. This is vital to protect the privacy
of library patrons, students, and customers using public terminals,
and children who might, for example, use a form on a public terminal
without realizing that their information is being stored.
When contact information is stored, the operator should have an
option to protect the information with a password, without which the
information might be unavailable, even to someone who has access to
the file(s) in which it is being stored. This would also allow for a
convenient method for multiple people to use their own ECML
information from the same browser.
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.
References
[eCheck] <http://www.echeck.org>
[HTML] HTML 3.2 Reference Specification
<http://www.w3.org/TR/REC-html32.html>, D. Raggett,
January 1997.
[IANA] Internet Assigned Numbers Authority, Official Names for
Character Sets, ed. Keld Simonsen et al.
<ftp://ftp.isi.edu/in-notes/iana/assignments/character-
sets>.
[ISO 3166] Codes for the representation of names of countries,
<http://www.din.de/gremien/nas/nabd/iso3166ma>
Eastlake & Goldstein Informational [Page 16]
RFC 3106 ECom Field Names April 2001
[ISO 7812] "Identification card - Identification of issuers - Part 1:
Numbering system".
[RFC 1766] Alvestrand, H., "Tags for the Identification of
Languages", BCP 47, RFC 3066, January 2001.
[RFC 2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996.
[RFC 2246] Dierks, T. and C. Allen, "The TLS Protocol: Version 1.0",
RFC 2246, January 1999.
[RFC 2411] Thayer, R., Doraswany, N. and R. Glenn, "IP Security:
Document Roadmap", RFC 2411, November 1998.
[RFC 2706] Eastlake, D. and T. Goldstein, "ECML v1: Field Names for
E-Commerce", RFC 2706, September 1999.
[RFC 2801] Burdett, D., "Internet Open Trading Protocol - IOTP
Version 1.0", RFC 2801, April 2000.
[SET] Secure Electronic Transaction,
<http://www.setco.org/set_specifications.html>
[XML] Extensible Markup Language (XML) 1.0 (Second Edition),
<http://www.w3.org/TR/REC-xml>, T. Bray, J. Paoli, C. M.
Sperberg-McQueen, E. Maler.
Eastlake & Goldstein Informational [Page 17]
RFC 3106 ECom Field Names April 2001
Appendix: Changes from ECML 1.0
ECML 1.0 is documented in [RFC 2706].
(1) Fields added for consumer to merchant transmission as listed
below. * indicated multiple values. Adding fields is a backward
compatible change.
Ecom_*_Postal_Company
Ecom_User_ID
Ecom_User_Password
Ecom_WalletID
(2) Change Ecom_SchemaVersion field value to
"http://www.ecml.org/version/1.1".
(3) Addition of XML DTD.
(4) Add "iotp", "echeck", "simcard", and "phoneid" as allowed tokens
in Ecom_Payment_Card_Protocol.
(5) Specify that a leading zero is permitted in day and month number
fields.
(6) Change "Security Considerations" section to "Security and Privacy
Considerations" and add material.
(7) Add internationalization material to HTML and XML subsections of
Section 2.
(8) Enumerate HTML form elements that must be supported (Section 2.2)
including SELECT.
(9) Add more credit card brand codes.
(10) Add fields for merchant to consumer transmissions as follows:
Ecom_Merchant
Ecom_Processor
Ecom_Transaction_*
Eastlake & Goldstein Informational [Page 18]
RFC 3106 ECom Field Names April 2001
Authors' Addresses
Donald E. Eastlake, 3rd
Motorola, M2-450
20 Cabot Boulevard
Mansfield, MA 02048
Phone: +1-508-261-5434
Fax: +1-508-261-4447
EMail: Donald.Eastlake@motorola.com
Ted Goldstein
Brodia
221 Main Street, Suite 1530
San Francisco, CA 94105 USA
Phone: +1 415-495-3100 x222
Fax: +1 415-495-3177
EMail: tgoldstein@brodia.com
Eastlake & Goldstein Informational [Page 19]
RFC 3106 ECom Field Names April 2001
Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved.
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.
Eastlake & Goldstein Informational [Page 20]
⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?