doc: Add RFC documents

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