Dynamic Delegation Discovery System (DDDS) Part Four: The Uniform Resource Identifiers (URI)
obsoletes
Extracted elements (22)
A client may modify the DDDS algorithm for this application to look beyond the first matching rule to find a more optimal protocol/service. This is safe as long as the input to step 3 and the output of step 4 remain identical to the basic algorithm, and optimization MUST NOT cross delegation paths.
Specifying a protocol in the services field alone is insufficient because additional semantics surrounding URI resolution must also be defined, including how requests for specific services are encoded and what information is returned.
URI and URN resolution are specified as two separate but technically identical DDDS Applications to allow URN resolution to proceed without dependency on the adoption of generic URI resolution, addressing concerns that URNs might suffer from lack of URI resolution adoption.
The UTF-8 character set is used to encode the substitution expression. Allowed input characters are those permitted anywhere in a URI, while Key characters are restricted to those valid in DNS domain-names. The 'i' flag in the substitution expression denotes case-insensitive matching where appropriate.
DNS servers MAY interpret Flag values and 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.
If a client encounters a NAPTR record with an unknown flag, it MUST ignore that record and move to the next Rule. This takes precedence over ordering.
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 examining records at the same order. The client MUST NOT consider records with a higher order value.
Implementers MUST NOT assume that the flags field can only contain 0 or 1 characters, as multiple flags may be allowed in future versions.
Protocol identifiers valid for the 'protocol' production MUST be defined by documents specific to URI resolution. At present only THTTP (RFC 2169) is specified.
Resolution libraries MAY signal an error if more than one of the mutually exclusive S, A, U, or P flags is present in a NAPTR record.
When optimizing across multiple applicable rules, the client software MUST NOT attempt this optimization outside a specific set of Rewrite Rules (i.e., across delegation paths).
For URI resolution, the First Well Known Rule extracts the URI scheme as the initial key (e.g., 'http' from 'http://www.example.com/'). For URN resolution, the Namespace Identifier is extracted as the first key (e.g., 'foo' from 'urn:foo:foospace').
For URI resolution, the URI scheme extracted by the First Well Known Rule is converted to a DNS key by appending '.uri.arpa.' (e.g., 'http.uri.arpa.'). For URN resolution, the namespace id is converted by appending '.urn.arpa.' (e.g., 'foo.urn.arpa.').
Four flags are defined: 'S' (output is a domain-name for SRV lookup), 'A' (output is a domain-name for A/AAAA/A6 lookup), 'U' (output is a URI), and 'P' (remainder of DDDS algorithm is application-specific and outside DDDS scope). The S, A, U, and P flags are mutually exclusive.
Service identifiers (the 'rs' production) include I2L (return one URI for the resource location), I2Ls (return multiple location URIs), I2R (return one resource instance), I2Rs (return multiple instances), I2C (return a resource description), and I2N (return a URN naming the resource).
The Application Unique String for URI/URN resolution is the URI or URN being located, which MUST be canonicalized and hex encoded according to the 'absolute-uri' production from RFC 2396.
The 'uri.arpa.' DNS zone serves as the registry for URI scheme resolution rules. The 'urn.arpa.' DNS zone serves as the registry for URN namespace resolution rules. Registration policies and procedures are specified in RFC 3405.
Values in the Services and Flags fields require a specification approved by the IESG and published as either an Informational or standards track RFC. URN NID registration policies are in RFC 2611; URI registration policies are in RFC 2717.
Rewrite rules make identifiers from other namespaces subject to the same attacks as normal domain names. Regular expressions should be checked for sanity and not blindly passed to an execution engine such as PERL.
The 'urn.arpa.' and 'uri.arpa.' registries are subject to denial of service attacks and DNS spoofing attacks. Interactions with DNSSEC are under study; NAPTR records are expected to be signed with SIG records once DNSSEC is deployed.
This document addresses locating a resolver but not the security of the communication with that resolver. Significant security considerations for resolver communication protocols are outside the scope of this document and must be addressed by those specifications.
The Services Parameters field follows the ABNF: service_field = [ [protocol] *("+" rs)], where protocol and rs are each limited to 32 characters and must start with an alphabetic character. An optional protocol specification is followed by zero or more resolution services, each preceded by '+'.