idnits 2.17.1 draft-faltstrom-uri-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 332. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 343. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 350. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 356. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- 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 18, 2008) is 5905 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) == Unused Reference: 'E164' is defined on line 277, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'E164' == Outdated reference: A later version (-08) exists of draft-iab-dns-choices-04 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Faltstrom 3 Internet-Draft Cisco 4 Intended status: Standards Track O. Kolkman 5 Expires: August 21, 2008 NLNet 6 February 18, 2008 8 The Uniform Resource Identifier (URI) DNS Resource Record 9 draft-faltstrom-uri-00.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on August 21, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2008). 40 Abstract 42 This document defines a new DNS resource record, called the Uniform 43 Resource Identifier (URI) RR, for publishing mappings from hostnames 44 to URIs. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 2. Applicability Statement . . . . . . . . . . . . . . . . . . . . 3 50 3. DNS considerations . . . . . . . . . . . . . . . . . . . . . . 4 51 4. The format of the URI RR . . . . . . . . . . . . . . . . . . . 4 52 4.1. Ownername, class and type . . . . . . . . . . . . . . . . . 4 53 4.2. Priority . . . . . . . . . . . . . . . . . . . . . . . . . 5 54 4.3. Weight . . . . . . . . . . . . . . . . . . . . . . . . . . 5 55 4.4. Target . . . . . . . . . . . . . . . . . . . . . . . . . . 5 56 4.5. URI RDATA Wire Format . . . . . . . . . . . . . . . . . . . 5 57 4.6. The URI RR Presentation Format . . . . . . . . . . . . . . 6 58 5. Definition of the flag 'D' for NAPTR records . . . . . . . . . 6 59 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 60 6.1. Homepage at one domain, but two domains in use . . . . . . 6 61 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 62 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 63 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 64 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 10.1. Normative References . . . . . . . . . . . . . . . . . . . 7 66 10.2. Non-normative references . . . . . . . . . . . . . . . . . 8 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 68 Intellectual Property and Copyright Statements . . . . . . . . . . 9 70 1. Introduction 72 This document explains the use of the Domain Name System (DNS) for 73 storage of URIs, and how to resolve hostnames to such URIs that can 74 be used by various applications. For resolution the application need 75 to know both the hostname and the protocol that the URI is to be used 76 for. The protocol is registered by IANA. 78 Currently, looking up URIs given a hostname uses the DDDS [RFC3401] 79 application framework with the DNS as a database as specified in RFC 80 3404 [RFC3404]. This have a number of implications as described in 81 draft-iab-dns-choices [I-D.iab-dns-choices] such as the inability to 82 select what NAPTR records that match the query is interesting. The 83 RRSet returned will always consist of all URIs "connected" with the 84 domain in question. 86 The URI resource record specified in this document create an ability 87 for the querying party to select which ones of the NAPTR records one 88 is interested in. This because data in the service field of the 89 NAPTR record is included in the owner part of the URI resource record 90 type. 92 Querying for the URI resource record type is not replacing querying 93 for the NAPTR (or S-NAPTR [RFC3958]) resource record type. Instead 94 it is a complementary mechanism to use when one know already what 95 service field is interesting. One can with the URI resource record 96 type directly query for the specific subset of the otherwise possibly 97 large RRSet given back when querying for NAPTR resource records. 99 This document updates RFC 3958 and RFC 3404 by adding the flag "D" to 100 the list of defined terminal flags in section 2.2.3 of RFC 3958 and 101 4.3 of RFC 3404. 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 105 document are to be interpreted as described in BCP 14, RFC 2119 106 [RFC2119]. 108 2. Applicability Statement 110 In general, it is expected that URI records will be used by clients 111 for applications where the relevant protocol to be used is known, but 112 for example extra abstraction given by separating a hostname from a 113 point of service (as address by the URI) is needed. Example of such 114 a situation is when an organisation have many domain names, but only 115 one official web page. 117 Applications MUST know the specific service fields to prepend the 118 hostname with. Using repetitive queries for URI records MUST NOT be 119 a replacement for querying for NAPTR or S-NAPTR records. NAPTR and 120 S-NAPTR records are for discovery of the various services and URI for 121 looking up access point for a given service. Those are two very 122 different kinds of needs. 124 3. DNS considerations 126 Using prefix labels, such as underscored service tags, prevents the 127 use of wildcards [I-D.iab-dns-choices], as constructs as 128 _s2._s1.*.example.net. are not possible in the DNS, see RFC 4592 129 [RFC4592]. Besides, underscored service tags used for the URI RR 130 (based on the NAPTR service descriptions) may have slightly different 131 semantics than service tags used for underscored prefix labels that 132 are used in combination with other (yet unspecified) RR types. This 133 may cause subtle management problems when delegation structure that 134 has developed within the context of URI RRs is also to be used for 135 other RR types. Since the service labels might be overloaded 136 applications should carefully check that the application level 137 protocol is indeed the protocol they expect. 139 Subtle management issues may also arise when the delegations from 140 service to sub service label involves several parties and different 141 stake holders. 143 4. The format of the URI RR 145 This is the format of the URI RR, whose DNS type code is NNNN (to be 146 assigned by IANA). 148 Ownername TTL Class URI Priority Weight Target 150 4.1. Ownername, class and type 152 The URI ownername is subject to special conventions. 154 Just like the SRV RR [ref] the URI RR has service information encoded 155 in its ownername. In order to encode the service for a specific 156 owner name one use service parameters. Valid service parameters used 157 are those as registered by IANA for NAPTR Records of any kind [ref to 158 IANA registry name]. The service parameters are reversed, prepended 159 with an underscore (_) and prepended to the owner name in separate 160 labels. The underscore is prepended to the service parameters to 161 avoid collisions with DNS labels that occur in nature, and the order 162 is reversed to make it possible to do delegations, if needed, to 163 different zones (and therefore providers of DNS). 165 For example, suppose we are looking for the URI for a service with 166 Service Parameter "A:B:C" for host example.com.. Then we would query 167 for (QNAME,QTYPE)=("_C._B._A.example.com","URI") 169 The type number for the URI record is NNNN (to be assigned by IANA). 171 The URI resource record is class independent. 173 The URI RR has no special TTL requirements. 175 4.2. Priority 177 The priority of this target URI. A client MUST attempt to contact 178 the URI with the lowest-numbered priority it can reach; URIs with the 179 same priority SHOULD be tried in an order defined by the weight 180 field. The range is 0-65535. This is a 16 bit unsigned integer in 181 network byte order. 183 4.3. Weight 185 A server selection mechanism. The weight field specifies a relative 186 weight for entries with the same priority. Larger weights SHOULD be 187 given a proportionately higher probability of being selected. The 188 range of this number is 0-65535. This is a 16 bit unsigned integer 189 in network byte order. 191 4.4. Target 193 The URI of the target. Resolution of the URI is according to the 194 definitions for the URI Scheme the URI consists of. 196 The URI is encoded as one or more RFC1035 section 197 3.3 [RFC1035]. 199 4.5. URI RDATA Wire Format 201 The RDATA for a URI RR consists of a 2 octet Priority field, a two 202 octet Weight field, and a variable length target field. 204 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 205 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 | Priority | Weight | 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 / / 210 / Target / 211 / / 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 4.6. The URI RR Presentation Format 216 The presentation format of the RDATA portion is as follows: 218 Priority field MUST be represented as an unsigned decimal integer. 220 The Weight Type field MUST be represented as an unsigned decimal 221 integer. 223 The target URI is enclosed in double-quotes ("). If the total length 224 of the URI exceeds 255 characters the URI will be encoded in multiple 225 . 227 5. Definition of the flag 'D' for NAPTR records 229 This document specifies the flag "D" for use as a flag in NAPTR 230 records. The flag indicate a terminal NAPTR record because it 231 denotes the end of the DDDS/NAPTR processing rules. In the case of a 232 "D" flag, the Replacement field in the NAPTR record is used as the 233 Owner of a DNS query for URI records, and normal URI processing as 234 defined in this document is applied. 236 The Regexp field in the NAPTR record MUST be empty when the 'D' flag 237 is in use. 239 6. Examples 241 6.1. Homepage at one domain, but two domains in use 243 An organisation have the domain names example.com and example.net, 244 but the official URI http://www.example.com/. Given the Service Tag 245 "web" for the imagined "homepage" application service, the following 246 URI Resource Records could be made available in the respective zones 247 (example.com and example.net): 249 $ORIGIN example.com. 250 IN NAPTR 1 1 "D" "http" ( ; service 251 "" ; regexp 252 _http ) ; replacement 253 _http IN URI 10 1 "http://www.example.com/" 255 $ORIGIN example.net. 256 IN NAPTR 1 1 "D" "http" ( ; service 257 "" ; regexp 258 _http ) ; replacement 259 _http IN URI 10 1 "http://www.example.com/" 261 7. IANA Considerations 263 8. Security Considerations 265 9. Acknowledgements 267 Ideas on how to split the two different kind of queries "What 268 services exists for this domain name" and "What is the URI for this 269 service" came from Scott Bradner and Lawrence Conroy. Other people 270 that have contributed to this document include Olafur Gudmundsson, 271 Maria Hall, Peter Koch and Penn Pfautz. 273 10. References 275 10.1. Normative References 277 [E164] ITU-T, "The International Public Telecommunication Number 278 Plan", Recommendation E.164, May 1997. 280 [RFC1035] Mockapetris, P., "Domain names - implementation and 281 specification", STD 13, RFC 1035, November 1987. 283 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 284 Requirement Levels", BCP 14, RFC 2119, March 1997. 286 [RFC3404] Mealling, M., "Dynamic Delegation Discovery System (DDDS) 287 Part Four: The Uniform Resource Identifiers (URI)", 288 RFC 3404, October 2002. 290 [RFC3958] Daigle, L. and A. Newton, "Domain-Based Application 291 Service Location Using SRV RRs and the Dynamic Delegation 292 Discovery Service (DDDS)", RFC 3958, January 2005. 294 10.2. Non-normative references 296 [I-D.iab-dns-choices] 297 Faltstrom, P., "Design Choices When Expanding DNS", 298 draft-iab-dns-choices-04 (work in progress), October 2006. 300 [RFC3401] Mealling, M., "Dynamic Delegation Discovery System (DDDS) 301 Part One: The Comprehensive DDDS", RFC 3401, October 2002. 303 [RFC4592] Lewis, E., "The Role of Wildcards in the Domain Name 304 System", RFC 4592, July 2006. 306 Authors' Addresses 308 Patrik Faltstrom 309 Cisco Systems 311 Email: paf@cisco.com 313 Olaf Kolkman 314 NLnet Labs 316 Email: olaf@NLnetLabs.nl 318 Full Copyright Statement 320 Copyright (C) The IETF Trust (2008). 322 This document is subject to the rights, licenses and restrictions 323 contained in BCP 78, and except as set forth therein, the authors 324 retain all their rights. 326 This document and the information contained herein are provided on an 327 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 328 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 329 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 330 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 331 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 332 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 334 Intellectual Property 336 The IETF takes no position regarding the validity or scope of any 337 Intellectual Property Rights or other rights that might be claimed to 338 pertain to the implementation or use of the technology described in 339 this document or the extent to which any license under such rights 340 might or might not be available; nor does it represent that it has 341 made any independent effort to identify any such rights. Information 342 on the procedures with respect to rights in RFC documents can be 343 found in BCP 78 and BCP 79. 345 Copies of IPR disclosures made to the IETF Secretariat and any 346 assurances of licenses to be made available, or the result of an 347 attempt made to obtain a general license or permission for the use of 348 such proprietary rights by implementers or users of this 349 specification can be obtained from the IETF on-line IPR repository at 350 http://www.ietf.org/ipr. 352 The IETF invites any interested party to bring to its attention any 353 copyrights, patents or patent applications, or other proprietary 354 rights that may cover technology that may be required to implement 355 this standard. Please address the information to the IETF at 356 ietf-ipr@ietf.org. 358 Acknowledgment 360 Funding for the RFC Editor function is provided by the IETF 361 Administrative Support Activity (IASA).