Network Working Group Donald E. Eastlake 3rd INTERNET-DRAFT Motorola Expires August 2001 February 2001 Considerations for URI and FQDN Protocol Parameters -------------- --- --- --- ---- -------- ---------- Donald E. Eastlake 3rd Status of This Document This document is intended to become a Best Current Practices RFC. Comments should be sent to the author. This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. 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. Abstract It is becoming increasingly common for protocol parameters to be of URI or Domain Name syntax. Examples include TSIG algorithm identifiers, XMLDSIG algorithm and type identifiers, XML namespaces, etc. Considerations are provided for the allocation of such URI or Domain Name syntax protocol parameter values. D. Eastlake 3rd [Page 1] INTERNET-DRAFT URI & FQDN Protocol Parameters February 2001 Table of Contents Status of This Document....................................1 Abstract...................................................1 Table of Contents..........................................2 1. Introduction............................................3 2. FQDN Syntax Parameters..................................3 2.1 IANA Allocation........................................4 2.2 'Working Group' Allocation.............................4 2.3 IESG/IETF Allocation...................................5 3. URI Syntax Parameters...................................5 3.1 Scheme Based Allocation................................5 3.2 Authority Based Allocation.............................6 3.3 Authority versus Path..................................6 4. Operational Considerations..............................6 5. Security Considerations.................................7 References.................................................8 Author's Address..........................................10 Expiration and File Name..................................10 D. Eastlake 3rd [Page 2] INTERNET-DRAFT URI & FQDN Protocol Parameters February 2001 1. Introduction It is becoming increasingly common for protocol parameters to be of URI [RFC 2396] or Domain Name [RFC 1035] syntax. Examples include TSIG algorithm identifiers [RFC 2845], XMLDSIG algorithm and type identifiers [RFC XMLDSIG], XML namespaces [XML-NS], etc. (The use of a Domain Name syntax does not imply that a corresponding node exists in the operational DNS nor does the use of URI syntax imply dereferencability.) This document provides considerations for the allocation of such protocol parameter values when used for infrastructure or standards purposes. (This should not be confused with the allocation and registration of other parameter values for use inside the DNS protocol, which is covered in [RFC 2929].) Where the concept of domain name CLASS [RFC 1035, 2929] is meaningful, all domain names referred to herein are considered to be in the Internet (IN) CLASS. 2. FQDN Syntax Parameters Fully Qualified Domain Name (FQDN) syntax is defined in [RFC 1035]. Some additional information on the structure and management of the operational DNS namespace is given in [RFCs 1591, 2606, and 2929]. Some protocol paramters are specified such that their values are FQDN syntax. While the use of such values, for example as TSIG algorithm names [RFC 2845], does not necessarily imply the existence of a node of the same name in the operational DNS system, such parameter values SHOULD NOT incorporate a domain which is or is likely to become a normal operational DNS domain unless the meaning and/or use of the value is reasonably tied to the entity controlling the operational domain for as long as the parameter value will be in use, and otherwise SHOULD use portions of the DNS name space set aside for stable infrastructure and standards protocol parameter values, particularly the .ARPA domain. Unless provided to the contrary, allocation of any FQDN hereunder to an entity implies authority of that entity to allocate subdomains within the domain identified by that FQDN [RFC 1035]. D. Eastlake 3rd [Page 3] INTERNET-DRAFT URI & FQDN Protocol Parameters February 2001 2.1 IANA Allocation Infrastructure and standards protocol parameter domain names allocated by IANA MUST be subordinate to a domain reserved for such purposes, such as .ARPA or .REG.INT, and SHOULD be subordinate to the top level domain name .ARPA. Such action shall occur only with an IETF Standards Action, IETF Consensus, or IESG Approval [RFC 2434]. The meaning and/or allocation criteria for sub-domains of such IANA allocated domain names SHOULD be defined at the time of their allocation. Historic Note: The first infrastructure domain, IN-ADDR.ARPA, was placed under .ARPA, which stood at the time for ARPANET, as part of the transitions strategy from host table naming [RFC 881]. Subsequently some infrastructure domains were assigned uner .INT, for example TPC.INT [RFCs 1528-1530] and IP6.INT [RFC 1886]. On 10 May, 2000, the Internet Architecture Board [IAB] issued a statement redefining .ARPA to be the "Address and Routing Parameters Area" where new infrastructure domains should be placed, deprecating the placing of Internet infrastructure domains under .INT, and recommending that, where appropriate, Internet infrastructure domains under .INT be migrated to .ARPA. An example of this is IP6.ARPA [RFC 2874]. 2.2 'Working Group' Allocation Consistent with the IETF principal of lubricating and delegating allocations so as to minimize bureaucratic barriers, the chair of any Working Group (WG), BoF, or other entity properly allocated a "Working Group" acronym by the IETF Secretariate may allocate Domain Names to be used in developing, experimenting with, and testing protocols. Such domain names will be subdomains of the entity acronym under the year under IETF.ARPA. For example, matching *.ACRONYM.2001.IETF.ARPA. where "acronym" is a hypotetical WG acronym and 2001 is replaced by the appropriate year. Such domain names MUST conform to the DNS overall and label size syntax limits. This document allocates IETF.ARPA for this purpose and use as described in section 2.3 below. It is the responsibility of the working group to track these names and avoid harmful duplication. These "Working Group" FQDNs SHOULD NOT become permanently embedded in standards or the like. IANA is NOT REQUIRED to register or track any such WG allocated domain names unless and until so directed by a Standards Action, IETF Consensus, or IESG Approval [RFC 2434]. D. Eastlake 3rd [Page 4] INTERNET-DRAFT URI & FQDN Protocol Parameters February 2001 The common era year used SHOULD be the year at time of allocations but MAY be a previous year in which the acronym identified entity existed. The year is included for the following reasons: While it is the current policy that working group acronyms will be unique for all time, this policy could change or errors could be made in acronym allocation. Incorporation of the year more robustly assures against accidental duplication. Since it is the responsibility of the WG to track these names, incorporation of the year reduces the burden for tracking past names to avoid duplication. 2.3 IESG/IETF Allocation Subdomains below IETF.ARPA not conforming to the constraints give in Section 2.2 above require an IETF Standards Action, IETF Consensus, or IESG Approval [RFC 2434] for allocation. 3. URI Syntax Parameters Uniform Resource Identifiers (URIs) [RFC 2396] generally conform to the syntax : but, when the starts with a double slash ("//"), the syntax is the more explicit ://? where , if it is not null, must start with a slash ("/") and consists of slash separated path elements. 3.1 Scheme Based Allocation The requirements for the registration of a new URI scheme are given in [RFC 2717]. The designer of the scheme has great flexibility in specifying the structure of and allocations/registration policies for the scheme specific part and SHOULD specify any special considrations if instances of the scheme are to be used in infrastructure or standards URIs. D. Eastlake 3rd [Page 5] INTERNET-DRAFT URI & FQDN Protocol Parameters February 2001 3.2 Authority Based Allocation Where a URI follows the syntax that includes an section as described above, then the structure of that authority part is specified by the scheme. However, all schemes currently in public use use the following structure: [@][:] where items in square brackets are optional. The allocation/registration procedures specified in Section 2 above should be followed for the FQDN (Fully Qualified Domain Name) part of infrastructure and standards URIs. Considerations for the allocation/registration of the optional and parts, where present, SHOULD be specified when the scheme is set up or the FQDN or an infrastructire / standards ancester domain of the FQDN is allocated. 3.3 Authority versus Path Where hierarhical subdivisions within an authority based URI are desired, there are two primary ways to achieve this: via an hierarchical component or via the hierarchical component. It is also possible to combine these. In the absence of considerations to the contrary, use of the should be preferred for hierarhical parameter allocation. This is because the frequently gets mapped to a host (or small set of hosts). Extensive Domain Name System facilities such as wildcards, CNAME, MX [RFC 1035], SRV [RFC 2782], and DNAME [RFC 2672] provide flexibility in mapping subdomains and services to a large or small number of hosts. On the other had, if hierarchy is used heavily with a fixed , then, if there are actaual network requests based on these URIs, they will normally be constrained to inflexibly hitting a small number of hosts. 4. Operational Considerations [Do we want to get into this...?] The use of a domain name as a protocol parameter, either by itself or in a URI or elsewhere, does not necessarily imply that a D. Eastlake 3rd [Page 6] INTERNET-DRAFT URI & FQDN Protocol Parameters February 2001 corresponding node exists in the operational global Domain Name System (DNS). The entity managing the .ARPA zone MUST make reasonable provision for delegating infrastrucutre and standards subdomains where an operational node in the global DNS is required for their use. In particular, it is noted that IN-ADDR.ARPA and IP6.ARPA MUST be allocated to the authorities for IPv4 and IPv6 addresses and that IETF.ARPA MUST be allocated to the IETF Secretariate or an entity that will operate it on their behalf. 5. Security Considerations The protocol parameter allocation considerations herein do not directly effect security. For DNS security considerations, see [RFC 2535]. For URI security considerations, see [RFC 2396]. D. Eastlake 3rd [Page 7] INTERNET-DRAFT URI & FQDN Protocol Parameters February 2001 References [IAB] - Internet Architecture Board, . [RFC 881] - "Domain names plan and schedule", J. Postel, Nov-01-1983. [RFC 1035] - "Domain names - implementation and specification", P.V. Mockapetris, Nov-01-1987. [RFC 1528] - "Principles of Operation for the TPC.INT Subdomain: Remote Printing -- Technical Procedures", C. Malamud, M. Rose, October 1993. [RFC 1529] - "Principles of Operation for the TPC.INT Subdomain: Remote Printing -- Administrative Policies", C. Malamud, M. Rose. October 1993. [RFC 1530] - "Principles of Operation for the TPC.INT Subdomain: General Principles and Policy", C. Malamud, M. Rose, October 1993. [RFC 1591] - "Domain Name System Structure and Delegation", J. Postel, March 1994. [RFC 1886] - "DNS Extensions to support IP version 6", S. Thomson, C. Huitema, December 1995. [RFC 2396] - "Uniform Resource Identifiers (URI): Generic Syntax", T. Berners-Lee, R. Fielding, L. Masinter, August 1998. [RFC 2434] - "Guidelines for Writing an IANA Considerations Section in RFCs", T. Narten, H. Alvestrand, October 1998. [RFC 2535] - "Domain Name System Security Extensions", D. Eastlake, March 1999. [RFC 2606] - "Reserved Top Level DNS Names", D. Eastlake, A. Panitz, June 1999. [RFC 2672] - "Non-Terminal DNS Name Redirection", M. Crawford, August 1999. [RFC 2717] - R. Petke, I. King, "Registration Procedures for URL Scheme Names", November 1999. [RFC 2845] - "Secret Key Transaction Authentication for DNS (TSIG)", P. Vixie, O. Gudmundsson, D. Eastlake, B. Wellington, May 2000. [RFC 2874] - "DNS Extensions to Support IPv6 Address Aggregation and Renumbering", M. Crawford, C. Huitema, July 2000. D. Eastlake 3rd [Page 8] INTERNET-DRAFT URI & FQDN Protocol Parameters February 2001 [RFC 2782] - "A DNS RR for specifying the location of services (DNS SRV)", A. Gulbrandsen, P. Vixie, L. Esibov, February 2000. [RFC 2929] - "Domain Name System (DNS) IANA Considerations", D. Eastlake 3rd, E. Brunner-Williams, B. Manning, September 2000. [RFC XMLDSIG] - "XML-Signature Syntax and Processing" draft-ietf- xmldsig-core-11.txt, D. Eastlake, J. Reagle, D. Solo, in RFC Editor's queue for publication as a Proposed Standard. [XML-NS] - "Namespaces in XML" , T. Bray, D. Hollander, A. Layman, 14-January-1999. D. Eastlake 3rd [Page 9] INTERNET-DRAFT URI & FQDN Protocol Parameters February 2001 Author's Address Donald E. Eastlake 3rd Motorola 155 Beaver Street Milford, MA 01757 USA Telephone: +1 508-634-2066(h) +1 508-261-5434(w) FAX: +1 508-261-4447(w) email: Donald.Eastlake@motorola.com Expiration and File Name This draft expires August 2001. Its file name is draft-eastlake-uri-fqdn-param-00.txt. D. Eastlake 3rd [Page 10]