ENUM Working Group R.Brandner Internet-Draft Siemens L. Conroy Siemens R. Stastny OeFEG Expires: December, 2002 June 14th, 2002 'The "enum:" URI scheme' draft-brandner-enum-uri-00.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 September 22, 2002. 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 can be returned by evaluating the URI value using the ENUM DDDS application. It also includes a definition of an optional URI parameter to indicate a list of enumservices that should be considered in the returned response to the ENUM query. Syntactically, it uses a subset of the format defined for the "tel:" URI scheme. Brandner, Conroy, Stastny Expires December, 2002 [Page 1] Internet-Draft The "enum:" URI scheme June 2002 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 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 is very similar in action to the "tel:" URI, but with which a compliant client should generate a query on the ENUM system. That is the role for the "enum:" URI scheme, as specified in this document. The syntax for this URI-scheme is covered in the next section. The subsequent section covers the expected client behaviour and meaning of the parameter that may be used with this URI scheme, 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. One optional parameter is defined for use with this URI-scheme. This is the 'es=' parameter, holding a comma-separated list of enumservice values. This fits within the generalised param syntax defined in RFC2806bis. enum-uri = enum-uritoken enumref [esparam] enum-uritoken = "enum:" enumref = global-number-part (global-number-part as defined in RFC2806bis) esparam = ";" espname "=" espvalue espname = "es" espvalue = enumservice [ *("," enumservice) ] (enumservice as defined in RFC2916bis) 3. Expected Client Behaviour 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. The essential difference between the "enum:" URI scheme and the "tel:" URI scheme is that in case of the "enum:" URI scheme 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 - so its behaviour in this case is undefined.' Brandner, Conroy, Stastny Expires December, 2002 [Page 2] Internet-Draft The "enum:" URI scheme June 2002 3.1. The 'es' parameter Note that the 'es' parameter is specified for use with this scheme. This parameter includes a list of enumservice values, as specified according to section 2.4.2.1 of RFC2916bis [3]. If present, the list of enumservices in the 'es' parameter should be used as a filter, indicating the enumservices that should be matched in any returned NAPTR resource records. Conversely, lack of this parameter should be taken to imply that all enumservices are of interest and should be considered when deciding on the appropriate communications contact. 3.2. "enum:" URI usage within ENUM domain space This section covers the specific case where an "enum:" URI is present within the ENUM domain space, and the interactions with the ENUM client application this involves. Two aspects are important here; an ENUM client MUST NOT re-submit a query to the ENUM system if it receives a "tel:" URI in response to its current query. Secondly, if the optional 'es' parameter is included, then the enumservices this parameter holds should be combined with those that the querying ENUM application is already considering. It SHOULD NOT simply replace this original set of "enumservices of interest". 3.2.1. "enum:" URI - comparisons with uses of other approaches The difference between "tel:" or "enum:" URIs that are generated as the result of ENUM processing is that the "enum:" URI will trigger a re-submission of a query to the ENUM system using the enclosed global-number-part (and any 'es' parameter value set), whilst a client SHOULD NOT re-submit the contents of a "tel:" URI to the ENUM infrastructure. 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 only for an individual NAPTR that meets the matching criteria rather than for all queries. 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. 3.2.2. enumservice filtering Where a NAPTR generating an "enum:" URI specifies an enumservice set (in the service field of the NAPTR), this NAPTR may have been selected because one of the enumservices specified matched against one being sought by the application requesting the ENUM lookup. However, if the "enum:" URI generated from this NAPTR includes the "es" parameter, AND the enumservice listed in that do not match against the initial enumservices of interest, then the URI SHOULD be discarded; it does not meet the requirements of the querying application. Brandner, Conroy, Stastny Expires December, 2002 [Page 3] Internet-Draft The "enum:" URI scheme June 2002 The application has its own interests. Thus, if there is an 'es' parameter in an "enum:" URI generated as the result of an ENUM query, then the intersection of the application's original "enumservices of interest" and the enumservices listed in the "enum:" URI SHOULD be used in the re-submitted ENUM query using this URI value. If the URI has no 'es' parameter included, the original "enumservices of interest" set is retained for the subsequent query. In both cases, any 'es' parameter value is combined with the querying application's "enumservices of interest" set to winnow the list to the intersection of the two sets. If this results in the empty set, then this URI is to be discarded. Otherwise, the intersection should be used for subsequent ENUM queries. 4. Security Issues Our initial thought is that the "enum:" URI has no more security and privacy implications above any other use of ENUM. 5. IANA Considerations This document specifies a URI scheme, together with an optional parameter. 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 for the associated URI parameter 'es', and that a registration be made for this use. 6. Acknowledgments Members of the IETF ENUM working group have helped in the development of this document with their comments on the earlier 'tel' enumservice draft. 7. References [1] H. Schulzrinne, A. Vaha-Sipila, "URIs for Telephone Calls", draft-antti-RFC2806bis-04.txt, Work in progress, May 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, "ENUM", draft-ietf-enum-rfc2916bis-0.txt, Work In Progress, February 2002 Brandner, Conroy, Stastny Expires December, 2002 [Page 4] Internet-Draft The "enum:" URI scheme June 2002 8. 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: Brandner, Conroy, Stastny Expires December, 2002 [Page 5] Internet-Draft The "enum:" URI scheme June 2002 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. Brandner, Conroy, Stastny Expires December, 2002 [Page 6]