ENUM Working Group R.Brandner Internet-Draft Siemens L. Conroy Siemens Expires: September 22, 2002 February 22, 2002 "The ENUM 'tel' enumservice" draft-brandner-enum-tel-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 describes the enumservice 'tel' and how it is used with an ENUM application when indicated within a returned a NAPTR record. It gives guidelines for the treatment of records having this sub-field value, and for the onward processing of information gleaned from the enclosing NAPTR record. Brandner & Conroy Expires August 22, 2002 [Page 1] Internet-Draft The ENUM 'tel' enumservice February 2002 1. 'tel' enumservice registration template As defined in [1], the following is a template covering information needed for the registration of the enumservice specified in this document. Service Name: "tel" URI Scheme(s): "tel:" Functional Specification: see section 3 of this document Security considerations: see section 5 of this document Intended usage: (One of COMMON, LIMITED USE or OBSOLETE) COMMON Author: Rudolf Brandner Any other information that the author deems interesting: see sections 2 and 4 of this document 2. Introduction The ENUM application is defined in [1]. This takes an input E.164 number and returns a URI (or set of URIs) by which communications services associated with that E.164 number[2] can be contacted. This process is called a "resolution service" provided by the client application. The data for this information is stored within the DNS[3][4], inside NAPTR resource records (defined in [5], section 4). The ENUM application specification defines the structure for one of the fields of the NAPTR records it will use; the "Services" field. ENUM expects this field to be structured in two parts, the rs (or resolution service) tag and the enumservice sub-field. This latter can in turn have multiple values, each of which is preceded by a '+' character. The "resolution service" for which a NAPTR record is intended for use is indicated by the record rs sub-field value. In the case of records intended for use with ENUM, this tag value will be "E2U" (meaning that the record is designed for use when taking an E.164 number and results in a URI). Brandner & Conroy Expires August 22, 2002 [Page 2] Internet-Draft The ENUM 'tel' enumservice February 2002 In addition to this tag, each NAPTR record for use by ENUM will include at least one enumservice identifier. Each of the values in this sub-field indicates a treatment that should be made of the returned URI, together with the IP-based protocol that should be used to forward the URI to an entity that can further a request for communication. This document describes one such treatment, that indicated by the 'tel' enumservice sub-field value. 2.1. ENUM enumservice sub-field ENUM is designed to retrieve URIs associated with an E.164 number. Note that each URI will be associated with its own set of enumservice sub-field values. Each value specifies two features; the treatment of the URI and the protocol to be used for onward processing. It is necessary to indicate the intended treatment and protocol to be used, as some user agents are capable of dealing with a number of different URI scheme values, so that the scheme alone cannot necessarily be used to distinguish what should be done with the URI; the URI is merely an identifier. For example, a URI with the scheme "mailto:" [6] implies that an email service can be used to contact the destination. However, it is unclear whether or not that user should be contacted using "basic" SMTP [7], or instead requires a secure connection to be made (using TLS, over which the SMTP protocol is carried, according to [8]). This might be indicated by a distinct enumservice sub-field value (say "smtp" or "smtps"), indicating the intended treatment and protocol to be used for the URI. In principle, these are NOT the same; the treatment is distinct from the protocol used to forward the URI to an entity that can further the communications processing, and, as just suggested, these may both differ from the URI scheme. However, for current uses, a single enumservice sub-field value, in conjunction with the URI scheme, will suffice. 3. 'tel' sub-field definition When used with an ENUM application, a NAPTR record including the indicator 'tel' in the enumservice sub-field implies that the URI can be treated as formatted according to [9], and includes a telephone number. This implies that the communications service described by this record will require a telephone connection to be made. Brandner & Conroy Expires August 22, 2002 [Page 3] Internet-Draft The ENUM 'tel' enumservice February 2002 This sub-field value differs from others that can be used with ENUM in that it does not specify the protocol to be used for onward processing, only the treatment of the URI with which it is associated. For example, it is a valid response to apply the associated URI to a remote SIP User Agent (and so to use SIP as the protocol by which the communication session is initiated). That external user agent would use this "tel:" URI to initiate a call (via a PSTN/IP Gateway as required). When a 'tel' enumservice sub-field value is present, the interpretation of the URI that results from processing with the enclosing NAPTR record is that it is a telephone number. This means that the URI MUST have a scheme of "tel:", or the client will treat the NAPTR as being in error. In such an error situation, the client SHOULD report this error and MUST NOT attempt to infer the treatment from the URI scheme. The client MAY use the email contact address held in the SOA record for the current DNS zone to report the mis-configuration of the NAPTR. By implication, there SHOULD be a SOA record with a valid email contact address available within the DNS zone holding NAPTR records. 4. Recommendations on the use of 'tel' NAPTR records The 'tel: URL scheme (RFC2806 [8]) allows considerable flexibility. Where a URI is to hold a telephone number and is to be used by ENUM, however, there are some issues that should be considered. These are recommendations on the information to be encoded into NAPTR records that hold the 'tel' enumservice sub-field. If these recommendations are not followed, the results when such NAPTRs are processed by an ENUM client may not be acceptable. 4.1. Locality of caller ENUM is designed to allow information to be returned to clients regardless of their location. Thus, although RFC2806 allows for both "internationally significant" global-phone-subscriber or local-phone-subscriber formats for telephone numbers, the person authoritative for the content of a NAPTR record has no way of knowing the locality of the person who subsequently will request information associated with this data. It is therefore important that only the global-phone-subscriber form SHOULD be used. In those cases where a local-phone-subscriber form cannot be avoided, then there MUST be a global-area-specifier parameter included within the URI. This differs from RFC2806, in which this is of SHOULD strength. Brandner & Conroy Expires August 22, 2002 [Page 4] Internet-Draft The ENUM 'tel' enumservice February 2002 Thus these are acceptable forms: -- global phone subscriber form -- local phone subscriber form whilst the following is not acceptable: 4.2. Use of Telephone Service Provider parameter It is recommended that, where a NAPTR output is to be treated according to this document, the Telephone Service Provider (TSP) parameter SHOULD be included within the tel: URI. This parameter indicates the telephone service provider that is associated with the telephone number. This parameter is specified as including a value that is a fully qualified domain name. There are several reasons for doing this. It allows a "hint" at the organization responsible for providing telephone service to that destination user. This information might be used by the caller, for example, to select an appropriate PSTN/IP Gateway, if needed and the caller has no preference. Note that this service provider information is distinct from the identity of the administrative or technical contacts for the zone or its parent. This parameter may also be useful if, for example, there is a problem with calling that user, or there is reason to believe that problem calls are made from a phone number that (when passed to ENUM) has returned this URI. In these last two cases, the tsp domain name could either be used by the calling user to guess at the web server for that provider, or instead the web site could be found by submitting the domain name to DNS (using a SRV query). Having found this, the web site could be used to get contact information for that provider. As an alternative use of the tsp parameter domain name value, the DNS zone indicated by this tsp domain might have communications contact information (using an application similar to ENUM, but operating with records not in the ".e164.arpa." domain). As an aside, it would also be possible to include another NAPTR record inside that domain with a tel: URI holding the "prefix dial string" for use with this provider. Again, these would be returned by a query NOT in the "e164.arpa" domain space, and so would not use the ENUM application. Brandner & Conroy Expires August 22, 2002 [Page 5] Internet-Draft The ENUM 'tel' enumservice February 2002 4.3. Use of "tel:" URIs within ENUM for Redirection Teleservices Having received a tel: URI as the result of an ENUM query it is possible for a client node to re-submit the resulting telephone number (held inside the tel: URI) back into ENUM as a new query. This might be considered, for example, to deal with telephone service redirection. Configuring a set of tel: URIs in different zones, the contents of each of which "points" to others in the set, could be used to support a range of "follow-me" services. It is a very powerful feature, and reflects a number of "real-world" PSTN services. However, this feature does not come without risk. That risk is looping. 4.3.1. Looping of ENUM queries If re-submitting a tel: URI content to ENUM, mis-configuration of the NAPTR contents may cause a loop, in which the re-submission results in the same tel: URI, that is re-submitted, and so on. Likewise, a loop may exist with more than one domain involved. For example, an ENUM query with telephone number aa retrieves a NAPTR from domain A resulting in a tel: URI with telephone number bb; if this is resubmitted to ENUM, domain B (associated with this number) has a NAPTR that results in a tel: URI holding telephone number aa. If this is re-submitted, then the process repeats. This condition is an error, and the client that calls the ENUM application SHOULD report this to the end user and terminate the re-submission. The condition may have been caused by the remote administrator's mistake, but it is the client's problem; the ENUM application cannot detect the problem, as from its perspective each query returns correctly. For this reason, the client of an ENUM application should take extra care when re-submitting the telephone number contained in a tel: URI back into the ENUM application. It is exclusively the responsibility of the client of the ENUM application to keep track of prior queries and detect this condition. Any client behavior in the face of this problem is possible. However, it is recommended that: (i) the client does not re-submit a query to the ENUM application if it detects a loop. (ii) the client keeps track of the number of requests it has made in attempting to find information on an initial E.164 number; if this count exceeds a "reasonable maximum" value of 10 attempts, then it SHOULD treat the request chain as a loop. Brandner & Conroy Expires August 22, 2002 [Page 6] Internet-Draft The ENUM 'tel' enumservice February 2002 (iii) if it has good reason to do so, the client MAY treat the most recent distinct telephone number retrieved in the sequence as the one to be used to place a call. However, a loop condition IS an error, and so this behavior is not recommended. Instead, clients SHOULD be expected to abort the procedure that started the chain of requests and report the error to the end user, where possible. 4.3.2. Alternatives to tel: URI chains for Redirection Teleservices ENUM (and the tel enumservice), use DNS. As a result, all DNS facilities are available. This includes the use of CNAME resource records within a zone. It is possible to install a CNAME record in the parent of the zone associated with a particular E.164 number. If that CNAME points at another zone within the ".e164.arpa." domain, then the effect is to continue the DNS lookup chain at that point in the domain space. This is similar in effect; a redirection can be arranged by inserting a CNAME record into a parent zone. The effect is not quite the same as provision of a chain of "tel:" URIs. In the CNAME case, the process is transparent to the ENUM client; the lookup is merely continued at a different point in the DNS tree. It is less flexible, in that it precludes other records being stored within the zone associated with the donor number; the whole zone is bypassed. In contrast, a chain of tel: URIs still allows other records, and so allows a rich set of teleservices to be provisioned. Both configurations suffer from similar risks of looping, but in the case of CNAME loops these are either within the ENUM application or the DNS recursive resolver it uses. Despite its lack of flexibility, CNAME redirection can provide a simple method that may be appropriate for longer term fixed forwarding for administrators with the right to modify resource records within the parent of a zone associated with a number. Another issue with CNAME redirection is that it places some restrictions on the REGEXP content. At present, DDDS allows a regular expression to match against the AUS, and if there is no match then the record is discarded. Where a query is made on a zone associated with a phone number then NAPTR records within that zone could have RegExp fields that pattern matched against the whole number. Thus, if the number in its AUS format were "+441794833666", then a query on the zone "6.6.6.3.3.8.4.9.7.1.4.4.e164.arpa." might return a NAPTR with a RegExp field of "!^(441794833666)$!\+\1!". This would match perfectly, and processing would continue. Brandner & Conroy Expires August 22, 2002 [Page 7] Internet-Draft The ENUM 'tel' enumservice February 2002 If, however, the query had been made starting with a phone number, in its AUS format, of "+494012345678", AND a CNAME record points from 8.7.6.5.4.3.2.1.0.4.9.4.e164.arpa. to 6.6.6.3.3.8.4.9.7.1.4.4.e164.arpa., then the same NAPTR returned from the query would NOT match with the AUS. This means that administrators of ENUM zones should be careful about specifying the RegExp match rules too tightly. There are reasons to do this, however. For example, two NAPTR records might exist in the destination zone, with different priority. The record with the higher priority might match against an AUS holding any fully qualified phone number, whilst that with the lower priority might have a tight match against the phone number associated directly with that zone. The result would be that two different NAPTRs would match, depending on whether or not that phone number was the subject of the query, or instead the redirected, or donor, number. This would allow different treatment of requests, depending on which number was queried. This is not specific to 'tel' enumservice, but it does show the flexibility possible. 5. Security Considerations [Including but not limited to...] Any system that places calls should not automatically dial out to a number included in ENUM. The calling user should be given a chance to express policy. For example, a NAPTR output treated as a 'tel' value may result in a call being placed to a long distance, international, or premium rate number. Any dialer system that is passed the telephone number and uses it to dial out should be act carefully; accidental or malicious mis-configuration of a NAPTR record may result in calls being placed either to an innocent third party or to an otherwise inappropriate destination. Any system that places a call automatically (i.e. without the end user actually dialing the number themselves) runs the risk of those calls being incorrect. The end user should be involved in the call process, if only so that they can veto a call dialed to a "wrong" number or at the "wrong" time. This is particularly important if the ENUM infrastructure is ever used to allow "follow-me" service listing, possibly based on automatic "time of day" changes. [Ask any European whether or not they have received a call whilst in the US that was placed during European work hours] Brandner & Conroy Expires August 22, 2002 [Page 8] Internet-Draft The ENUM 'tel' enumservice February 2002 There might be an issue with Telephone Service Provider (TSP) privacy. If the ";tsp=" parameter (RFC 2806) is used in a tel: URI resulting from an ENUM query, an exhaustive lookup of ENUM will reveal data about how many ENUM users a TSP has. It is yet unclear how to distinguish between "normal" ENUM request behavior and an exhaustive lookup and how to prevent an exhaustive lookup. Particularly for a "niche" TSP providing services to a particular group, information on the user may be revealed by presence of the TSP field in a "tel:" URI. 6. IANA Considerations This document specifies the enumservice 'tel', i.e. the treatment of a URI within a NAPTR record that is intended for use by the ENUM application, when that NAPTR record includes the 'tel' enumservice sub-field value. To ensure that this sub-field value does not collide with other uses, it is necessary to register this NAPTR sub-field value, when used within ENUM. Thus this requests that this document be considered a specification for the sub-field value with the identifier 'tel', and that a registration be made for this within the ENUM enumservice name space, as specified in [1]. 7. Acknowledgements Brandner & Conroy Expires August 22, 2002 [Page 9] Internet-Draft The ENUM 'tel' enumservice February 2002 8. References [1] P. Faltstrom, "The E.164 to URI DDDS Application", draft-ietf-enum-rfc2916bis-01.txt, Work In Progress, March 2002 [2] ITU-T Recommendation E.164/I.331 (05/97): The International Public Telecommunication Numbering Plan. 1997. [3] Mockapetris, P., "Domain names - implementation and specification", RFC 1035, STD 13, Nov 1987. [4] Mockapetris, P., "Domain names - concepts and facilities", RFC 1034, STD 13, Nov 1987. [5] M.Mealling, "Dynamic Delegation Discovery System (DDDS) Part Three: The DNS Database" draft-ietf-urn-dns-ddds-database-08.txt, Work In Progress, February 2002 [6] Hoffman, et. al., "The mailto URL scheme", RFC2368, July 1998 [7] Klensin, J., "Simple Mail Transfer Protocol", RFC821, August 1982 [8] Hoffman, P., "SMTP Service Extension for Secure SMTP over TLS", RFC2847, January 1999 [9] Vaha-Sipila, A., "URLs for Telephone Calls", RFC2806, April 2000 Brandner & Conroy Expires August 22, 2002 [Page 10] Internet-Draft The ENUM 'tel' enumservice February 2002 9. Authors' Addresses Rudolf Brandner Siemens ICN Hofmannstrasse 51 Munich Germany Email: rudolf.brandner@icn.siemens.de URI: http://www.siemens.de Lawrence Conroy Siemens Roke Manor Research Roke Manor Romsey U.K. email: lwc@roke.co.uk 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. Brandner & Conroy Expires August 22, 2002 [Page 11]