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://<host>:<port>/<path>?<common-name>[;<attribute>=<value>]*
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:<common-name>[;<attribute>=<value>]*
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]