summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc2706.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc2706.txt')
-rw-r--r--doc/rfc/rfc2706.txt731
1 files changed, 731 insertions, 0 deletions
diff --git a/doc/rfc/rfc2706.txt b/doc/rfc/rfc2706.txt
new file mode 100644
index 0000000..149704f
--- /dev/null
+++ b/doc/rfc/rfc2706.txt
@@ -0,0 +1,731 @@
+
+
+
+
+
+
+Network Working Goup D. Eastlake
+Request for Comments: 2706 IBM
+Category: Informational T. Goldstein
+ Brodia
+ October 1999
+
+
+ ECML v1: Field Names for E-Commerce
+
+
+Status of this Memo
+
+ This memo provides information for the Internet community. It does
+ not specify an Internet standard of any kind. Distribution of this
+ memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (1999). All Rights Reserved.
+
+IESG Note
+
+ 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.
+
+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.
+
+
+
+
+
+
+
+
+
+
+
+Eastlake & Goldstein Informational [Page 1]
+
+RFC 2706 ECom Field Names October 1999
+
+
+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
+
+1. Introduction
+
+1.1 Background
+
+ 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.
+
+ 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
+
+
+
+Eastlake & Goldstein Informational [Page 2]
+
+RFC 2706 ECom Field Names October 1999
+
+
+ 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.
+
+ 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:
+
+ 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
+
+ <http://www.w3.org/TR/WD-P3P/basedata.html>.
+
+1.2 Relationship to Other Standards
+
+ 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 may be used with any payment mechanism. It simply allows a
+ merchant to publish consistent simple web forms.
+
+ Multiple wallets and multiple merchants plan to interoperably support
+ ECML. This is an open standard. ECML is designed to be simple.
+
+
+
+Eastlake & Goldstein Informational [Page 3]
+
+RFC 2706 ECom Field Names October 1999
+
+
+ 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.3 Areas Deferred to Future Versions
+
+ 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.
+
+2. Using The Fields
+
+ 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.
+
+2.1 Presentation of the Fields
+
+ 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.
+
+ 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.
+
+
+
+
+
+
+
+
+Eastlake & Goldstein Informational [Page 4]
+
+RFC 2706 ECom Field Names October 1999
+
+
+2.2 Methods and Flow of Setting the Fields
+
+ 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].
+
+ 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.
+
+ 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 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake & Goldstein Informational [Page 5]
+
+RFC 2706 ECom Field Names October 1999
+
+
+2.3 HTML Example
+
+ An example in HTML 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
+ <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>
+
+
+
+
+
+
+
+Eastlake & Goldstein Informational [Page 6]
+
+RFC 2706 ECom Field Names October 1999
+
+
+3. Field Definitions
+
+ 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.
+
+ 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
+
+
+
+Eastlake & Goldstein Informational [Page 7]
+
+RFC 2706 ECom Field Names October 1999
+
+
+ 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)
+
+ card protocols Ecom_Payment_Card_Protocol 20 (17)
+
+ consumer order ID Ecom_ConsumerOrderID 20 (18)
+
+ schema version Ecom_SchemaVersion 30 (19)
+
+ end transaction flag 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
+
+
+
+
+
+Eastlake & Goldstein Informational [Page 8]
+
+RFC 2706 ECom Field Names October 1999
+
+
+ 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.
+
+4. End Notes
+
+ ( 1) For example: Mr., Mrs., Ms., Dr. This field is commonly not
+ used.
+
+ ( 2) May also be used for middle initial
+
+ ( 3) For example: Ph.D., Jr. (Junior), 3rd, Esq. (Esquire). This
+ field is commonly not used.
+
+ ( 4) Address lines must be filled in the order line1, then line2,
+ last line3.
+
+ ( 5) 2 characters are the minimum for the US and Canada, other
+ countries may require longer fields. For the US use 2 character
+ US Postal state abbreviation.
+
+ ( 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.
+
+ ( 7) Use [ISO 3166] standard two letter codes
+ <http://www.din.de/gremien/nas/nabd/iso3166ma/codlstp1.html> for
+ country names.
+
+ ( 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.
+
+ ( 9) For example: jsmith@example.com
+
+ (10) The name of the cardholder.
+
+
+
+
+Eastlake & Goldstein Informational [Page 9]
+
+RFC 2706 ECom Field Names October 1999
+
+
+ (11) Use the first 4 letters of the association name: American
+ Express=AMER; Diners Club=DINE; 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.
+
+ (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.
+
+ (14) The day of the month. Values: 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, ...
+
+ (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.
+
+ (18) A unique order ID generated by the consumer software.
+
+ (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.
+
+ (20) A flag to indicate that this web-page/aggregate is the final one
+ for this transaction. Usually a hidden field.
+
+5. Security Considerations
+
+ 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.
+
+
+
+
+Eastlake & Goldstein Informational [Page 10]
+
+RFC 2706 ECom Field Names October 1999
+
+
+ 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.
+
+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 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.
+
+ IOTP - Internet Open Trading Protocol, being specified in the
+ IETF TRADE working group, D. Burdett
+
+ 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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake & Goldstein Informational [Page 11]
+
+RFC 2706 ECom Field Names October 1999
+
+
+Authors' Addresses
+
+ Donald E. Eastlake, 3rd
+ IBM, J1-N63
+ 17 Skyline Drive
+ Hawthorne, NY 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
+
+ Phone: +1 415-495-3100 x222
+ Fax: +1 415-495-3177
+ EMail: tgoldstein@brodia.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake & Goldstein Informational [Page 12]
+
+RFC 2706 ECom Field Names October 1999
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (1999). 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 13]
+