IPTEL Working Group R.Brandner Internet-Draft Siemens L.Conroy Siemens R.Stastny OeFEG Expires: August, 2003 February 24th, 2003 'The "enum:" URI scheme' draft-brandner-enum-uri-01.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. This Internet-Draft will expire on August 24, 2003. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract This document specifies the "enum:" URI scheme. This URI is intended for use where a resource address can be returned by evaluating the URI value using the ENUM DDDS application. Syntactically, it uses a subset of the format defined for the "tel:" URI scheme. 1. Introduction The tel: URI is specified in RFC2806bis [1]. This holds a telephone number and optional parameters. It can be used to initiate a telephone call to the number it holds as its value, or may be used within a SIP session setup (e.g. it may be used in the from: or to: fields of a SIP Invite message; see RFC3261 [2] for more details). The "tel:" URI does not specify whether or not an ENUM [3] query should be made prior to initiating a call; thus a "tel:" client may or may not generate a request to the ENUM infrastructure. It is convenient to have a URI that appears very similar in format to the "tel:" URI, but with which a compliant client MUST generate a query on the ENUM system. That is the role for the "enum:" URI scheme, as specified in this document. 1.1. Expected Usage A URI is not appropriate for all situations in which a telephone number may be found, and this is as true for an "enum:" URI as a "tel:" URI. Some situations where URIs can't be used are: - Call delivered to a Media Gateway has a Destination Number only. - PSTN Signaling System No.7 messages have Source and Destination Numbers or Digits; they do not have URIs. - In the interface to a telephone, normally the user enters a destination 'phone number or identifier, not a URI The "enum:" URI is expected to find use on Web Pages and in email signatures, for example. Whilst it would be possible to publish the URIs that were generated by the NAPTRs (NAPTRs are defined in [4]) stored within ENUM, this would miss the selectivity by enumservice that ENUM provides, and could easily lead to a lack of synchronization between the various URI values. As a URI, in principle it may appear anywhere that another URI might. However, its use in other services such as in H.323 or SIP systems (for example, in the To: field of a SIP Invite message) is NOT recommended here - such use would at least require further consideration and may well require further standardization. An "enum:" URI can appear as the constructed value that is the result of ENUM processing (as can any other URI). 1.2. Document Content The syntax for this URI-scheme is covered in the next section. The subsequent section covers the expected client behavior, whilst section 4 covers the security and privacy issues associated with this scheme, and this is followed by the IANA considerations for this document. 2. Syntax for the "enum:" URI scheme The syntax of this scheme is a subset of that defined for the "tel:" scheme defined in RFC2806bis. In particular, the local-number form is excluded, and the global-number form excludes the optional isdn-subaddress parameter. enum-uri = enum-uritoken enumref enum-uritoken = "enum:" enumref = global-number-part (global-number-part as defined in RFC2806bis) 3. Expected Client Behavior This URI scheme encloses a value in the form of an E.164 telephone number. The intention is that a client MUST use this E.164 number to generate a query to the ENUM infrastructure in order to evaluate this URI. The essential difference between this URI scheme and the "tel:" scheme is that, in this case, the client MUST generate an ENUM query to resolve the resource, whilst in the case of the "tel:" scheme, the client may generate such a query or instead directly set up a phone call to the "tel:" URI value using a local or shared GSTN connection - its behavior in this is undefined. 3.1. URI parameters This URI scheme does not use parameters - its sole purpose is to be passed to an ENUM client processor. The E.164 number that is the URI value is used as input to the ENUM process; no other parameters are relevant in this case. Thus, when processing this URI, any parameters appended to it SHOULD be ignored with the URI value being passed to an ENUM process alone. 3.2. "enum:" URI usage within ENUM domain space This section covers the specific case where an "enum:" URI is present as the value constructed from processing a NAPTR "under" e.164.arpa. using the ENUM process, and the interactions with the ENUM client application this involves. As a general principle, an ENUM client SHOULD NOT re-submit a query to the ENUM system if it receives a "tel:" URI in response to its current query. However, if an "enum:" URI is the result of ENUM processing, then the client MUST re-submit it (i.e. use the "enum:" URI value to generate a new ENUM query). 3.2.1. "enum:" URI - comparisons with uses of other approaches * "enum:" versus "tel:" The difference between "tel:" or "enum:" URIs that are generated as the result of ENUM processing is that evaluation of the "enum:" URI MUST initiate a re-submission of a query to the ENUM system (using the enclosed global-number-part), whilst a client SHOULD NOT re-submit the contents of a "tel:" URI to the ENUM infrastructure. * "enum:" versus CNAME An "enum:" URI differs from the use of a CNAME within a sub-domain of e164.arpa in that a redirection to another part of the ENUM domain space can be effected for an individual NAPTR that meets the matching criteria. With CNAME, it is the only Resource Record for a DNS domain, so that ALL queries would be redirected. * "enum:" versus non-terminal NAPTR An "enum:" URI differs from the use of the "replacement" field of a non-terminal NAPTR in that with a replacement field the DDDS application continues its processing, whilst an "enum:" URI is the result of a query - it is part of a "terminal" NAPTR and allows the client application to evaluate its requirements prior to re-submission. The global-number-part syntax used with "enum:" URIs has certain advantages in REGEXP processing within "terminal" NAPTRs when selective redirection within the e164.arpa. "golden tree" is required. The URI takes phone numbers as its value. REGEXP processing of the ENUM Application Unique String (see [3] for details) to generate a different phone number is more straightforward than attempting to generate a domain name within e164.arpa. space. Use of "enum:" URIs allows a Registrant (ENUM Subscriber) of several ENUM domains (each associated with a different number) to redirect queries temporarily to a single domain associated with a phone number and so within e164.arpa. space without recourse to requesting changes to Tier1 NS records for the domains, and to do so selectively for different enumservice-specialised entries. This can be done using "non-terminal" NAPTRs and explicit domain names within the e164.arpa. space. However, experience in Trials has shown that the "reversed number" domains that requires are not as intuitively obvious as phone numbers. Customer- provisioning is much easier if a simple URI is to be installed; CNAMEs and "reversed domain" replacement fields are prone to "user error". 3.2.2. Example of use of "enum:" URI in e164.arpa. Redirection from one part of the e164.arpa. tree (associated with one E.164 number) to another part of the tree (associated with another number) can be difficult, particularly with variable length numbers. For example, converting from the number +432221234567890 to the number +4311234567890 without "hard coding" the REGEXP (or the replacement field, in a "non-terminal" NAPTR) is not easy. If a domain name within e164.arpa is to be constructed using a REGEXP from the ENUM Application Unique String (effectively, the input phone number), then the digits have to be reversed; not easy and perhaps impossible with variable length digit strings. (i) As an alternative to constructing a domain name within e164.arpa., an "enum:" URI could be readily constructed using simple REGEXP processing, and re-submission of this would have a similar effect. For example, 0.9.8.7.6.5.4.3.2.1.2.2.2.3.4.e164.arpa. IN NAPTR 10 10 "E2U+esx" "!^43222(.*)$!enum:+431\1!" . would suffice to redirect an ENUM query of +432221234567890 to look at the domain associated with number +4311234567890 for queries that matched the enumservice "esx". (ii) In fact, an identical REGEXP subsequent part could be used in any number of different e164.arpa. domains to map from one area of the tree to another. Thus, exactly the same REGEXP field (in fact, the same NAPTR content) within another domain under 2.2.2.3.4.e164.arpa. could be used to redirect a query to "its" equivalent number. Thus: 9.0.1.2.3.4.5.6.7.8.2.2.2.3.4.ea64.arpa. IN NAPTR 10 10 "E2U+esx" "!^43222(.*)$!enum:+431\1!" . would redirect an ENUM query of +432228765432109 to look at the domain associated with number +4318765432109 for queries that matched the enumservice "esx". (iii) Finally, this is how an "enum:" URI might be used in a "wildcard" Resource Record. Note that the use of DNS wildcards is NOT recommended here; this merely shows how a wildcard MIGHT be used with an "enum:" URI. 2.2.2.3.4.e164.arpa. * IN NAPTR 10 10 "E2U+esx" "!^43222(.*)$!enum:+431\1!" . The intention here would be to redirect queries on any number "under" the area code +43-222 to the area code +43-1, for any ENUM query that matched the enumserevice "esx". This of course assumes that there are NO Resource Records "under" 2.2.2.3.4.e164.arpa. Note that a similar affect might be achieved by the use of a DNAME record. However, in that case the value returned would depend on whether or not the extended DNS option flags were set in the query, and the target suffix used in the DNAME Resource Record would be a "reversed domain". 4. Security Issues Our initial thought is that the "enum:" URI has no more security and privacy implications above any other use of ENUM. Also, it has similar privacy implications to the use of a "tel:" URI. Publication of an "enum:" URI, for example within a Web page, DOES indicate that there is an ENUM entry with this value as a key. This exposes some information, but as this can be found out anyway by the expedient of performing a test ENUM query, it is not seen as being important. 5. IANA Considerations This document specifies a URI scheme. To ensure that this URI scheme value does not collide with other uses, it is necessary to register this token. Thus this requests that this document be considered a specification for the 'enum:' URI scheme, and that a registration be made for this use. 6. Acknowledgments Jon Peterson gave constructive comments on the "enum:" URI. 7. History Version - 0 , issued June 2002 - Initial version. Version - 1 , issued February 2003 - removed reference to ENUM 'es' URI parameter - added recommendation to ignore any included parameters - removed reference to combination of 'es' parameter values with client selection 8. References [1] H. Schulzrinne, A. Vaha-Sipila, "URIs for Telephone Calls", draft-antti-RFC2806bis-07.txt, Work in progress, December 2002 [2] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks, M. Handley, E. Schooler "SIP: session initiation protocol", RFC3261, Internet Engineering task Force, June 2002 [3] P. Faltstrom, M. Mealling, "The E.164 to URI DDDS Application (ENUM)", draft-ietf-enum-rfc2916bis-3.txt, Work in progress, January 2003 [4] M. Mealling, "Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database", RFC3403, Internet Engineering task Force, October 2002 9. Authors' Addresses Rudolf Brandner Siemens ICN Hofmannstrasse 51 Munich Germany Email: Phone: URI: Lawrence Conroy Siemens Roke Manor Research Roke Manor Romsey U.K. Email: Phone: Richard Stastny OeFEG Postbox 147 1103 Vienna, Austria Email: Phone: Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.