idnits 2.17.00 (12 Aug 2021) /tmp/idnits54624/draft-eastlake-uri-fqdn-param-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 96: '... SHOULD NOT incorporate a domain ...' RFC 2119 keyword, line 102: '... otherwise SHOULD use portions of...' RFC 2119 keyword, line 113: '...llocated by IANA MUST be subordinate t...' RFC 2119 keyword, line 114: '...or .REG.INT, and SHOULD be subordinate...' RFC 2119 keyword, line 118: '...ted domain names SHOULD be defined at ...' (10 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- The exact meaning of the all-uppercase expression 'NOT REQUIRED' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 2001) is 7758 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '2929' on line 81 == Missing Reference: 'RFCs 1528-1530' is mentioned on line 125, but not defined == Unused Reference: 'RFC 1528' is defined on line 274, but no explicit reference was found in the text == Unused Reference: 'RFC 1529' is defined on line 278, but no explicit reference was found in the text == Unused Reference: 'RFC 1530' is defined on line 282, but no explicit reference was found in the text == Unused Reference: 'RFC 1591' is defined on line 285, but no explicit reference was found in the text == Unused Reference: 'RFC 2535' is defined on line 297, but no explicit reference was found in the text == Unused Reference: 'RFC 2606' is defined on line 300, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'IAB' ** Downref: Normative reference to an Unknown state RFC: RFC 881 ** Downref: Normative reference to an Experimental RFC: RFC 1528 ** Downref: Normative reference to an Informational RFC: RFC 1529 ** Downref: Normative reference to an Informational RFC: RFC 1530 ** Downref: Normative reference to an Informational RFC: RFC 1591 ** Obsolete normative reference: RFC 1886 (Obsoleted by RFC 3596) ** Obsolete normative reference: RFC 2396 (Obsoleted by RFC 3986) ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 2535 (Obsoleted by RFC 4033, RFC 4034, RFC 4035) ** Obsolete normative reference: RFC 2672 (Obsoleted by RFC 6672) ** Obsolete normative reference: RFC 2717 (Obsoleted by RFC 4395) ** Obsolete normative reference: RFC 2845 (Obsoleted by RFC 8945) ** Downref: Normative reference to an Historic RFC: RFC 2874 ** Obsolete normative reference: RFC 2929 (Obsoleted by RFC 5395) == Outdated reference: draft-ietf-xmldsig-core has been published as RFC 3075 -- Possible downref: Non-RFC (?) normative reference: ref. 'XML-NS' Summary: 20 errors (**), 0 flaws (~~), 9 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Donald E. Eastlake 3rd 2 INTERNET-DRAFT Motorola 3 Expires August 2001 February 2001 5 Considerations for URI and FQDN Protocol Parameters 6 -------------- --- --- --- ---- -------- ---------- 7 9 Donald E. Eastlake 3rd 11 Status of This Document 13 This document is intended to become a Best Current Practices RFC. 14 Comments should be sent to the author. 16 This document is an Internet-Draft and is in full conformance with 17 all provisions of Section 10 of RFC 2026. Internet-Drafts are 18 working documents of the Internet Engineering Task Force (IETF), its 19 areas, and its working groups. Note that other groups may also 20 distribute working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet- Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 Abstract 35 It is becoming increasingly common for protocol parameters to be of 36 URI or Domain Name syntax. Examples include TSIG algorithm 37 identifiers, XMLDSIG algorithm and type identifiers, XML namespaces, 38 etc. Considerations are provided for the allocation of such URI or 39 Domain Name syntax protocol parameter values. 41 Table of Contents 43 Status of This Document....................................1 44 Abstract...................................................1 46 Table of Contents..........................................2 48 1. Introduction............................................3 49 2. FQDN Syntax Parameters..................................3 50 2.1 IANA Allocation........................................4 51 2.2 'Working Group' Allocation.............................4 52 2.3 IESG/IETF Allocation...................................5 53 3. URI Syntax Parameters...................................5 54 3.1 Scheme Based Allocation................................5 55 3.2 Authority Based Allocation.............................6 56 3.3 Authority versus Path..................................6 57 4. Operational Considerations..............................6 58 5. Security Considerations.................................7 60 References.................................................8 62 Author's Address..........................................10 63 Expiration and File Name..................................10 65 1. Introduction 67 It is becoming increasingly common for protocol parameters to be of 68 URI [RFC 2396] or Domain Name [RFC 1035] syntax. Examples include 69 TSIG algorithm identifiers [RFC 2845], XMLDSIG algorithm and type 70 identifiers [RFC XMLDSIG], XML namespaces [XML-NS], etc. (The use of 71 a Domain Name syntax does not imply that a corresponding node exists 72 in the operational DNS nor does the use of URI syntax imply 73 dereferencability.) 75 This document provides considerations for the allocation of such 76 protocol parameter values when used for infrastructure or standards 77 purposes. (This should not be confused with the allocation and 78 registration of other parameter values for use inside the DNS 79 protocol, which is covered in [RFC 2929].) 81 Where the concept of domain name CLASS [RFC 1035, 2929] is 82 meaningful, all domain names referred to herein are considered to be 83 in the Internet (IN) CLASS. 85 2. FQDN Syntax Parameters 87 Fully Qualified Domain Name (FQDN) syntax is defined in [RFC 1035]. 88 Some additional information on the structure and management of the 89 operational DNS namespace is given in [RFCs 1591, 2606, and 2929]. 91 Some protocol paramters are specified such that their values are FQDN 92 syntax. While the use of such values, for example as TSIG algorithm 93 names [RFC 2845], does not necessarily imply the existence of a node 94 of the same name in the operational DNS system, such parameter values 96 SHOULD NOT incorporate a domain which is or is likely to become a 97 normal operational DNS domain unless the meaning and/or use of 98 the value is reasonably tied to the entity controlling the 99 operational domain for as long as the parameter value will be 100 in use, and 102 otherwise SHOULD use portions of the DNS name space set aside for 103 stable infrastructure and standards protocol parameter values, 104 particularly the .ARPA domain. 106 Unless provided to the contrary, allocation of any FQDN hereunder to 107 an entity implies authority of that entity to allocate subdomains 108 within the domain identified by that FQDN [RFC 1035]. 110 2.1 IANA Allocation 112 Infrastructure and standards protocol parameter domain names 113 allocated by IANA MUST be subordinate to a domain reserved for such 114 purposes, such as .ARPA or .REG.INT, and SHOULD be subordinate to the 115 top level domain name .ARPA. Such action shall occur only with an 116 IETF Standards Action, IETF Consensus, or IESG Approval [RFC 2434]. 117 The meaning and/or allocation criteria for sub-domains of such IANA 118 allocated domain names SHOULD be defined at the time of their 119 allocation. 121 Historic Note: The first infrastructure domain, IN-ADDR.ARPA, was 122 placed under .ARPA, which stood at the time for ARPANET, as part 123 of the transitions strategy from host table naming [RFC 881]. 124 Subsequently some infrastructure domains were assigned uner .INT, 125 for example TPC.INT [RFCs 1528-1530] and IP6.INT [RFC 1886]. 127 On 10 May, 2000, the Internet Architecture Board [IAB] issued a 128 statement redefining .ARPA to be the "Address and Routing 129 Parameters Area" where new infrastructure domains should be 130 placed, deprecating the placing of Internet infrastructure domains 131 under .INT, and recommending that, where appropriate, Internet 132 infrastructure domains under .INT be migrated to .ARPA. An 133 example of this is IP6.ARPA [RFC 2874]. 135 2.2 'Working Group' Allocation 137 Consistent with the IETF principal of lubricating and delegating 138 allocations so as to minimize bureaucratic barriers, the chair of any 139 Working Group (WG), BoF, or other entity properly allocated a 140 "Working Group" acronym by the IETF Secretariate may allocate Domain 141 Names to be used in developing, experimenting with, and testing 142 protocols. Such domain names will be subdomains of the entity 143 acronym under the year under IETF.ARPA. For example, matching 145 *.ACRONYM.2001.IETF.ARPA. 147 where "acronym" is a hypotetical WG acronym and 2001 is replaced by 148 the appropriate year. Such domain names MUST conform to the DNS 149 overall and label size syntax limits. This document allocates 150 IETF.ARPA for this purpose and use as described in section 2.3 below. 152 It is the responsibility of the working group to track these names 153 and avoid harmful duplication. These "Working Group" FQDNs SHOULD 154 NOT become permanently embedded in standards or the like. IANA is 155 NOT REQUIRED to register or track any such WG allocated domain names 156 unless and until so directed by a Standards Action, IETF Consensus, 157 or IESG Approval [RFC 2434]. 159 The common era year used SHOULD be the year at time of allocations 160 but MAY be a previous year in which the acronym identified entity 161 existed. The year is included for the following reasons: 163 While it is the current policy that working group acronyms will be 164 unique for all time, this policy could change or errors could 165 be made in acronym allocation. Incorporation of the year more 166 robustly assures against accidental duplication. 168 Since it is the responsibility of the WG to track these names, 169 incorporation of the year reduces the burden for tracking past 170 names to avoid duplication. 172 2.3 IESG/IETF Allocation 174 Subdomains below IETF.ARPA not conforming to the constraints give in 175 Section 2.2 above require an IETF Standards Action, IETF Consensus, 176 or IESG Approval [RFC 2434] for allocation. 178 3. URI Syntax Parameters 180 Uniform Resource Identifiers (URIs) [RFC 2396] generally conform to 181 the syntax 183 : 185 but, when the starts with a double slash 186 ("//"), the syntax is the more explicit 188 ://? 190 where , if it is not null, must start with a slash ("/") and 191 consists of slash separated path elements. 193 3.1 Scheme Based Allocation 195 The requirements for the registration of a new URI scheme are given 196 in [RFC 2717]. The designer of the scheme has great flexibility in 197 specifying the structure of and allocations/registration policies for 198 the scheme specific part and SHOULD specify any special considrations 199 if instances of the scheme are to be used in infrastructure or 200 standards URIs. 202 3.2 Authority Based Allocation 204 Where a URI follows the syntax that includes an section 205 as described above, then the structure of that authority part is 206 specified by the scheme. However, all schemes currently in public 207 use use the following structure: 209 [@][:] 211 where items in square brackets are optional. 213 The allocation/registration procedures specified in Section 2 above 214 should be followed for the FQDN (Fully Qualified Domain Name) part of 215 infrastructure and standards URIs. 217 Considerations for the allocation/registration of the optional 218 and parts, where present, SHOULD be specified when 219 the scheme is set up or the FQDN or an infrastructire / standards 220 ancester domain of the FQDN is allocated. 222 3.3 Authority versus Path 224 Where hierarhical subdivisions within an authority based URI are 225 desired, there are two primary ways to achieve this: via an 226 hierarchical component or via the hierarchical 227 component. It is also possible to combine these. 229 In the absence of considerations to the contrary, use of the 230 should be preferred for hierarhical parameter allocation. This is 231 because the frequently gets mapped to a host (or small set of 232 hosts). Extensive Domain Name System facilities such as wildcards, 233 CNAME, MX [RFC 1035], SRV [RFC 2782], and DNAME [RFC 2672] provide 234 flexibility in mapping subdomains and services to a large or small 235 number of hosts. 237 On the other had, if hierarchy is used heavily with a fixed 238 , then, if there are actaual network requests based on these 239 URIs, they will normally be constrained to inflexibly hitting a small 240 number of hosts. 242 4. Operational Considerations 244 [Do we want to get into this...?] 246 The use of a domain name as a protocol parameter, either by itself or 247 in a URI or elsewhere, does not necessarily imply that a 248 corresponding node exists in the operational global Domain Name 249 System (DNS). 251 The entity managing the .ARPA zone MUST make reasonable provision for 252 delegating infrastrucutre and standards subdomains where an 253 operational node in the global DNS is required for their use. In 254 particular, it is noted that IN-ADDR.ARPA and IP6.ARPA MUST be 255 allocated to the authorities for IPv4 and IPv6 addresses and that 256 IETF.ARPA MUST be allocated to the IETF Secretariate or an entity 257 that will operate it on their behalf. 259 5. Security Considerations 261 The protocol parameter allocation considerations herein do not 262 directly effect security. For DNS security considerations, see [RFC 263 2535]. For URI security considerations, see [RFC 2396]. 265 References 267 [IAB] - Internet Architecture Board, . 269 [RFC 881] - "Domain names plan and schedule", J. Postel, Nov-01-1983. 271 [RFC 1035] - "Domain names - implementation and specification", P.V. 272 Mockapetris, Nov-01-1987. 274 [RFC 1528] - "Principles of Operation for the TPC.INT Subdomain: 275 Remote Printing -- Technical Procedures", C. Malamud, M. Rose, 276 October 1993. 278 [RFC 1529] - "Principles of Operation for the TPC.INT Subdomain: 279 Remote Printing -- Administrative Policies", C. Malamud, M. Rose. 280 October 1993. 282 [RFC 1530] - "Principles of Operation for the TPC.INT Subdomain: 283 General Principles and Policy", C. Malamud, M. Rose, October 1993. 285 [RFC 1591] - "Domain Name System Structure and Delegation", J. 286 Postel, March 1994. 288 [RFC 1886] - "DNS Extensions to support IP version 6", S. Thomson, C. 289 Huitema, December 1995. 291 [RFC 2396] - "Uniform Resource Identifiers (URI): Generic Syntax", T. 292 Berners-Lee, R. Fielding, L. Masinter, August 1998. 294 [RFC 2434] - "Guidelines for Writing an IANA Considerations Section 295 in RFCs", T. Narten, H. Alvestrand, October 1998. 297 [RFC 2535] - "Domain Name System Security Extensions", D. Eastlake, 298 March 1999. 300 [RFC 2606] - "Reserved Top Level DNS Names", D. Eastlake, A. Panitz, 301 June 1999. 303 [RFC 2672] - "Non-Terminal DNS Name Redirection", M. Crawford, August 304 1999. 306 [RFC 2717] - R. Petke, I. King, "Registration Procedures for URL 307 Scheme Names", November 1999. 309 [RFC 2845] - "Secret Key Transaction Authentication for DNS (TSIG)", 310 P. Vixie, O. Gudmundsson, D. Eastlake, B. Wellington, May 2000. 312 [RFC 2874] - "DNS Extensions to Support IPv6 Address Aggregation and 313 Renumbering", M. Crawford, C. Huitema, July 2000. 315 [RFC 2782] - "A DNS RR for specifying the location of services (DNS 316 SRV)", A. Gulbrandsen, P. Vixie, L. Esibov, February 2000. 318 [RFC 2929] - "Domain Name System (DNS) IANA Considerations", D. 319 Eastlake 3rd, E. Brunner-Williams, B. Manning, September 2000. 321 [RFC XMLDSIG] - "XML-Signature Syntax and Processing" draft-ietf- 322 xmldsig-core-11.txt, D. Eastlake, J. Reagle, D. Solo, in RFC Editor's 323 queue for publication as a Proposed Standard. 325 [XML-NS] - "Namespaces in XML" , 326 T. Bray, D. Hollander, A. Layman, 14-January-1999. 328 Author's Address 330 Donald E. Eastlake 3rd 331 Motorola 332 155 Beaver Street 333 Milford, MA 01757 USA 335 Telephone: +1 508-634-2066(h) 336 +1 508-261-5434(w) 337 FAX: +1 508-261-4447(w) 338 email: Donald.Eastlake@motorola.com 340 Expiration and File Name 342 This draft expires August 2001. 344 Its file name is draft-eastlake-uri-fqdn-param-00.txt.