doc: Add RFC documents

1 files changed, 1011 insertions, 0 deletions

diff --git a/doc/rfc/rfc3404.txt b/doc/rfc/rfc3404.txt
new file mode 100644
index 0000000..19b6dc1
--- /dev/null
+++ b/doc/rfc/rfc3404.txt
@@ -0,0 +1,1011 @@
+
+
+
+
+
+
+Network Working Group                                        M. Mealling
+Request for Comments: 3404                                      VeriSign
+Obsoletes: 2915, 2168                                       October 2002
+Category: Standards Track
+
+
+              Dynamic Delegation Discovery System (DDDS)
+           Part Four: The Uniform Resource Identifiers (URI)
+                         Resolution Application
+
+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 describes a specification for taking Uniform Resource
+   Identifiers (URI) and locating an authoritative server for
+   information about that URI.  The method used to locate that
+   authoritative server is the Dynamic Delegation Discovery System.
+
+   This document is part of a series that is specified in "Dynamic
+   Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS"
+   (RFC 3401).  It is very important to note that it is impossible to
+   read and understand any document in this series without reading the
+   others.
+
+Table of Contents
+
+   1.    Introduction . . . . . . . . . . . . . . . . . . . . . . . .  2
+   2.    Terminology  . . . . . . . . . . . . . . . . . . . . . . . .  3
+   3.    The Distinction between URNs and URIs  . . . . . . . . . . .  3
+   4.    The URI and URN Resolution Application Specifications  . . .  4
+   4.1   Application Unique String  . . . . . . . . . . . . . . . . .  4
+   4.2   First Well Known Rule  . . . . . . . . . . . . . . . . . . .  4
+   4.3   Flags  . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
+   4.4   Services Parameters  . . . . . . . . . . . . . . . . . . . .  5
+   4.4.1 Services . . . . . . . . . . . . . . . . . . . . . . . . . .  6
+   4.4.2 protocols  . . . . . . . . . . . . . . . . . . . . . . . . .  6
+   4.4.3 Applicability of Services  . . . . . . . . . . . . . . . . .  7
+
+
+
+Mealling                    Standards Track                     [Page 1]
+
+RFC 3404               DDDS Based URI Resolution            October 2002
+
+
+   4.5   Valid Databases  . . . . . . . . . . . . . . . . . . . . . .  7
+   5.    Examples . . . . . . . . . . . . . . . . . . . . . . . . . .  8
+   5.1   An example using a URN . . . . . . . . . . . . . . . . . . .  8
+   5.2   CID URI Scheme Example . . . . . . . . . . . . . . . . . . .  9
+   5.3   Resolving an HTTP URI Scheme . . . . . . . . . . . . . . . . 11
+   6.    Notes  . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
+   7.    IANA Considerations  . . . . . . . . . . . . . . . . . . . . 12
+   8.    Security Considerations  . . . . . . . . . . . . . . . . . . 12
+   9.    Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . 13
+         References . . . . . . . . . . . . . . . . . . . . . . . . . 13
+         Appendix A: Pseudo Code  . . . . . . . . . . . . . . . . . . 15
+         Author's Address . . . . . . . . . . . . . . . . . . . . . . 17
+         Full Copyright Statement . . . . . . . . . . . . . . . . . . 18
+
+1. Introduction
+
+   The Dynamic Delegation Discovery System (DDDS) is used to implement
+   lazy binding of strings to data, in order to support dynamically
+   configured delegation systems.  The DDDS functions by mapping some
+   unique string to data stored within a DDDS Database by iteratively
+   applying string transformation rules until a terminal condition is
+   reached.
+
+   This document describes a DDDS Application for resolving Uniform
+   Resource Identifiers (URI).  It does not define the DDDS Algorithm or
+   a Database.  The entire series of documents that do so are specified
+   in "Dynamic Delegation Discovery System (DDDS) Part One: The
+   Comprehensive DDDS" (RFC 3401) [1].  It is very important to note
+   that it is impossible to read and understand any document in that
+   series without reading the related documents.
+
+   Uniform Resource Identifiers (URI) have been a significant advance in
+   retrieving Internet-accessible resources.  However, their brittle
+   nature over time has been recognized for several years.  The Uniform
+   Resource Identifier working group proposed the development of Uniform
+   Resource Names (URN) [8] to serve as persistent, location-independent
+   identifiers for Internet resources in order to overcome most of the
+   problems with URIs.  RFC 1737 [6] sets forth requirements on URNs.
+
+   During the lifetime of the URI-WG, a number of URN proposals were
+   generated.  The developers of several of those proposals met in a
+   series of meetings, resulting in a compromise known as the Knoxville
+   framework.  The major principle behind the Knoxville framework is
+   that the resolution system must be separate from the way names are
+   assigned.  This is in marked contrast to most URIs, which identify
+   the host to contact and the protocol to use.  Readers are referred to
+   [7] for background on the Knoxville framework and for additional
+   information on the context and purpose of this proposal.
+
+
+
+Mealling                    Standards Track                     [Page 2]
+
+RFC 3404               DDDS Based URI Resolution            October 2002
+
+
+   Separating the way names are resolved from the way they are
+   constructed provides several benefits.  It allows multiple naming
+   approaches and resolution approaches to compete, as it allows
+   different protocols and resolvers to be used.  There is just one
+   problem with such a separation - how do we resolve a name when it
+   can't give us directions to its resolver?
+
+   For the short term, the Domain Name System (DNS) is the obvious
+   candidate for the resolution framework, since it is widely deployed
+   and understood.  However, it is not appropriate to use DNS to
+   maintain information on a per-resource basis.  First of all, DNS was
+   never intended to handle that many records.  Second, the limited
+   record size is inappropriate for catalog information.  Third, domain
+   names are not appropriate as URNs.
+
+   Therefore our approach is to use the DDDS to locate "resolvers" that
+   can provide information on individual resources, potentially
+   including the resource itself.  To accomplish this, we "rewrite" the
+   URI into a Key following the rules found in the DDDS.  This document
+   describes URI Resolution as an application of the DDDS and specifies
+   the use of at least one Database based on DNS.
+
+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.
+
+   All capitalized terms are taken from the vocabulary found in the DDDS
+   algorithm specification found in RFC 3403 [3].
+
+3. The Distinction Between URNs and URIs
+
+   From the point of view of this system, there is no theoretical
+   difference between resolving URIs in the general case and URNs in the
+   specific case.  Operationally however, there is a difference that
+   stems from URI resolution possibly not becoming of widespread use.
+   If URN resolution is collapsed into generic URI resolution, URNs may
+   suffer by the lack of adoption of URI resolution.
+
+   The solution is to allow for shortcutting for URN resolution.  In the
+   following specification generic URI resolution starts by inserting
+   rules for known URI schemes into the 'uri.arpa.' registry.  For the
+   'URN:' URI scheme, one of the rules found in 'uri.arpa.' would be for
+   the 'urn' URI scheme.  This rule would simply delegate to the
+   'urn.arpa.' zone for additional NAPTRs based on the URN namespace.
+   Essentially, the URI Resolution Rewrite Rule for 'URN:' is the URN
+   Resolution Application's First Well Known Rule.
+
+
+
+Mealling                    Standards Track                     [Page 3]
+
+RFC 3404               DDDS Based URI Resolution            October 2002
+
+
+   Therefore, this document specifies two DDDS Applications.  One is for
+   URI Resolution and the other is for URN Resolution.  Both are
+   technically identical but by separating the two URN Resolution can
+   still proceed without the dependency.
+
+4. The URI and URN Resolution Application Specifications
+
+   This template defines the URI and URN Resolution DDDS Application
+   according to the rules and requirements found in [3].  The DDDS
+   database used by this Application is found in [4] which is the
+   document that defines the Naming Authority Pointer (NAPTR) DNS
+   Resource Record (RR) type.
+
+4.1 Application Unique String
+
+   The Application Unique String is the URI or URN for which an
+   authoritative server is being located.  This URI or URN MUST be
+   canonicalized and hex encoded according to the "absolute-uri"
+   production found in the Collected ABNF from RFC 2396 [15].
+
+4.2 First Well Known Rule
+
+   In the URI case, the first known key is created by taking the URI
+   scheme.  In the URN case, the first known key is the Namespace
+   Identifier.  For example, the URI 'http://www.example.com/' would
+   have a 'http' as its Key.  The URN 'urn:foo:foospace' would have
+   'foo' as its first Key.
+
+4.3 Flags
+
+   At this time only four flags, "S", "A", "U", and "P", are defined.
+   The "S", "A" and "U" flags are for a terminal lookup.  This means
+   that the Rule is the last one and that the flag determines what the
+   next stage should be.  The "S" flag means that the output of this
+   Rule is a domain-name for which one or more SRV [9] records exist.
+   See Section 5 for additional information on how URI and URN
+   Resolution use the SRV record type.  "A" means that the output of the
+   Rule is a domain-name and should be used to lookup either A, AAAA, or
+   A6 records for that domain.  The "U" flag means that the output of
+   the Rule is a URI [15].
+
+   The "P" flag says that the remainder of the DDDS Algorithm is ignored
+   and that the rest of the process is application specific and outside
+   the scope of this document.  An application can use the Protocol part
+   found in the Services field to identify which Application specific
+   set of rules that should be followed next.  The record that contains
+   the 'P' flag is the last record that is interpreted by the rules in
+   this document.  One might think that this would also make the "P"
+
+
+
+Mealling                    Standards Track                     [Page 4]
+
+RFC 3404               DDDS Based URI Resolution            October 2002
+
+
+   flag an indicator of a terminal lookup but this would be incorrect
+   since a "terminal" Rule is a DDDS concept and this flag indicates
+   that anything after this rule does not adhere to DDDS concepts at
+   all.
+
+   The remaining alphabetic flags are reserved for future versions of
+   this specification.  The numeric flags may be used for local
+   experimentation.  The S, A, U and P flags are all mutually exclusive,
+   and resolution libraries MAY signal an error if more than one is
+   given.  (Experimental code and code for assisting in the creation of
+   Rewrite Rules would be more likely to signal such an error than a
+   client such as a browser.)  It is anticipated that multiple flags
+   will be allowed in the future, so implementers MUST NOT assume that
+   the flags field can only contain 0 or 1 characters.  Finally, if a
+   client encounters a record with an unknown flag, it MUST ignore it
+   and move to the next Rule.  This test takes precedence over any
+   ordering since flags can control the interpretation placed on fields.
+   A novel flag might change the interpretation of the regexp and/or
+   replacement fields such that it is impossible to determine if a
+   record matched a given target.
+
+   The "S", "A", and "U" flags are called 'terminal' flags since they
+   halt the looping DDDS algorithm.  If those flags are not present,
+   clients may assume that another Rule exists at the Key produced by
+   the current Rewrite Rule.
+
+4.4 Services Parameters
+
+   Service Parameters for this Application take the form of a string of
+   characters that follow this ABNF:
+
+      service_field = [ [protocol] *("+" rs)]
+      protocol      = ALPHA *31ALPHANUM
+      rs            = ALPHA *31ALPHANUM
+      ; The protocol and rs fields are limited to 32
+      ; characters and must start with an alphabetic.
+
+   In other words, an optional protocol specification followed by 0 or
+   more resolution services.  Each resolution service is indicated by an
+   initial '+' character.
+
+
+
+
+
+
+
+
+
+
+
+Mealling                    Standards Track                     [Page 5]
+
+RFC 3404               DDDS Based URI Resolution            October 2002
+
+
+   The empty string is also valid.  This will typically be seen at the
+   beginning of a series of Rules, when it is impossible to know what
+   services and protocols will be offered at the end of a particular
+   delegation path.
+
+4.4.1 Services
+
+   The service identifiers that make up the 'rs' production are generic
+   for both URI and URN resolution since the input value types itself
+   based on the URI scheme.  The list of valid services are defined in
+   [11].
+
+   Examples of some of these services are:
+
+   I2L:  given a URI return one URI that identifies a location where the
+         original URI can be found.
+
+   I2Ls: given a URI return one or more URIs that identify multiple
+         locations where the original URI can be found.
+
+   I2R:  given a URI return one instance of the resource identified by
+         that URI.
+
+   I2Rs: given a URI return one or more instances of the resources
+         identified by that URI.
+
+   I2C:  given a URI return one instance of a description of that
+         resource.
+
+   I2N:  given a URI return one URN that names the resource (Caution:
+         equality with respect to URNs is non-trivial.  See [6] for
+         examples of why.)
+
+4.4.2 Protocols
+
+   The protocol identifiers that are valid for the 'protocol' production
+   MUST be defined by documents that are specific to URI resolution.  At
+   present the THTTP [10] protocol is the only such specification.
+
+   It is extremely important to realize that simply specifying any
+   protocol in the services field is insufficient since there are
+   additional semantics surrounding URI resolution that are not defined
+   within the protocols.  For example, if Z39.50 were to be specified as
+   a valid protocol it would have to additionally define how it would
+   encode requests for specific services, how the URI is encoded, and
+   what information is returned.
+
+
+
+
+
+Mealling                    Standards Track                     [Page 6]
+
+RFC 3404               DDDS Based URI Resolution            October 2002
+
+
+4.4.3 Applicability of Services
+
+   Since it is possible for there to be a complex set of possible
+   protocols and services a client application may often need to apply a
+   more complex decision making process to a set of records than simply
+   matching on an ordered list of protocols.  For example, if there are
+   4 rules that are applicable the last one may have a more desirable
+   Service field than the first.  But since the client may be satisfied
+   by the first it will never know about the 4th one which may be
+   'better'.
+
+   To mitigate this the client may want to slightly modify the DDDS
+   algorithm (for this application only!) in order to determine if more
+   applicable protocols/services exist.  This can safely be done for
+   this application by using a more complex interaction between steps 3
+   and 4 of the DDDS algorithm in order to find the optimal path to
+   follow.  For example, once a client has found a rule who's
+   Substitution Expression produces a result and who's Service
+   description is acceptable, it may make note of this but continue to
+   look at further rules that apply (all the while adhering to the
+   Order!) in order to find a better one.  If none are found it can use
+   the one it made note of.
+
+   Keep in mind that in order for this to remain safe, the input to step
+   3 and the output of step 4 MUST be identical to the basic algorithm.
+   The client software MUST NOT attempt to do this optimization outside
+   a specific set of Rewrite Rules (i.e., across delegation paths).
+
+4.5 Valid Databases
+
+   At present only one DDDS Database is specified for this Application.
+   "Dynamic Delegation Discovery System (DDDS) Part Three: The Domain
+   Name System (DNS) Database" (RFC 3403) [4] specifies a DDDS Database
+   that uses the NAPTR DNS resource record to contain the rewrite rules.
+   The Keys for this database are encoded as domain-names.
+
+   The output of the First Well Known Rule for the URI Resolution
+   Application is the URI's scheme.  In order to convert this to a
+   unique key in this Database the string '.uri.arpa.' is appended to
+   the end.  This domain-name is used to request NAPTR records which
+   produces new keys in the form of domain-names.
+
+   The output of the First Well Known Rule of the URN Resolution
+   Application is the URN's namespace id.  In order to convert this to a
+   unique key in this Database the string '.urn.arpa.' is appended to
+   the end.  This domain-name is used to request NAPTR records which
+   produces new keys in the form of domain-names.
+
+
+
+
+Mealling                    Standards Track                     [Page 7]
+
+RFC 3404               DDDS Based URI Resolution            October 2002
+
+
+   DNS servers MAY interpret Flag values and use that information to
+   include appropriate SRV and A records in the Additional Information
+   portion of the DNS packet.  Clients are encouraged to check for
+   additional information but are not required to do so.  See the
+   Additional Information Processing section of RFC 3404 for more
+   information on NAPTR records and the Additional Information section
+   of a DNS response packet.
+
+   The character set used to encode the substitution expression is
+   UTF-8.  The allowed input characters are all those characters that
+   are allowed anywhere in a URI.  The characters allowed to be in a Key
+   are those that are currently defined for DNS domain-names.  The "i"
+   flag to the substitution expression is used to denote that, where
+   appropriate for the code points in question, any matches should be
+   done in a case-insensitive way.
+
+5. Examples
+
+5.1 An Example Using a URN
+
+   Consider a URN that uses the hypothetical FOO namespace.  FOO numbers
+   are identifiers for approximately 30 million registered businesses
+   around the world, assigned and maintained by Fred, Otto and Orvil,
+   Inc.  The URN might look like:
+
+      urn:foo:002372413:annual-report-1997
+
+   The first step in the resolution process is to find out about the FOO
+   namespace.  The namespace identifier [8], "foo", is extracted from
+   the URN and prepended to '.urn.arpa.', producing 'foo.urn.arpa.'.
+   The DNS is queried for NAPTR records for this domain which produces
+   the following results:
+
+foo.urn.arpa.
+;;      order pref flags service          regexp        replacement
+IN NAPTR 100  10  "s" "foolink+I2L+I2C"  ""   foolink.udp.example.com.
+IN NAPTR 100  20  "s" "rcds+I2C"          ""  rcds.udp.example.com.
+IN NAPTR 100  30  "s" "thttp+I2L+I2C+I2R" ""  thttp.tcp.example.com.
+
+   The order field contains equal values, indicating that no order has
+   to be followed.  The preference field indicates that the provider
+   would like clients to use the special 'foolink' protocol, followed by
+   the RCDS protocol, and that THTTP is offered as a last resort.  All
+   the records specify the "s" flag which means that the record is
+   terminal and that the next step is to retrieve an SRV record from DNS
+   for the given domain-name.
+
+
+
+
+
+Mealling                    Standards Track                     [Page 8]
+
+RFC 3404               DDDS Based URI Resolution            October 2002
+
+
+   The service fields say that if we speak of foolink, we will be able
+   to issue either the I2L, I2C or I2R requests to obtain a URI or ask
+   some complicated questions about the resource.  The Resource
+   Cataloging and Distribution Service  (RCDS) [12] could be used to get
+   some metadata for the resource, while THTTP could be used to get a
+   URI for the current location of the resource.
+
+   Assuming our client does not know the foolink protocol but does know
+   the RCDS protocol, our next action is to lookup SRV RRs for
+   rcds.udp.example.com, which will tell us hosts that can provide the
+   necessary resolution service.  That lookup might return:
+
+      ;;                          Pref Weight Port Target
+      rcds.udp.example.com  IN SRV 0    0    1000 deffoo.example.com.
+                            IN SRV 0    0    1000 dbexample.com.au.
+                            IN SRV 0    0    1000 ukexample.com.uk.
+
+   telling us three hosts that could actually do the resolution, and
+   giving us the port we should use to talk to their RCDS server.  (The
+   reader is referred to the SRV specification [9] for the
+   interpretation of the fields above.)
+
+   There is opportunity for significant optimization here.  RFC 3404
+   defines that Additional Information section may be available.  In
+   this case the the SRV records may be returned as additional
+   information for terminal NAPTRs lookups (as well as the A records for
+   those SRVs).  This is a significant optimization.  In conjunction
+   with a long TTL for *.urn.arpa. records, the average number of probes
+   to DNS for resolving most URIs would approach one.
+
+   Note that the example NAPTR records above are intended to represent
+   the result of a NAPTR lookup using some client software like
+   nslookup; zone administrators should consult the documentation
+   accompanying their domain name servers to verify the precise syntax
+   they should use for zone files.
+
+   Also note that there could have been an additional first step where
+   the URN was resolved as a generic URI by looking up urn.uri.arpa.
+   The resulting rule would have specified that the NID be extracted
+   from the URN and '.urn.arpa.' appended to it resulting in the new key
+   'foo.urn.arpa.' which is the first step from above.
+
+5.2 CID URI Scheme Example
+
+   Consider a URI scheme based on MIME Content-Ids.  The URI might look
+   like this:
+
+      cid:199606121851.1@bar.example.com
+
+
+
+Mealling                    Standards Track                     [Page 9]
+
+RFC 3404               DDDS Based URI Resolution            October 2002
+
+
+   (Note that this example is chosen for pedagogical purposes, and does
+   not conform to the CID URI scheme.)
+
+   The first step in the resolution process is to find out about the CID
+   scheme.  The scheme is extracted from the URI, prepended to
+   '.uri.arpa.', and the NAPTR for 'cid.uri.arpa.' looked up in the DNS.
+   It might return records of the form:
+
+cid.uri.arpa.
+;;       order pref flags service        regexp           replacement
+IN NAPTR 100   10   ""    ""  "!^cid:.+@([^\.]+\.)(.*)$!\2!i"    .
+
+   Since there is only one record, ordering the responses is not a
+   problem.  The replacement field is empty, so the pattern provided in
+   the regexp field is used.  We apply that regexp to the entire URI to
+   see if it matches, which it does.  The \2 part of the substitution
+   expression returns the string "example.com".  Since the flags field
+   is empty, the lookup is not terminal and our next probe to DNS is for
+   more NAPTR records where the new domain is 'example.com'.
+
+   Note that the rule does not extract the full domain name from the
+   CID, instead it assumes the CID comes from a host and extracts its
+   domain.  While all hosts, such as 'bar', could have their very own
+   NAPTR, maintaining those records for all the machines at a site could
+   be an intolerable burden.  Wildcards are not appropriate here since
+   they only return results when there is no exactly matching names
+   already in the system.
+
+   The record returned from the query on "example.com" might look like:
+
+example.com.
+;;      order pref flags service           regexp  replacement
+IN NAPTR 100 50 "s" "z3950+I2L+I2C"     ""    z3950.tcp.example.com.
+IN NAPTR 100 50 "s" "rescap+I2C"        ""    rescap.udp.example.com.
+IN NAPTR 100 50 "s" "thttp+I2L+I2C+I2R" ""    thttp.tcp.example.com.
+
+   Continuing with the example, note that the values of the order fields
+   are equal for all records, so the client is free to pick any record.
+   The Application defines the flag 's' to mean a terminal lookup and
+   that the output of the rewrite will be a domain-name for which an SRV
+   record should be queried.  Once the client has done that, it has the
+   following information: the host, port, the protocol, and the services
+   available via that protocol.  Given these bits of information the
+   client has enough to be able to contact that server and ask it
+   questions about the cid URI.
+
+
+
+
+
+
+Mealling                    Standards Track                    [Page 10]
+
+RFC 3404               DDDS Based URI Resolution            October 2002
+
+
+   Recall that the regular expression used \2 to extract a domain name
+   from the CID, and \.  for matching the literal '.' characters
+   separating the domain name components.  Since '\' is the escape
+   character, literal occurrences of a backslash must be escaped by
+   another backslash.  For the case of the cid.uri.arpa record above,
+   the regular expression entered into the master file should be
+   "!^cid:.+@([^\\.]+\\.)(.*)$!\\2!i".  When the client code actually
+   receives the record, the pattern will have been converted to
+   "!^cid:.+@([^\.]+\.)(.*)$!\2!i".
+
+5.3 Resolving an HTTP URI Scheme
+
+   Even if URN systems were in place now, there would still be a
+   tremendous number of host based URIs.  It should be possible to
+   develop a URI resolution system that can also provide location
+   independence for those URIs.
+
+   Assume we have the URI for a very popular piece of software that the
+   publisher wishes to mirror at multiple sites around the world:
+
+   http://www.example.com/software/latest-beta.exe
+
+   We extract the prefix, "http", and lookup NAPTR records for
+   'http.uri.arpa.'.  This might return a record of the form:
+
+   http.uri.arpa. IN NAPTR
+   ;;  order   pref flags service      regexp             replacement
+        100     90   ""      ""   "!^http://([^/:]+)!1!i"       .
+
+   This expression returns everything after the first double slash and
+   before the next slash or colon.  (We use the '!' character to delimit
+   the parts of the substitution expression.  Otherwise we would have to
+   use backslashes to escape the forward slashes, and would have a
+   regexp in the zone file that looked like this:
+   "/^http:\\/\\/([^\\/:]+)/\\1/i").
+
+   Applying this pattern to the URI extracts "www.example.com".  Looking
+   up NAPTR records for that might return:
+
+   www.example.com.
+   ;;       order pref flags   service  regexp     replacement
+    IN NAPTR 100  100  "s"   "thttp+L2R"   ""    thttp.example.com.
+    IN NAPTR 100  100  "s"   "ftp+L2R"    ""     ftp.example.com.
+
+   Looking up SRV records for thttp.example.com would return information
+   on the hosts that example.com has designated to be its mirror sites.
+   The client can then pick one for the user.
+
+
+
+
+Mealling                    Standards Track                    [Page 11]
+
+RFC 3404               DDDS Based URI Resolution            October 2002
+
+
+6. Notes
+
+   o  Registration procedures for the 'urn.arpa.' and 'uri.arpa.' DNS
+      zones are specified in "Dynamic Delegation Discovery System (DDDS)
+      Part Five: URI.ARPA Assignment Procedures" (RFC 3405 [5].
+
+   o  If a record at a particular order matches the URI, but the client
+      doesn't know the specified protocol and service, the client SHOULD
+      continue to examine records that have the same order.  The client
+      MUST NOT consider records with a higher value of order.  This is
+      necessary to make delegation of portions of the namespace work.
+      The order field is what lets site administrators say "all requests
+      for URIs matching pattern x go to server 1, all others go to
+      server 2".
+
+   o  Note that SRV RRs impose additional requirements on clients.
+
+7. IANA Considerations
+
+   The use of the "urn.arpa." and "uri.arpa." zones requires
+   registration policies and procedures to be followed and for the
+   operation of those DNS zones to be maintained.  These policies and
+   procedures are spelled out in a "Dynamic Delegation Discovery System
+   (DDDS) Part Five: URI.ARPA Assignment Procedures (RFC 3405)" [5].
+   The operation of those zones imposes operational and administrative
+   responsibilities on the IANA.
+
+   The registration method used for values in the Services and Flags
+   fields is for a specification to be approved by the IESG and
+   published as either an Informational or standards track RFC.
+
+   The registration policies for URIs is found in RFC 2717 [17].  URN
+   NID registration policies are found in RFC 2611 [16].
+
+8. Security Considerations
+
+   The use of "urn.arpa." and "uri.arpa." as the registry for namespaces
+   is subject to denial of service attacks, as well as other DNS
+   spoofing attacks.  The interactions with DNSSEC are currently being
+   studied.  It is expected that NAPTR records will be signed with SIG
+   records once the DNSSEC work is deployed.
+
+   The rewrite rules make identifiers from other namespaces subject to
+   the same attacks as normal domain names.  Since they have not been
+   easily resolvable before, this may or may not be considered a
+   problem.
+
+
+
+
+
+Mealling                    Standards Track                    [Page 12]
+
+RFC 3404               DDDS Based URI Resolution            October 2002
+
+
+   Regular expressions should be checked for sanity, not blindly passed
+   to something like PERL.
+
+   This document has discussed a way of locating a resolver, but has not
+   discussed any detail of how the communication with the resolver takes
+   place.  There are significant security considerations attached to the
+   communication with a resolver.  Those considerations are outside the
+   scope of this document, and must be addressed by the specifications
+   for particular resolver communication protocols.
+
+9. Acknowledgments
+
+   The editors would like to thank Keith Moore for all his consultations
+   during the development of this document.  We would also like to thank
+   Paul Vixie for his assistance in debugging our implementation, and
+   his answers on our questions.  Finally, we would like to acknowledge
+   our enormous intellectual debt to the participants in the Knoxville
+   series of meetings, as well as to the participants in the URI and URN
+   working groups.
+
+   Specific recognition is given to Ron Daniel who was co-author on the
+   original versions of these documents.  His early implementations and
+   clarity of thinking was invaluable in clearing up many of the
+   potential boundary cases.
+
+References
+
+   [1]  Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
+        One: The Comprehensive DDDS", RFC 3401, October 2002.
+
+   [2]  Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
+        Two: The Algorithm", RFC 3402, October 2002.
+
+   [3]  Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
+        Three: The Domain Name System (DNS) Database", RFC 3403, October
+        2002.
+
+   [4]  Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
+        Four: The Uniform Resource Identifiers (URI) Resolution
+        Application", RFC 3404, October 2002.
+
+   [5]  Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
+        Five: URI.ARPA Assignment Procedures", RFC 3405y, October 2002.
+
+   [6]  Sollins, K. and L. Masinter, "Functional Requirements for
+        Uniform Resource Names", RFC 1737, December 1994.
+
+
+
+
+
+Mealling                    Standards Track                    [Page 13]
+
+RFC 3404               DDDS Based URI Resolution            October 2002
+
+
+   [7]  Arms, B., "The URN Implementors, Uniform Resource Names: A
+        Progress Report", D-Lib Magazine, February 1996.
+
+   [8]  Moats, R., "URN Syntax", RFC 2141, May 1997.
+
+   [9]  Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for
+        specifying the location of services (DNS SRV)", RFC 2782,
+        February 2000.
+
+   [10] Daniel, R., "A Trivial Convention for using HTTP in URN
+        Resolution", RFC 2169, June 1997.
+
+   [11] Mealling, M., "URI Resolution Services Necessary for URN
+        Resolution", RFC 2483, January 1999.
+
+   [12] Moore, K., Browne, S., Cox, J. and J. Gettler, "Resource
+        Cataloging and Distribution System", Technical Report CS-97-346,
+        December 1996.
+
+   [13] Sollins, K., "Architectural Principles of Uniform Resource Name
+        Resolution", RFC 2276, January 1998.
+
+   [14] Daniel, R. and M. Mealling, "Resolution of Uniform Resource
+        Identifiers using the Domain Name System", RFC 2168, June 1997.
+
+   [15] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource
+        Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
+
+   [16] Daigle, L., van Gulik, D., Iannella, R. and P. Falstrom, "URN
+        Namespace Definition Mechanisms", RFC 2611, BCP 33, June 1999.
+
+   [17] Petke, R. and I. King, "Registration Procedures for URL Scheme
+        Names", RFC 2717, BCP 35, November 1999.
+
+   [18] Mealling, M. and R. Daniel, "The Naming Authority Pointer
+        (NAPTR) DNS Resource Record", RFC 2915, August 2000.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mealling                    Standards Track                    [Page 14]
+
+RFC 3404               DDDS Based URI Resolution            October 2002
+
+
+Appendix A. Pseudo Code
+
+   For the edification of implementers, pseudocode for a client routine
+   using NAPTRs is given below.  This code is provided merely as a
+   convenience, it does not have any weight as a standard way to process
+   NAPTR records.  Also, as is the case with pseudocode, it has never
+   been executed and may contain logical errors.  You have been warned.
+
+   //
+   // findResolver(URN)
+   // Given a URN, find a host that can resolve it.
+   //
+   findResolver(string URN) {
+     // prepend prefix to ".urn.arpa."
+     sprintf(key, "%s.urn.arpa.", extractNS(URN));
+     do {
+       rewrite_flag = false;
+       terminal = false;
+       if (key has been seen) {
+         quit with a loop detected error
+       }
+       add key to list of "seens"
+       records = lookup(type=NAPTR, key); // get all NAPTR RRs for 'key'
+
+       discard any records with an unknown value in the "flags" field.
+       sort NAPTR records by "order" field and "preference" field
+           (with "order" being more significant than "preference").
+       n_naptrs = number of NAPTR records in response.
+       curr_order = records[0].order;
+       max_order = records[n_naptrs-1].order;
+
+       // Process current batch of NAPTRs according to "order" field.
+       for (j=0; j < n_naptrs && records[j].order <= max_order; j++) {
+         if (unknown_flag) // skip this record and go to next one
+            continue;
+         newkey = rewrite(URN, naptr[j].replacement, naptr[j].regexp);
+         if (!newkey) // Skip to next record if the rewrite didn't
+            match continue;
+         // We did do a rewrite, shrink max_order to current value
+         // so that delegation works properly
+         max_order = naptr[j].order;
+         // Will we know what to do with the protocol and services
+         // specified in the NAPTR? If not, try next record.
+         if(!isKnownProto(naptr[j].services)) {
+           continue;
+         }
+         if(!isKnownService(naptr[j].services)) {
+           continue;
+
+
+
+Mealling                    Standards Track                    [Page 15]
+
+RFC 3404               DDDS Based URI Resolution            October 2002
+
+
+         }
+
+         // At this point we have a successful rewrite and we will
+         // know how to speak the protocol and request a known
+         // resolution service. Before we do the next lookup, check
+         // the flags to see if we're done.
+         // Note: it is possible to rewrite this so that this valid
+         // record could be noted as such but continue on in order
+                // to find a 'better' record. But that code would be to
+         // voluminous and application specific to be illustrative.
+         if (strcasecmp(flags, "S")
+          || strcasecmp(flags, "P"))
+          || strcasecmp(flags, "A")) {
+            terminal = true;
+            services = naptr[j].services;
+            addnl = any SRV and/or A records returned as additional
+                    info for naptr[j].
+         }
+         key = newkey;
+         rewriteflag = true;
+         break;
+       }
+     } while (rewriteflag && !terminal);
+
+     // Did we not find our way to a resolver?
+     if (!rewrite_flag) {
+        report an error
+        return NULL;
+     }
+
+     // Leave rest to another protocol?
+     if (strcasecmp(flags, "P")) {
+        return key as host to talk to;
+     }
+
+     // If not, keep plugging
+     if (!addnl) { // No SRVs came in as additional info, look them up
+       srvs = lookup(type=SRV, key);
+     }
+
+     sort SRV records by preference, weight, ...
+     for each (SRV record) { // in order of preference
+       try contacting srv[j].target using the protocol and one of the
+           resolution service requests from the "services" field of the
+           last NAPTR record.
+       if (successful)
+         return (target, protocol, service);
+         // Actually we would probably return a result, but this
+
+
+
+Mealling                    Standards Track                    [Page 16]
+
+RFC 3404               DDDS Based URI Resolution            October 2002
+
+
+         // code was supposed to just tell us a good host to talk to.
+     }
+     die with an "unable to find a host" error;
+   }
+
+Author's Address
+
+   Michael Mealling
+   VeriSign
+   21345 Ridgetop Circle
+   Sterling, VA  20166
+   US
+
+   EMail: michael@neonym.net
+   URI:   http://www.verisignlabs.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mealling                    Standards Track                    [Page 17]
+
+RFC 3404               DDDS Based URI Resolution            October 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 18]
+