[Search] [txt|pdfized|bibtex] [Tracker] [Email] [Nits]
Versions: 00                                                            
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]