Network Working Group M. Mealling Internet-Draft NSI Expires: May 31, 2000 December 1999 A URI Scheme for the Common Name Resolution Protocol draft-ietf-cnrp-uri-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 31, 2000. Copyright Notice Copyright (C) The Internet Society (1999). All Rights Reserved. Abstract This document defines a URI scheme 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 CNRP scheme has more in common with the location independent "news" scheme than any other URI scheme. Mealling Expires May 31, 2000 [Page 1] Internet-Draft CNRP URI Specification December 1999 Table of Contents 1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Syntax Rules . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Transport Independency with URI Resolution . . . . . . . . . . . 5 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 A. Registration Template . . . . . . . . . . . . . . . . . . . . . 7 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 8 Mealling Expires May 31, 2000 [Page 2] Internet-Draft CNRP URI Specification December 1999 1. Goals The two main goals of the CNRP URI 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 by only specifying the ID of the item in the URI. On first glance it would seem a simple enough excercize to simply 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. Another problem is that, since CNRP is transport independent, the actual transport protocol cannot be encoded into the URI. Requiring a client to send mail to an SMTP transport just to find out if an HTTP transport is available is unacceptable. The suggested solution here is to use URI resolution to find out the available transports for a given service. NOTE: The use of the NAPTR record described below is simply one solution. The working group is encouraged to look at this issue and make the determination that 'transport discovery' is worth the price of admission. At this point the author only sees three solutions: 1. remove CNRP's transport independence and only have one protocol 2. put the transport protocol in the URI 3. use DNS or some other method to discovery the transport method Mealling Expires May 31, 2000 [Page 3] Internet-Draft CNRP URI Specification December 1999 2. Syntax Rules The CNRP URI comes in two forms: cnrp://:/?[;=]* where: host The domain-name to contact port The port on which to contact the host path The path or any other information needed to specifically identify the query endpoint common-name The common-name itself attribute One half of a possible series of attribute/value pairs value the other half and cnrp:[;=]* where: common-name The common-name itself attribute Same as above value Same as above Mealling Expires May 31, 2000 [Page 4] Internet-Draft CNRP URI Specification December 1999 3. Transport Independency with URI Resolution In order to discover the available transport methods for a given CNRP server, the client should use the URI Resolution algorithm to locate the NAPTR records for the domain in question. Then, via the Services and subsequent SRV records, the client will know all of the available servers in a way that also provides robust caching via DNS. The sequence of events looks like this: 1. The client requests the NAPTR for the domain "cnrp.uri.net". 2. The result will be two rules: 1. cnrp.uri.net 0 0 "p" "" "/cnrp:[/]^" 2. cnrp.uri.net 0 0 "" "" "/cnrp://(.*):([0-9]*)(.*)?.*$/$1/" . 3. The first rule states that if there is no host:port section then the rest of the algorithm is protocol specific. In the CNRP case this means that the client should consult its own configuration for what server(s) to query and how. 4. The client applies both rules. If the second matches then the rule states that the client should use the host portion as the new key and start the NAPTR looping algorithm over again. 5. The second time through the loop the client will request a NAPTR record for the domain found in the URI. This NAPTR record will contain a set of flags and services fields that determine if there are subsequent delegations. It is expected that the normal case is that this NAPTR lookup will be the terminal one. 6. If this is the terminal lookup then the protocol should be listed in the first part of the Services field. The only service that should be listed is the I2C service. The Flags field should contain the character "S" which means an SRV lookup should be done for the domain-name in the Replacement field. This should return a series of records containing the actual hostname and port number to be used. Since each record returned by the DNS must have a Time To Live (TTL), the information used in the above sequence should be very cacheable. As stated in the URI Resolution documents, the two rules in the uri.net zone should have a very long TTL since they do not change. Mealling Expires May 31, 2000 [Page 5] Internet-Draft CNRP URI Specification December 1999 4. Examples Author's Address Michael Mealling Network Solutions, Inc. Mealling Expires May 31, 2000 [Page 6] Internet-Draft CNRP URI Specification December 1999 Appendix A. Registration Template Mealling Expires May 31, 2000 [Page 7] Internet-Draft CNRP URI Specification December 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 implmentation 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 Expires May 31, 2000 [Page 8]