idnits 2.17.1 draft-brandner-enum-uri-01.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 -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 389 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 70 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** There are 8 instances of lines with control characters in the document. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. ** 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 57: '...compliant client MUST generate a query...' RFC 2119 keyword, line 116: '...is that a client MUST use this E.164 n...' RFC 2119 keyword, line 121: '...case, the client MUST generate an ENUM...' RFC 2119 keyword, line 133: '... appended to it SHOULD be ignored wit...' RFC 2119 keyword, line 143: '..., an ENUM client SHOULD NOT re-submit ...' (3 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- No information found for draft-antti-RFC2806bis - is the name correct? -- Possible downref: Normative reference to a draft: ref. '1' -- No information found for draft-ietf-enum-rfc2916bis-3 - is the name correct? -- Possible downref: Normative reference to a draft: ref. '3' Summary: 7 errors (**), 0 flaws (~~), 4 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IPTEL Working Group R.Brandner 2 Internet-Draft Siemens 3 L.Conroy 4 Siemens 5 R.Stastny 6 OeFEG 7 Expires: August, 2003 February 24th, 2003 9 'The "enum:" URI scheme' 10 draft-brandner-enum-uri-01.txt 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. 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-Drafts 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on August 24, 2003. 34 Copyright Notice 36 Copyright (C) The Internet Society (2002). All Rights Reserved. 38 Abstract 40 This document specifies the "enum:" URI scheme. This URI is intended for 41 use where a resource address can be returned by evaluating the URI value 42 using the ENUM DDDS application. Syntactically, it uses a subset of the 43 format defined for the "tel:" URI scheme. 45 1. Introduction 47 The tel: URI is specified in RFC2806bis [1]. This holds a telephone 48 number and optional parameters. It can be used to initiate a telephone 49 call to the number it holds as its value, or may be used within a SIP 50 session setup (e.g. it may be used in the from: or to: fields of a SIP 51 Invite message; see RFC3261 [2] for more details). The "tel:" URI does 52 not specify whether or not an ENUM [3] query should be made prior to 53 initiating a call; thus a "tel:" client may or may not generate a 54 request to the ENUM infrastructure. 56 It is convenient to have a URI that appears very similar in format to 57 the "tel:" URI, but with which a compliant client MUST generate a query 58 on the ENUM system. That is the role for the "enum:" URI scheme, as 59 specified in this document. 61 1.1. Expected Usage 63 A URI is not appropriate for all situations in which a telephone number 64 may be found, and this is as true for an "enum:" URI as a "tel:" URI. 65 Some situations where URIs can't be used are: 67 - Call delivered to a Media Gateway has a Destination Number only. 69 - PSTN Signaling System No.7 messages have Source and Destination 70 Numbers or Digits; they do not have URIs. 72 - In the interface to a telephone, normally the user enters a 73 destination 'phone number or identifier, not a URI 75 The "enum:" URI is expected to find use on Web Pages and in email 76 signatures, for example. Whilst it would be possible to publish the URIs 77 that were generated by the NAPTRs (NAPTRs are defined in [4]) stored 78 within ENUM, this would miss the selectivity by enumservice that ENUM 79 provides, and could easily lead to a lack of synchronization between the 80 various URI values. 82 As a URI, in principle it may appear anywhere that another URI might. 83 However, its use in other services such as in H.323 or SIP systems (for 84 example, in the To: field of a SIP Invite message) is NOT recommended 85 here - such use would at least require further consideration and may 86 well require further standardization. 88 An "enum:" URI can appear as the constructed value that is the result of 89 ENUM processing (as can any other URI). 91 1.2. Document Content 93 The syntax for this URI-scheme is covered in the next section. The 94 subsequent section covers the expected client behavior, whilst section 95 4 covers the security and privacy issues associated with this scheme, 96 and this is followed by the IANA considerations for this document. 98 2. Syntax for the "enum:" URI scheme 100 The syntax of this scheme is a subset of that defined for the "tel:" 101 scheme defined in RFC2806bis. In particular, the local-number form is 102 excluded, and the global-number form excludes the optional 103 isdn-subaddress parameter. 105 enum-uri = enum-uritoken enumref 107 enum-uritoken = "enum:" 109 enumref = global-number-part 111 (global-number-part as defined in RFC2806bis) 113 3. Expected Client Behavior 115 This URI scheme encloses a value in the form of an E.164 telephone 116 number. The intention is that a client MUST use this E.164 number to 117 generate a query to the ENUM infrastructure in order to evaluate this 118 URI. 120 The essential difference between this URI scheme and the "tel:" scheme 121 is that, in this case, the client MUST generate an ENUM query to resolve 122 the resource, whilst in the case of the "tel:" scheme, the client may 123 generate such a query or instead directly set up a phone call to the 124 "tel:" URI value using a local or shared GSTN connection - its behavior 125 in this is undefined. 127 3.1. URI parameters 129 This URI scheme does not use parameters - its sole purpose is to be 130 passed to an ENUM client processor. The E.164 number that is the URI 131 value is used as input to the ENUM process; no other parameters are 132 relevant in this case. Thus, when processing this URI, any parameters 133 appended to it SHOULD be ignored with the URI value being passed to an 134 ENUM process alone. 136 3.2. "enum:" URI usage within ENUM domain space 138 This section covers the specific case where an "enum:" URI is present as 139 the value constructed from processing a NAPTR "under" e.164.arpa. using 140 the ENUM process, and the interactions with the ENUM client application 141 this involves. 143 As a general principle, an ENUM client SHOULD NOT re-submit a query to 144 the ENUM system if it receives a "tel:" URI in response to its current 145 query. However, if an "enum:" URI is the result of ENUM processing, then 146 the client MUST re-submit it (i.e. use the "enum:" URI value to generate 147 a new ENUM query). 149 3.2.1. "enum:" URI - comparisons with uses of other approaches 151 * "enum:" versus "tel:" 153 The difference between "tel:" or "enum:" URIs that are generated as the 154 result of ENUM processing is that evaluation of the "enum:" URI MUST 155 initiate a re-submission of a query to the ENUM system (using the 156 enclosed global-number-part), whilst a client SHOULD NOT re-submit the 157 contents of a "tel:" URI to the ENUM infrastructure. 159 * "enum:" versus CNAME 161 An "enum:" URI differs from the use of a CNAME within a sub-domain of 162 e164.arpa in that a redirection to another part of the ENUM domain space 163 can be effected for an individual NAPTR that meets the matching 164 criteria. With CNAME, it is the only Resource Record for a DNS domain, 165 so that ALL queries would be redirected. 167 * "enum:" versus non-terminal NAPTR 169 An "enum:" URI differs from the use of the "replacement" field of a 170 non-terminal NAPTR in that with a replacement field the DDDS application 171 continues its processing, whilst an "enum:" URI is the result of a query 172 - it is part of a "terminal" NAPTR and allows the client application to 173 evaluate its requirements prior to re-submission. 175 The global-number-part syntax used with "enum:" URIs has certain 176 advantages in REGEXP processing within "terminal" NAPTRs when selective 177 redirection within the e164.arpa. "golden tree" is required. The URI 178 takes phone numbers as its value. REGEXP processing of the ENUM 179 Application Unique String (see [3] for details) to generate a different 180 phone number is more straightforward than attempting to generate a 181 domain name within e164.arpa. space. 183 Use of "enum:" URIs allows a Registrant (ENUM Subscriber) of several 184 ENUM domains (each associated with a different number) to redirect 185 queries temporarily to a single domain associated with a phone number 186 and so within e164.arpa. space without recourse to requesting changes to 187 Tier1 NS records for the domains, and to do so selectively for different 188 enumservice-specialised entries. This can be done using "non-terminal" 189 NAPTRs and explicit domain names within the e164.arpa. space. However, 190 experience in Trials has shown that the "reversed number" domains that 191 requires are not as intuitively obvious as phone numbers. Customer- 192 provisioning is much easier if a simple URI is to be installed; CNAMEs 193 and "reversed domain" replacement fields are prone to "user error". 195 3.2.2. Example of use of "enum:" URI in e164.arpa. 197 Redirection from one part of the e164.arpa. tree (associated with one 198 E.164 number) to another part of the tree (associated with another 199 number) can be difficult, particularly with variable length numbers. 200 For example, converting from the number +432221234567890 to the 201 number +4311234567890 without "hard coding" the REGEXP (or the 202 replacement field, in a "non-terminal" NAPTR) is not easy. 204 If a domain name within e164.arpa is to be constructed using a REGEXP 205 from the ENUM Application Unique String (effectively, the input phone 206 number), then the digits have to be reversed; not easy and perhaps 207 impossible with variable length digit strings. 209 (i) As an alternative to constructing a domain name within e164.arpa., an 210 "enum:" URI could be readily constructed using simple REGEXP processing, 211 and re-submission of this would have a similar effect. For example, 213 0.9.8.7.6.5.4.3.2.1.2.2.2.3.4.e164.arpa. 214 IN NAPTR 10 10 "E2U+esx" "!^43222(.*)$!enum:+431\1!" . 216 would suffice to redirect an ENUM query of +432221234567890 to look at 217 the domain associated with number +4311234567890 for queries that 218 matched the enumservice "esx". 220 (ii) In fact, an identical REGEXP subsequent part could be used in any 221 number of different e164.arpa. domains to map from one area of the tree 222 to another. Thus, exactly the same REGEXP field (in fact, the same 223 NAPTR content) within another domain under 2.2.2.3.4.e164.arpa. could 224 be used to redirect a query to "its" equivalent number. Thus: 226 9.0.1.2.3.4.5.6.7.8.2.2.2.3.4.ea64.arpa. 227 IN NAPTR 10 10 "E2U+esx" "!^43222(.*)$!enum:+431\1!" . 229 would redirect an ENUM query of +432228765432109 to look at the domain 230 associated with number +4318765432109 for queries that matched the 231 enumservice "esx". 233 (iii) Finally, this is how an "enum:" URI might be used in a "wildcard" 234 Resource Record. Note that the use of DNS wildcards is NOT recommended 235 here; this merely shows how a wildcard MIGHT be used with an "enum:" 236 URI. 238 2.2.2.3.4.e164.arpa. 239 * IN NAPTR 10 10 "E2U+esx" "!^43222(.*)$!enum:+431\1!" . 241 The intention here would be to redirect queries on any number "under" 242 the area code +43-222 to the area code +43-1, for any ENUM query that 243 matched the enumserevice "esx". This of course assumes that there are 244 NO Resource Records "under" 2.2.2.3.4.e164.arpa. 246 Note that a similar affect might be achieved by the use of a DNAME 247 record. However, in that case the value returned would depend on 248 whether or not the extended DNS option flags were set in the query, 249 and the target suffix used in the DNAME Resource Record would be a 250 "reversed domain". 252 4. Security Issues 254 Our initial thought is that the "enum:" URI has no more security and 255 privacy implications above any other use of ENUM. Also, it has similar 256 privacy implications to the use of a "tel:" URI. 258 Publication of an "enum:" URI, for example within a Web page, DOES 259 indicate that there is an ENUM entry with this value as a key. This 260 exposes some information, but as this can be found out anyway by the 261 expedient of performing a test ENUM query, it is not seen as being 262 important. 264 5. IANA Considerations 266 This document specifies a URI scheme. To ensure that this URI scheme 267 value does not collide with other uses, it is necessary to register this 268 token. 270 Thus this requests that this document be considered a specification for 271 the 'enum:' URI scheme, and that a registration be made for this use. 273 6. Acknowledgments 275 Jon Peterson gave constructive comments on the "enum:" URI. 277 7. History 279 Version - 0 , issued June 2002 280 - Initial version. 282 Version - 1 , issued February 2003 283 - removed reference to ENUM 'es' URI parameter 285 - added recommendation to ignore any included parameters 287 - removed reference to combination of 'es' parameter values with 288 client selection 290 8. References 292 [1] H. Schulzrinne, A. Vaha-Sipila, 293 "URIs for Telephone Calls", 294 draft-antti-RFC2806bis-07.txt, 295 Work in progress, December 2002 297 [2] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. 298 Peterson, R. Sparks, M. Handley, E. Schooler "SIP: session initiation 299 protocol", 300 RFC3261, Internet Engineering task Force, June 2002 302 [3] P. Faltstrom, M. Mealling, 303 "The E.164 to URI DDDS Application (ENUM)", 304 draft-ietf-enum-rfc2916bis-3.txt, 305 Work in progress, January 2003 307 [4] M. Mealling, "Dynamic Delegation Discovery System (DDDS) 308 Part Three: The Domain Name System (DNS) Database", 309 RFC3403, Internet Engineering task Force, October 2002 311 9. Authors' Addresses 313 Rudolf Brandner 315 Siemens ICN 316 Hofmannstrasse 51 317 Munich 318 Germany 320 Email: 321 Phone: 322 URI: 324 Lawrence Conroy 326 Siemens Roke Manor Research 327 Roke Manor 328 Romsey 329 U.K. 331 Email: 332 Phone: 334 Richard Stastny 336 OeFEG 337 Postbox 147 338 1103 Vienna, Austria 340 Email: 341 Phone: 343 Full Copyright Statement 345 Copyright (C) The Internet Society (2000). All Rights Reserved. 347 This document and translations of it may be copied and furnished to 349 others, and derivative works that comment on or otherwise explain it 350 or assist in its implementation may be prepared, copied, published 351 and distributed, in whole or in part, without restriction of any 352 kind, provided that the above copyright notice and this paragraph are 353 included on all such copies and derivative works. However, this 354 document itself may not be modified in any way, such as by removing 355 the copyright notice or references to the Internet Society or other 356 Internet organizations, except as needed for the purpose of 357 developing Internet standards in which case the procedures for 358 copyrights defined in the Internet Standards process must be 359 followed, or as required to translate it into languages other than 360 English. 362 The limited permissions granted above are perpetual and will not be 363 revoked by the Internet Society or its successors or assigns. 365 This document and the information contained herein is provided on an 366 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 367 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 368 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 369 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 370 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.