idnits 2.17.1 draft-daigle-unaptr-02.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 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 394. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 405. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 412. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 418. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == 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 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 271: '... DNS servers MAY interpret Flag valu...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 344 has weird spacing: '...ocation of se...' -- 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 10, 2007) is 6275 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) ** Obsolete normative reference: RFC 4234 (ref. '1') (Obsoleted by RFC 5234) ** Obsolete normative reference: RFC 2434 (ref. '6') (Obsoleted by RFC 5226) Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group L. Daigle 3 Internet-Draft Cisco Systems 4 Expires: August 14, 2007 February 10, 2007 6 Domain-based Application Service Location Using URIs and the Dynamic 7 Delegation Discovery Service (DDDS) 8 draft-daigle-unaptr-02.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 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 This Internet-Draft will expire on August 14, 2007. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 39 Abstract 41 The purpose of this document is to define a new, straightforward 42 Dynamic Delegation Discovery Service (DDDS) application to allow 43 mapping of domain names to URIs for particular application services 44 and protocols. Although defined as a new DDDS application, dubbed 45 U-NAPTR, this is effectively an extension of the Straightforward 46 NAPTR (S-NAPTR) DDDS application. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Straightforward URI-enabled NAPTR (U-NAPTR) . . . . . . . . . 3 52 2.1. Permitted Flags . . . . . . . . . . . . . . . . . . . . . 3 53 2.2. Permitted Regular Expressions . . . . . . . . . . . . . . 4 54 3. Sample U-NAPTR DNS records . . . . . . . . . . . . . . . . . . 4 55 4. Formal Definition of U-NAPTR Application of DDDS . . . . . . . 5 56 4.1. Application Unique String . . . . . . . . . . . . . . . . 5 57 4.2. First Well Known Rule . . . . . . . . . . . . . . . . . . 5 58 4.3. Expected Output . . . . . . . . . . . . . . . . . . . . . 5 59 4.4. Flags . . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 4.5. Service Parameters . . . . . . . . . . . . . . . . . . . . 5 61 4.5.1. Application Services . . . . . . . . . . . . . . . . . 6 62 4.5.2. Application Protocols . . . . . . . . . . . . . . . . 6 63 4.6. Valid Rules . . . . . . . . . . . . . . . . . . . . . . . 6 64 4.7. Valid Databases . . . . . . . . . . . . . . . . . . . . . 7 65 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 66 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 67 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 68 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 69 8.1. Normative References . . . . . . . . . . . . . . . . . . . 8 70 8.2. Informative References . . . . . . . . . . . . . . . . . . 9 71 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 72 Intellectual Property and Copyright Statements . . . . . . . . . . 10 74 1. Introduction 76 The purpose of this document is to define a new, straightforward 77 Dynamic Delegation Discovery Service (DDDS, [7]) application to allow 78 mapping of domain names to URIs for particular application services 79 and protocols. This allows the "lookup" of particular services 80 available for given domains, for example. 82 Although this is defining a new and separate DDDS application, dubbed 83 U-NAPTR, it is built from the same principles as the Straightforward 84 NAPTR (S-NAPTR) application, specified in [2]. This specification is 85 not an update of S-NAPTR, but the reader is encouraged to review that 86 document for extensive coverage of motivation and implementation 87 considerations. 89 S-NAPTR provides for application service location that does not rely 90 on rigid domain naming conventions. It is deemed "straightforward" 91 in part because it rules out the use of regular expressions in NAPTR 92 records (for the S-NAPTR DDDS Application). However, that also rules 93 out the possibility of providing a URI as the target of DDDS 94 resolution. A number of applications, specified (e.g., [9]) and 95 proposed, find the restriction too limiting, making S-NAPTR a near 96 miss to suit their needs. 98 This U-NAPTR is effectively a modest extension to S-NAPTR, to 99 accommodate the use of URIs as targets, without allowing the full 100 range of possible regular expressions in NAPTR records. 102 2. Straightforward URI-enabled NAPTR (U-NAPTR) 104 This document assumes the reader is familiar with the S-NAPTR 105 specification ([2]). The intention of U-NAPTR is to provide 106 everything that S-NAPTR does, except that it allows the use of the 107 "U" flag in the NAPTR record, and a specific form of REGEXP. 109 2.1. Permitted Flags 111 U-NAPTR permits the same flags as S-NAPTR ("S", "A", or empty), plus 112 the "U" Flag. For the U-NAPTR DDDS Application, the presence of the 113 "U" Flag in the NAPTR record indicates the REGEXP field must be 114 populated (and, consequently, the REPLACEMENT field is empty). The 115 regular expression in the REGEXP field must be of the limited form 116 described below, and the result of the regular expression evaluation 117 will be a URI that is the result of the DDDS resolution. 119 2.2. Permitted Regular Expressions 121 U-NAPTR permits regular expressions of a form that does a complete 122 replacement of the matched string with a URI, expressed as a constant 123 string. This is essentially a dodge around the fact that the 124 REPLACEMENT field in NAPTR is required to produce only a fully 125 qualified domain name (and, therefore, cannot be used for a URI). 127 The specific allowed syntax for U-NAPTR regular expressions is: 129 u-naptr-regexp = "!.*!""!" 131 where is as defined in STD 66 [8], the URI syntax 132 specification. 134 With this limited form of regular expression, applications using 135 U-NAPTR need not implement full regular expression parsers. 137 3. Sample U-NAPTR DNS records 139 In the sample NAPTR RRs for example.com shown below, "WP" is the 140 imagined application service tag for "white pages", and "EM" is the 141 application service tag for an imagined "Extensible Messaging" 142 application service. 144 example.com. 145 ;; order pref flags 146 IN NAPTR 100 10 "" "WP:whois++" ( ; service 147 "" ; regexp 148 bunyip.example.com. ; replacement 149 ) 150 IN NAPTR 100 20 "s" "WP:ldap" ( ; service 151 "" ; regexp 152 _ldap._tcp.myldap.example.com. ; replacement 153 ) 154 IN NAPTR 200 10 "u" "EM:protA" ( ; service 155 "!.*!prota://someisp.example.com!" ; regexp 156 "" ; replacement 157 ) 158 IN NAPTR 200 30 "a" "EM:protB" ; service 159 "" ; regexp 160 myprotB.example.com.; replacement 161 ) 163 4. Formal Definition of U-NAPTR Application of DDDS 165 This section formally defines the DDDS application, as described in 166 [7]. 168 4.1. Application Unique String 170 The Application Unique String is a fully quallified domain name 171 (FQDN) for which an authoritative server for a particular service is 172 sought. 174 4.2. First Well Known Rule 176 The "First Well Known Rule" is identity -- that is, the output of the 177 rule is the Application Unique String, the FQDN for which the 178 authoritative server for a particular service is sought. 180 4.3. Expected Output 182 The expected output of this Application is the information necessary 183 to connect to authoritative server(s) (host, port, protocol, or URI) 184 for an application service within a given domain. 186 4.4. Flags 188 This DDDS Application uses only 3 of the Flags defined for the URI/ 189 URN Resolution Application ([5]): "S", "A", and "U". No other Flags 190 are valid. If a client obtains a NAPTR RR for a U-NAPTR-using 191 application that contains any other flag, that NAPTR RR should be 192 ignored and processing continues with the next record (if any). 194 These flags are for terminal lookups. This means that the Rule is 195 the last one and that the flag determines what the next stage should 196 be. The "S" flag means that the output of this Rule is a FQDN for 197 which one or more SRV [3] records exist. "A" means that the output 198 of the Rule is a domain name and should be used to lookup address 199 records for that domain. "U" means that the output of the Rule is a 200 URI which should be resolved in order to obtain access to the 201 described service. 203 Consistent with the DDDS algorithm, if the Flag string is empty the 204 next lookup is for another NAPTR record (for the replacement target). 206 4.5. Service Parameters 208 Service Parameters for this Application take the form of a string of 209 characters that follow this ABNF ([1]): 211 service-parms = [ [app-service] *(":" app-protocol)] 212 app-service = experimental-service / iana-registered-service 213 app-protocol = experimental-protocol / iana-registered-protocol 214 experimental-service = "x-" 1*30ALPHANUMSYM 215 experimental-protocol = "x-" 1*30ALPHANUMSYM 216 iana-registered-service = ALPHA *31ALPHANUMSYM 217 iana-registered-protocol = ALPHA *31ALPHANUM 218 ALPHA = %x41-5A / %x61-7A ; A-Z / a-z 219 DIGIT = %x30-39 ; 0-9 220 SYM = %x2B / %x2D / %x2E ; "+" / "-" / "." 221 ALPHANUMSYM = ALPHA / DIGIT / SYM 222 ; The app-service and app-protocol tags are limited to 32 223 ; characters and must start with an alphabetic character. 224 ; The service-parms are considered case-insensitive. 226 Thus, the Service Parameters may consist of an empty string, just an 227 app-service, or an app-service with one or more app-protocol 228 specifications separated by the ":" symbol. 230 Note that this is similar to, but not the same as the syntax used in 231 the URI DDDS application ([5]). The DDDS DNS database requires each 232 DDDS application to define the syntax of allowable service strings. 233 The syntax here is expanded to allow the characters that are valid in 234 any URI scheme name (see [8]). Since "+" (the separator used in the 235 RFC3404 service parameter string) is an allowed character for URI 236 scheme names, ":" is chosen as the separator here. 238 4.5.1. Application Services 240 The "app-service" must be an IANA-registered service; see Section 5 241 for instructions on registering new application service tags. 243 4.5.2. Application Protocols 245 The protocol identifiers that are valid for the "app-protocol" 246 production are standard, registered protocols; see Section 5 for 247 instructions on registering new application protocol tags. 249 4.6. Valid Rules 251 Permitted rules are substitution rules and regular expressions of the 252 following syntax (i.e., a regular expression to replace the domain 253 name with a URI): 255 u-naptr-regexp = "!.*!""!" 257 where is as defined in STD 66 [8], the URI syntax 258 specification. 260 4.7. Valid Databases 262 At present only one DDDS Database is specified for this Application. 263 [4] specifies a DDDS Database that uses the NAPTR DNS resource record 264 to contain the rewrite rules. The Keys for this database are encoded 265 as domain-names. 267 The First Well Known Rule produces a domain name, and this is the Key 268 that is used for the first lookup -- the NAPTR records for that 269 domain are requested. 271 DNS servers MAY interpret Flag values and use that information to 272 include appropriate NAPTR, SRV or A records in the Additional 273 Information portion of the DNS packet. Clients are encouraged to 274 check for additional information but are not required to do so. See 275 the Additional Information Processing section of [4] for more 276 information on NAPTR records and the Additional Information section 277 of a DNS response packet. 279 5. IANA Considerations 281 This document does not itself place any requirements on IANA, but 282 provides the basis upon which U-NAPTR-using services can make use of 283 the existing IANA registries for application service tags and 284 application protocol tags (defined in RFC3958, [2]). 286 As is the case for S-NAPTR, all application service and protocol tags 287 that start with "x-" are considered experimental, and no provision is 288 made to prevent duplicate use of the same string. Use them at your 289 own risk. 291 All other application service and protocol tags are registered based 292 on the "specification required" option defined in [6], with the 293 further stipulation that the "specification" is an RFC (of any 294 category). 296 There are no further restrictions placed on the tags other than that 297 they must conform with the syntax defined above (Section 4.5). 299 The defining RFC must clearly identify and describe, for each tag 300 being registered: 301 o Application protocol or service tag 302 o Intended usage 303 o Interoperability considerations 304 o Security considerations (see Section 6 of this document for 305 further discussion of the types of considerations that are 306 applicable) 308 o Any relevant related publications 310 The defining RFC may also include further application-specific 311 restrictions, such as limitations on the types of URIs that may be 312 returned for the application service. 314 6. Security Considerations 316 U-NAPTR has the same considerations for security as S-NAPTR; see 317 Section 8 of [2]). U-NAPTR has the additional consideration that 318 resolving URIs (from the result of the DDDS resolution) has its own 319 set of security implications, covered in the URI specification (in 320 particular, Section 7 of [8]). In essence, using DNSSEC, client 321 software can be confident that the URI obtained using U-NAPTR is 322 indeed the one specified by the administrator of the domain from 323 which it was retrieved; but the validity of the service reached by 324 resolving that URI is a matter of URI resolution security practices. 326 7. Acknowledgements 328 Thanks to Martin Thomson, John Klensin, Bernard Aboba, Alfred Hoenes, 329 Dan Romascanu, Suresh Krishnan, and Lars Eggert for reviewing earlier 330 drafts and catching errors! 332 8. References 334 8.1. Normative References 336 [1] Crocker, D. and P. Overell, "Augmented BNF for Syntax 337 Specifications: ABNF", RFC 4234, October 2005. 339 [2] Daigle, L. and A. Newton, "Domain-Based Application Service 340 Location Using SRV RRs and the Dynamic Delegation Discovery 341 Service (DDDS)", RFC 3958, January 2005. 343 [3] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 344 specifying the location of services (DNS SRV)", RFC 2782, 345 February 2000. 347 [4] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part 348 Three: The Domain Name System (DNS) Database", RFC 3403, 349 October 2002. 351 [5] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part 352 Four: The Uniform Resource Identifiers (URI)", RFC 3404, 353 October 2002. 355 [6] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 356 Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 358 8.2. Informative References 360 [7] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part 361 One: The Comprehensive DDDS", RFC 3401, October 2002. 363 [8] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 364 Resource Identifier (URI): Generic Syntax", RFC 3986, STD 66, 365 January 2005. 367 [9] Malamud, C., "Attaching Meaning to Solicitation Class Keywords", 368 RFC 4095, May 2005. 370 Author's Address 372 Leslie L. Daigle 373 Cisco Systems 374 13600 Dulles Technology Drive 375 Herndon, VA 20171 376 US 378 Email: ledaigle@cisco.com; leslie@thinkingcat.com 380 Full Copyright Statement 382 Copyright (C) The IETF Trust (2007). 384 This document is subject to the rights, licenses and restrictions 385 contained in BCP 78, and except as set forth therein, the authors 386 retain all their rights. 388 This document and the information contained herein are provided on an 389 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 390 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 391 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 392 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 393 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 394 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 396 Intellectual Property 398 The IETF takes no position regarding the validity or scope of any 399 Intellectual Property Rights or other rights that might be claimed to 400 pertain to the implementation or use of the technology described in 401 this document or the extent to which any license under such rights 402 might or might not be available; nor does it represent that it has 403 made any independent effort to identify any such rights. Information 404 on the procedures with respect to rights in RFC documents can be 405 found in BCP 78 and BCP 79. 407 Copies of IPR disclosures made to the IETF Secretariat and any 408 assurances of licenses to be made available, or the result of an 409 attempt made to obtain a general license or permission for the use of 410 such proprietary rights by implementers or users of this 411 specification can be obtained from the IETF on-line IPR repository at 412 http://www.ietf.org/ipr. 414 The IETF invites any interested party to bring to its attention any 415 copyrights, patents or patent applications, or other proprietary 416 rights that may cover technology that may be required to implement 417 this standard. Please address the information to the IETF at 418 ietf-ipr@ietf.org. 420 Acknowledgment 422 Funding for the RFC Editor function is provided by the IETF 423 Administrative Support Activity (IASA).