Network Working Group Donald E. Eastlake 3rd
INTERNET-DRAFT Motorola
Expires August 2001 February 2001
Considerations for URI and FQDN Protocol Parameters
-------------- --- --- --- ---- -------- ----------
<draft-eastlake-uri-fqdn-param-00.txt>
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
<scheme>:<scheme specific part>
but, when the <scheme specific part> starts with a double slash
("//"), the syntax is the more explicit
<scheme>://<authority><path>?<query>
where <path>, 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 <authority> 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:
[<userinfo>@]<FQDN>[:<port>]
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
<userinfo> and <port> 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 <path> component or via the hierarchical <FQDN>
component. It is also possible to combine these.
In the absence of considerations to the contrary, use of the <FQDN>
should be preferred for hierarhical parameter allocation. This is
because the <FQDN> 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 <path> hierarchy is used heavily with a fixed
<FQDN>, 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, <http://www.iab.org>.
[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" <http://www.w3.org/TR/REC-xml-names>,
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]