doc: Add RFC documents

1 files changed, 451 insertions, 0 deletions

diff --git a/doc/rfc/rfc3368.txt b/doc/rfc/rfc3368.txt
new file mode 100644
index 0000000..165b0c6
--- /dev/null
+++ b/doc/rfc/rfc3368.txt
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+Network Working Group                                        M. Mealling
+Request for Comments: 3368                                VeriSign, Inc.
+Category: Standards Track                                    August 2002
+
+
+      The 'go' URI Scheme for the Common Name Resolution Protocol
+
+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.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2002).  All Rights Reserved.
+
+Abstract
+
+   This document defines a URI scheme, 'go:' to be used with the Common
+   Name Resolution Protocol.  Specifically it lays out the syntactic
+   components and how those components are used by URI Resolution to
+   find the available transports for a CNRP service.  Care should be
+   taken with several of the URI components because, while they may look
+   like components found in other URI schemes, they often do not act
+   like them.  The "go" scheme has more in common with the location
+   independent "news" scheme than any other URI scheme.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mealling                    Standards Track                     [Page 1]
+
+RFC 3368                CNRP URI Specification               August 2002
+
+
+Table of Contents
+
+   1.    Goals  . . . . . . . . . . . . . . . . . . . . . . . . . . .  2
+   2.    Terminology  . . . . . . . . . . . . . . . . . . . . . . . .  2
+   3.    Syntax Rules . . . . . . . . . . . . . . . . . . . . . . . .  3
+   3.1   General Syntax . . . . . . . . . . . . . . . . . . . . . . .  3
+   3.2   ABNF Grammar . . . . . . . . . . . . . . . . . . . . . . . .  3
+   3.3   Special Cases and Default Values . . . . . . . . . . . . . .  4
+   3.3.1 If There is Only a Server  . . . . . . . . . . . . . . . . .  4
+   3.3.2 If Server is Empty Then server=localhost . . . . . . . . . .  4
+   3.3.3 Default Port . . . . . . . . . . . . . . . . . . . . . . . .  4
+   3.4   Encoding Rules . . . . . . . . . . . . . . . . . . . . . . .  4
+   4.    Transport Independence . . . . . . . . . . . . . . . . . . .  4
+   5.    Examples . . . . . . . . . . . . . . . . . . . . . . . . . .  4
+   6.    Security Considerations  . . . . . . . . . . . . . . . . . .  5
+   7.    IANA Considerations  . . . . . . . . . . . . . . . . . . . .  5
+         References . . . . . . . . . . . . . . . . . . . . . . . . .  6
+   A.    Registration Template  . . . . . . . . . . . . . . . . . . .  7
+         Author's Address . . . . . . . . . . . . . . . . . . . . . .  7
+         Full Copyright Statement . . . . . . . . . . . . . . . . . .  8
+
+1. Goals
+
+   The two goals of the CNRP [3] URI [1] are to identify both a specific
+   common-name record at a specific server and to identify a possibly
+   dynamic query or entry point into the query process.  Since CNRP
+   requires that the ID be a core query term, these two cases can be
+   generalized down to simply specifying a query that contains only the
+   ID of the item.
+
+   On first glance it would seem a simple enough exercise to
+   canonicalize the XML encoded query and then insert it into the query
+   portion of the URL.  The problem here is that, due to the encoding
+   rules, any remotely complex query will quickly blow out the URI
+   length limitations.  The suggested solution is to provide a
+   simplified query syntax that is a subset of what is available via the
+   XML.
+
+2. Terminology
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119 [4].
+
+
+
+
+
+
+
+
+Mealling                    Standards Track                     [Page 2]
+
+RFC 3368                CNRP URI Specification               August 2002
+
+
+3. Syntax Rules
+
+3.1 General Syntax
+
+   The CNRP URI comes in two forms.  The first form is for talking to a
+   specific server.  The second form is for expressing a query that is
+   meant to be sent to several different CNRP services.  The following
+   two examples are for pedagogical purposes only.  The complete ABNF
+   grammar in Section 3.2 is the only authoritative syntax definition.
+
+   go://[<host>]?[<common-name>]*[;<attribute>=[<type>,]<value>]
+
+   and
+
+   go:<common-name>*[;<attribute>=[<type>,]<value>]
+
+3.2 ABNF Grammar
+
+   The full ABNF [2] (certain values are included by reference from RFC
+   2396 [1]):
+
+   cnrp-uri      = "go:" (form1 / form2)
+   form1         = "//" [server] ["?" ((common-name *avpair) / id-req) ]
+   form2         = common-name *avpair
+
+   id-req        = "id=" value
+   avpair        = ";" attribute "=" [ type "," ] value
+
+   server        = // as specified in RFC2396
+
+   common-name     = *(unreserved | escaped)
+   attribute       = *(unreserved | escaped)
+   value           = *(unreserved | escaped)
+   type            = *(unreserved | escaped)
+
+   unreserved      = // as specified in RFC2396
+
+   escaped       = "%" hex hex
+   hex           = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" |
+                   "8" | "9" | "A" | "B" | "C" | "D" | "E" | "F" |
+                   "a" | "b" | "c" | "d" | "e" | "f"
+
+
+
+
+
+
+
+
+
+
+Mealling                    Standards Track                     [Page 3]
+
+RFC 3368                CNRP URI Specification               August 2002
+
+
+3.3 Special Cases and Default Values
+
+3.3.1 If There is Only a Server
+
+   In the case where the CNRP URI contains only the server production
+   then the URI identifies a given CNRP server, not any particular query
+   that is to be done.  A client can assume that this server will at
+   least answer the 'servicequery' request.
+
+3.3.2 If Server is Empty Then server=localhost
+
+   If the 'server' element has no value then its value MUST be assumed
+   to be "localhost".
+
+3.3.3 Default Port
+
+   CNRP's well known HTTP transport port is 1096.  If the port value
+   portion of the server production is not specified then port 1096
+   SHOULD be used if the client has no prior knowledge about other ports
+   or transports that the service may support.
+
+3.4 Encoding Rules
+
+   The common-name, query parameters, and parameter values must be
+   encoded using the UTF-8 encoding scheme [5], and any octet that is
+   not one of the permitted characters per the above grammar MUST
+   instead be represented by a "%" followed by two characters from the
+   <hex> character set above.  The two characters give the hexadecimal
+   representation of that octet.
+
+4. Transport Independence
+
+   As stated in the CNRP protocol specification [3], CNRP is allowed to
+   be expressed over multiple transport protocols with HTTP being
+   mandatory to implement.  In the case where a client attempts to
+   resolve a CNRP URI and it knows nothing about the service being
+   referenced in that URI, then it SHOULD use HTTP on the CNRP default
+   port (1096).
+
+5. Examples
+
+   go:Mercedes%20Benz
+      This example shows a general query for the common-name "Mercedes
+      Benz".  The intent is that the query should be packaged with any
+      client provided defaults and sent to the one or more services that
+      the client has configured to ask.
+
+
+
+
+
+Mealling                    Standards Track                     [Page 4]
+
+RFC 3368                CNRP URI Specification               August 2002
+
+
+   go://?Mercedes%20Benz
+      This example shows a general query for the common-name "Mercedes
+      Benz" that is sent to the server running on the 'localhost'.
+
+   go://cnrp.foo.com?Mercedes%20Benz;geography=US-ga
+      This example shows a query for the common-name "Mercedes Benz" in
+      the geographic area "US-ga" which should be sent to the server
+      found at cnrp.foo.com.
+
+   go://cnrp.foo.org?Martin%20J.%20D%C3%BCrst
+      This example includes a UTF-8 character encoded using hex
+      escaping.  The value encoded is a u-umlaut (a 'u' with two dots
+      over it).  This simple query is sent to a server found at
+      cnrp.foo.org with no parameters.
+
+   go://cnrp.foo.com?id=5432345
+      Here only an id is given which means that his example points
+      directly at a particular common-name record on a particular
+      server.  This example would probably be found in a link on a web
+      page of some type.
+
+6. Security Considerations
+
+   In addition to the security considerations inherent in CNRP itself
+   (see the Security Considerations section of RFC 3367 [3]), the URI
+   mechanism can also be used to retrieve a URI identifying some other
+   site by including just the ID and not the common-name being linked
+   to.  I.e., the user may think he/she is being shown the URI currently
+   mapped to the "BMW" common-name but in the case where only the ID is
+   used the actual common-name is not part of the URI, thus making it
+   possible to use a CNRP URI without knowing which common-name it is
+   referring to.
+
+7. IANA Considerations
+
+   The IANA is asked to register the URL registration template found in
+   Appendix A in accordance with RFC 2717 [6].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mealling                    Standards Track                     [Page 5]
+
+RFC 3368                CNRP URI Specification               August 2002
+
+
+References
+
+   [1]  Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource
+        Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
+
+   [2]  Crocker, D., "Augmented BNF for Syntax Specifications: ABNF",
+        RFC 2234, November 1997.
+
+   [3]  Popp, N., Mealling, M. and M. Moseley, "Common Name Resolution
+        Protocol (CNRP)", RFC 3367, August 2002.
+
+   [4]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
+        Levels", BCP 14, RFC 2119, March 1997.
+
+   [5]  The Unicode Consortium, "The Unicode Standard, Version 2.0:
+        Appendix A.2", ISBN 0-201-48345-9, January 1988.
+
+   [6]  Petke, R. and I. King, "Registration Procedures for URL Scheme
+        Names", BCP 35, RFC 2717, November 1999.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mealling                    Standards Track                     [Page 6]
+
+RFC 3368                CNRP URI Specification               August 2002
+
+
+Appendix A. Registration Template
+
+   URL scheme name: go
+
+   URL scheme syntax: Section 3.2
+
+   Character encoding considerations: Section 3.4
+
+   Intended usage: Section 1
+
+   Applications and/or protocols which use this scheme: [3]
+
+   Interoperability considerations: None not specified in [3]
+
+   Security considerations: Section 6
+
+   Relevant publications: [3]
+
+   Contact: CNRP Working Group
+
+   Author/Change Controller: IESG
+
+Author's Address
+
+   Michael Mealling
+   VeriSign, Inc.
+   21345 Ridgetop Circle
+   Dulles, VA  20170
+   US
+
+   Phone: (703) 742-0400
+   EMail: michael@verisignlabs.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mealling                    Standards Track                     [Page 7]
+
+RFC 3368                CNRP URI Specification               August 2002
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2002).  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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mealling                    Standards Track                     [Page 8]
+