SIPPING Working Group J. Peterson Internet-Draft H. Liu Expires: August 9, 2002 J. Yu NeuStar B. Campbell dynamicsoft February 8, 2002 Using ENUM for SIP Applications draft-ietf-sipping-e164-01 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 9, 2002. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract Although SIP was clearly one of the primary applications for which ENUM was created, there is nevertheless widespread uncertainty about the demarcation of SIP location services from ENUM. This document attempts to sharpen the distinction between location services provided by the two protocols, illustrating how the two protocols might work in concert and clarifying the authoring and processing of ENUM records for SIP applications. Peterson, et al. Expires August 9, 2002 [Page 1] Internet-Draft Using ENUM for SIP Applications February 2002 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. ENUM: Resources and Protocols . . . . . . . . . . . . . . . 5 2.1 Telephone Numbers & the Internet . . . . . . . . . . . . . . 5 2.2 The Space of ENUM . . . . . . . . . . . . . . . . . . . . . 6 3. SIP and ENUM . . . . . . . . . . . . . . . . . . . . . . . . 8 3.1 Overview of SIP Capabilities . . . . . . . . . . . . . . . . 8 3.2 E.164 Numbers in SIP Requests . . . . . . . . . . . . . . . 9 3.3 Addresses-of-record in SIP . . . . . . . . . . . . . . . . . 10 3.4 ENUM and SIP Location Services . . . . . . . . . . . . . . . 11 3.5 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . 14 4. Authoring NAPTR records for SIP . . . . . . . . . . . . . . 16 4.1 The Service Field . . . . . . . . . . . . . . . . . . . . . 16 4.2 Flags in NAPTR RR . . . . . . . . . . . . . . . . . . . . . 17 4.3 Creating the Regular Expression: Matching . . . . . . . . . 17 4.3.1 Creating the Regular Expression: The URI . . . . . . . . . . 17 4.4 Provisioning multiple NAPTR records . . . . . . . . . . . . 18 4.4.1 tel URL v. SIP URI . . . . . . . . . . . . . . . . . . . . . 19 4.4.2 Composing SIP services with ENUM . . . . . . . . . . . . . . 20 4.5 Setting Order and Preference amongst Records . . . . . . . . 21 4.6 Example of a Well-Formed ENUM NAPTR Record Set . . . . . . . 22 5. Processing ENUM records . . . . . . . . . . . . . . . . . . 23 5.1 Selecting a number for a query . . . . . . . . . . . . . . . 23 5.2 Examining Service fields . . . . . . . . . . . . . . . . . . 23 5.3 Handling Order and Preference . . . . . . . . . . . . . . . 24 5.4 Contending with multiple SIP records . . . . . . . . . . . . 25 5.5 Processing NATPR records in a client . . . . . . . . . . . . 25 6. Limits of ENUM . . . . . . . . . . . . . . . . . . . . . . . 27 7. Security Considerations . . . . . . . . . . . . . . . . . . 29 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 30 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 32 A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 33 References . . . . . . . . . . . . . . . . . . . . . . . . . 31 B. To Do . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 Full Copyright Statement . . . . . . . . . . . . . . . . . . 35 Peterson, et al. Expires August 9, 2002 [Page 2] Internet-Draft Using ENUM for SIP Applications February 2002 1. Introduction ENUM (E.164 Number Mapping, RFC2916 [1]) is a system that uses DNS (Domain Name Service, RFC1034 [2]) in order to translate certain telephone numbers, like '+12025332600', into URIs (Uniform Resource Identifiers, RFC2396 [3]), like 'sip:user@sipcarrier.com'. ENUM exists primarily to facilitate the interconnection of systems that rely on telephone numbers with those that use URIs to route transactions. SIP (Session Initiation Protocol, RFC2543 [4]) is a text-based application protocol that allows two endpoints in the Internet to discover one another in order to exchange context information about a session they would like to share. Common applications for SIP include Internet telephony, instant messaging, video, Internet gaming and other forms of real-time communications. SIP is a multi-service protocol capable of initiating sessions involving different forms of real-time communications simultaneously. The creators of ENUM quickly recognized its relevance to SIP. SIP is frequently used in telephony applications in which calls originate within the PSTN (Public Switched Telephone Network), traverse a PSTN- SIP gateway and terminate on an SIP endpoint; in these scenarios, the utility of deriving a SIP URI from a telephone number is pretty obvious. But moreover the telephone number will undoubtedly continue to enjoy widespread use for many years to come - even some native SIP phones have user interfaces that are essentially traditional DTMF number pads. Despite the fact that ENUM and SIP provide very different services there is a small amount of overlap in their capabilities. For example, SIP can use telephone numbers within URIs instead of addresses in the 'user@domain' form. Also, SIP supports entities called 'location services' that facilitate routing based on URIs. Unfortunately, this overlap has lead to some confusion about how the two protocols should be used in tandem - some parties have attempted to implement what amounts to SIP location services in ENUM, while others have maintained that ENUM provides merely a subset of SIP's capabilities and is therefore unnecessary for SIP architectures. This uncertainty is deepened by ambiguities in the ENUM standard that must be resolved before the structure of records and the logic for processing records can be well understood. This document aspires to demarcate the roles of SIP and ENUM by proposing an architecture in which the two systems can profitably interact. Guidelines are proposed for the authoring of the DNS records used by ENUM, and for client-side processing once these DNS records have been received. Peterson, et al. Expires August 9, 2002 [Page 3] Internet-Draft Using ENUM for SIP Applications February 2002 The remainder of this document is organized as follows: sections 2 and 3 provide an informative high-level overview of ENUM and SIP and discuss their relationship, proposed normative guidelines for ENUM record authoring and processing in the context of SIP are described in Sections 4 and 5 respectively, and limitations of ENUM are discussed in Section 6. Peterson, et al. Expires August 9, 2002 [Page 4] Internet-Draft Using ENUM for SIP Applications February 2002 2. ENUM: Resources and Protocols ENUM is a mechanism for grouping URIs associated with particular protocols under a common identity, namely an E.164 [5] number. An E.164 number is a globally-unique, language-independent identifier for a logical resource in the telephone network. E.164 itself is an standard for the assignment of telephone numbers within an international, ubiquitously-reachable framework. 2.1 Telephone Numbers & the Internet Historically, telephone numbers corresponded directly to physical resources in the network; the digits of a number literally corresponded to physical coordinates on a switching plane. Over time, telephone numbers began to identify logical rather than physical resources. For example, in order to terminate a call to a freephone (in the USA, 1-800) number, the network must translate the freephone number into a regular number, and this translation may depend on time of day or the location of the caller. Today we take it for granted that a wireless phone number inevitably identifies both the wireless device carried by the user and a voicemail terminal, elsewhere in the network, that is contacted when the user is unavailable. The introduction of follow-me services allows a call to a single number to attempt connections to multiple terminals - in the office, the home, or the car, then maybe a pager - in order to reach a particular person who moves between these devices. Users of the telephone network are therefore accustomed to the idea that many logical destinations may be grouped under an E.164 number. However, in order to invoke, or even learn about, any of the PSTN resources under an E.164 number, the originating user must attempt to place a call. An E.164 number is a relatively opaque identifier - staring at a telephone number one might be able to get a rough sense of the geographic location of its (home) network, or the comparative expense of placing a call to it, but nothing about the resources that will be reached is obvious from the identifier itself (excepting perhaps 1-800-FLOWERS and its ilk). Once you launch a call you may hear a live human, a fax, an voice browser, or a message that the number has been disconnected. The Internet adopts, in quite a few respects, a very different attitude towards reaching resources. Internet endpoints controlled by end users may be general purpose computers with sophisticated user interfaces that explicitly establish network connections with resources selected by the end user. Endpoints listen on standardized ports for requests associated with application capabilities. These ports can each accommodate a specific service associated with a particular protocol. Protocols tend to be customized to a specific Peterson, et al. Expires August 9, 2002 [Page 5] Internet-Draft Using ENUM for SIP Applications February 2002 capability of the endpoint; one protocol is optimized for carrying mail traffic, another for carrying Internet game traffic. One common way of identifying a resource in the Internet is a URI, and by inspecting a URI one can commonly ascertain its purpose and even the logical domain in which the resource exists; for example, 'mailto:jon.peterson@neustar.biz'. By way of contrast, a PSTN user's endpoint (the venerable 'black phone') has one real capability - rendering audio media. Similarly, end users have only one 'protocol' for interacting with the PSTN - picking up the phone and placing a call. Any and all services in the PSTN are reachable through this lone 'protocol'. But in the Internet model, you must choose one of many protocols before you attempt to create a network connection, and the choice of protocol usually limits the sorts of services that might be reached. 2.2 The Space of ENUM ENUM is the intersection of the PSTN convention for naming resources with the Internet model of protocols. ENUM allows an endpoint to inspect the Internet protocols that are associated with an E.164 number before attempting to initiate any communication. Among other things, this allows endpoints to choose appropriate protocols to communicate with resources grouped under an E.164 number. Once a protocol has been selected for communication, endpoints derive from ENUM records a URI that designates the resource with which a network connection should be established. ENUM is both a technology and a policy. From its inception, it has aspired to be a tool for namespace management for the national numbering administrations participating in the international E.164 system. ENUM mandates that only one record set should correspond to each E.164 number, and that these records should be delegated from a single 'golden root' (known as 'e164.arpa'). Much of the utility of ENUM derives from the fact that there is only a single logical place in the Internet where clients need to look for information about a given E.164 number, and that this place provides an authoritative record set that is sanctioned by the national numbering plan administrator for that number. With this utility comes a limitation - clients that perform ENUM queries must know how to render a telephone number in international form (e.g. if a user in the Washington D.C. dials '5332600', a client processing this number must transform it into '+12025332600' before launching an ENUM query). Also, ENUM cannot operate on private dialing plans or other numbering systems outside the scope of the E.164 plan. Although ENUM guarantees that responsibility for the record set corresponding to a given telephone number descends from policies of Peterson, et al. Expires August 9, 2002 [Page 6] Internet-Draft Using ENUM for SIP Applications February 2002 the national numbering authorities, this makes no assumption about who authors ENUM records, or how they happen to be provisioned. Governments, carriers, corporations or users could all possibly be authors of ENUM record sets, subject to local regulatory and market forces; note that this document has no dependency on which parties happen to control the population of ENUM records. Similarly, ENUM makes no assumptions about who consumes ENUM records (between, say, carriers and end users) - all parties that can use ENUM will have access to the same records since there is only one ENUM record set per E.164 number. Finally, although ENUM records offer a set of protocols that can be used to reach services, protocols and services in the Internet are not the same thing. Admittedly, some protocols are very specific tools that are invariably used for a single service; for example, an FTP URL found in an ENUM record set isn't likely to be useful for anything other than file transfer. However, some protocols (like DNS itself) play a support role, assisting in the invocation of other protocols. SIP falls into this same category in so far as it is ultimately a facilitator for other protocols - SIP signaling is used to establish a session that in turn carries the real data that end users would like to exchange. As such, a SIP URI could be used to invoke any of the sorts of sessions that SIP can administer, and therefore the 'sip' URI scheme, although it designates a protocol, cannot be said to represent any particular type of service or resource. Peterson, et al. Expires August 9, 2002 [Page 7] Internet-Draft Using ENUM for SIP Applications February 2002 3. SIP and ENUM 3.1 Overview of SIP Capabilities SIP is not a protocol that offers a direct service to end users, like access to file transfer or exchange of hypertext documents. Rather, SIP helps you to find the best way to communicate with a remote resource. It employs a number of mechanisms, including registration of the location of endpoints, discovery of endpoints by routing requests through proxy servers, and various forms of capability negotiation, to allow a set of endpoints to establish an optimal communication path. Typically, a SIP user agent forms a SIP request for a particular destination URI that advertises its own capabilities and preferences, and then hands this request over to a proxy server for delivery. In some respects this is reminiscent of the PSTN user who picks up the phone and dials without knowing what sort of resource will be reached. However, SIP represents a substantial improvement over that model. First of all, SIP has an innate mechanism for discovering the right device to field a call for a particular user's identity. A SIP device can register dynamically (through the use of the REGISTER request) at the administrative domain of the user's identity when the user becomes available through the device, and de-register when the user has departed. Proxy servers take into account the set of registered devices when determining how to route a request. A SIP- based follow-me service, for example, would rely on this real-time availability data in order to find immediately the best place to reach the end user - without having to cycle through numerous devices from which the user is not currently registered. Secondly, SIP has a process for negotiating the sorts of sessions its users would like to share. Like email messages, SIP requests consist of headers followed by one or more bodies. A common type of body contained in a SIP request is SDP (Session Description Protocol, RFC2327 [10]), which is used to advertise various potential connections that could be used to send real-time session data. When creating a request for a session, SIP endpoints frequently offer as many types of communication in the SDP as possible in order to find common ground with the remote resource; one SDP could contain, for example, offers for voice, video and instant messaging channels simultaneously. The remote resource, when it receives the request, may accept some or all of these channels as appropriate. Several logical roles are defined for SIP network entities. The most significant are those of user agents, which may act for a particular Peterson, et al. Expires August 9, 2002 [Page 8] Internet-Draft Using ENUM for SIP Applications February 2002 transaction as either a client or server, and those of proxy servers, which forwards SIP requests between user agents or one another. Another significant role is the redirect server, which receives a request from a user agent and responds with a redirection message that prompts the user agent to send the same request to a different destination. Note that a common SIP phone and a PSTN-SIP gateway both act as SIP user agents. Any SIP entity could potentially launch an ENUM query when it needs to operate on an E.164 number. Whether or not it does so is largely a matter of its capabilities and its local policies; SIP has no built-in way to route calls based on E.164 numbers, and ENUM certainly offers one such mechanism. Note that if ENUM is implemented in a proxy server, it may change the destination of a SIP session in a manner of which the client would like to be informed; for example, from a local SIP telephony call to an international call. ENUM is probably best employed by a user agent prior to the creation of a request, rather than by proxy servers; this also simplifies routing and provides the end user with the most flexibility (especially when their endpoint supports multiple communications protocols). Also note that when ENUM is invoked by an intermediary in the network, the selection of a protocol must be made by the intermediary in ignorance of the client's protocol capabilities; most likely, a SIP proxy server would be able to deduce only that the originating user supported SIP. 3.2 E.164 Numbers in SIP Requests There are a number of reasons why a user might want to initiate a SIP request that targets an E.164 number. One common reason is that the user is calling from the PSTN through a PSTN-SIP gateway; such gateways usually map routing information from the PSTN directly on to SIP signaling. Or a native SIP user might intentionally initiate a session addressed to an E.164 number - perhaps because the target user is canonically known by that number, or the originator's SIP user agent only supports a traditional numeric telephone keypad. A request initially targeting a conventional SIP URI might also be redirected to an E.164 number. In all of these cases a user agent could use ENUM to discover a SIP URI associated with the E.164 number. But what would the user agent do otherwise? If a user agent is unable to translate an E.164 number, it can create a type of SIP Request-URI that contains a telephone number. Since one of the most common applications of SIP is telephony, a great deal of attention has already been devoted to the representation of telephone numbers in SIP. In particular, the tel URL RFC2806 [6] has been identified as a way of carrying telephone routing information within SIP. A tel URL usually consists of the number in E.164 format Peterson, et al. Expires August 9, 2002 [Page 9] Internet-Draft Using ENUM for SIP Applications February 2002 preceded by a plus sign, e.g: tel:+12025332600. This format is so useful that it has been incorporated into the baseline SIP specification; the user portion of a SIP URI contain a tel URL (without the scheme string, like sip:+12025332600@carrier.com). A SIP proxy server might therefore receive a request from a user agent with a tel URL in the Request-URI; one way in which the proxy server could handle this sort of request is by launching an ENUM query itself and proxying the SIP request in accordance with the returned ENUM records. Why is a URI so much easier to route than an E.164 number? The 'user@domain' composition of a SIP URI suggests how routing should occur - go to 'domain' and inquire about 'user'. A tel URL, however, contains no contextual data of this nature. All number blocks (like '+1202533') may very well belong to some specific service provider, but the blocks themselves give no indication of who that carrier might be. Even when a tel URL appears within a SIP URI, as in 'sip:+12025332600@sipcarrier.com', this does not necessarily mean that sipcarrier.com owns the corresponding number block - it merely means that one should go to sipcarrier.com, which will presumably attempt to route the call from there. One of the most important uses of ENUM is that it provides valuable context information about a telephone number - specifically, the means of contacting the administrative domain that is responsible for the number. When the reverse resolution string is created for an E.164 number and the request is resolved within the e164.arpa hierarchy, the request will automatically be delegated to the nameserver that hosts the record for the number in question. Note that this context is provided, however, only for E.164 numbers; since tel URLs can also carry non-geographic numbers, services codes (like x11 in the United States), and numbers in private dialing plans, these URLs retain some utility outside ENUM's scope. In the absence of a mechanism like ENUM, or if ENUM requests return no records, local policy can be used to determine how to forward requests for E.164 numbers. These sorts of policies are frequently used to route calls to gateways that interconnect SIP networks with the PSTN. 3.3 Addresses-of-record in SIP When a SIP device (specifically a user agent) sends a registration to a registrar on behalf of its user, the device associates its contact address with the user's address-of-record. An address-of-record is a SIP URI that serves as a permanent identity for a user, for example, 'sip:user@sipcarrier.com'. Upon receiving the registration request, the registrar will in turn modify the provisioning data in a location Peterson, et al. Expires August 9, 2002 [Page 10] Internet-Draft Using ENUM for SIP Applications February 2002 service, creating a mapping between the address-of-record for the user and the device where the user can currently be reached. When future requests arrive at the administrative domain of this location service for the user in question, proxy servers ask the location service where to find the user. The difference between a contact address and an address-of-record is like the difference between a device and its user. A contact address is associated with a particular device, and may have a very device- specific form (like sip:10.0.0.1). An address-of-record, however, represents a permanent identity of the user, and it should not have a dependency on any device; it can move between devices or even be associated with multiple devices at one time. A simple URI, generally of the form 'sip:user@domain' should be used for an address-of-record. When a SIP request is created in a user agent, it usually contains the address-of-record of its destination in its To header field and Request-URI. Ideally, an address-of-record should be used to populate the URI field of ENUM records for SIP applications. When a SIP entity (be it a user agent or proxy server) needs to make a forwarding decision for a Request-URI containing an address-of- record, it uses the mechanisms described in the SIP specification (RFC2543). Basically, it resolves the domain portion of the URI (sipcarrier.com in the example above) in order to route the call to a proxy server that is responsible for that domain. 3.4 ENUM and SIP Location Services Readers familiar with SIP are no doubt already aware that there is a concept in SIP of a directory that can group multiple URIs under a single identity - the location service. At first glance, it might not be clear what the differences are between a specific application of the location service concept and ENUM. For example, one could imagine a location service in which the keys are 'tel' URLs (like 'tel:+12025332600') and the values are SIP URIs in address-of-record form (like 'sip:jon.peterson@neustar.biz') alongside any other URIs for distinct protocols desired by the user. If this location service were consulted by a redirect server, then it could be queried in a fashion similar to ENUM. Superficially, the two might seem like they provided the same capabilities. For example, both query mechanisms can express relative preference within a record set (NAPTR records support a preference field, while contact addresses in a SIP redirect message contain 'q' values that suggest a preferred order). However, there are a number of important respects in which the two differ. Note Peterson, et al. Expires August 9, 2002 [Page 11] Internet-Draft Using ENUM for SIP Applications February 2002 that this section makes no judgment about the superiority of either approach, but it is intended that these distinctions will clarify the applicability of these mechanisms to potential deployments. Request vs. Query: Some sort of SIP request must be sent in order to query a redirect server - generally it is only in the process of attempting to initiate a session that a SIP client can access a location service. An ENUM request can be sent independently of any attempt to initiate a session. This can be a meaningful difference when the location service would return URI schemes indicating a protocol other than SIP. If a client wants to learn, say, the 'mailto' URI associated with a telephone number, it might not be desirable to have to attempt to initiate a SIP session in order to discover it. Authentication: A redirect server can challenge a SIP client to provide authentication before processing a query. ENUM, like all DNS systems, returns the same records regardless of the identity of its client, and therefore has no means nor need for authentication. Significantly, a redirect server can therefore make policy decisions about the records it returns based on the authenticated identity of the client, whereas ENUM cannot. Registration: SIP supports dynamic registrations of contact addresses in a location service; in addition to supporting an interface to query a location service, SIP also supports an interface to provision a location service in real-time, including ways to expire and refresh registrations as appropriate, authenticate registrations, and so forth. ENUM describes only a query system - how ENUM record sets are uploaded to DNS servers is not in the scope of DNS. Generally, however, DNS records are not updated in real-time, and ENUM makes no special provision for real-time responsiveness. Frequently, DNS records are assigned comparatively long time-to-live (TTL) values, especially due to the prevalence of record caching. Delegation: ENUM is designed to be delegated from the 'golden root' server to individual country codes, and within these country codes potentially to carriers or organizations that own individual numbers or number blocks. ENUM is designed to easily delegate at the granularity of individual digits in an E.164 numbers (through the reverse-resolution e164.arpa domain). It isn't clear how this sort of delegation would occur with 'tel' URLs in a location service; redirection triggering on a partial URI (like matching 'tel:+1202533*') is in any event not described in baseline SIP. Moreover, the manner in which delegation might operate in SIP raises some performance concerns if it involves multiple redirections. Delegation in DNS is comparatively well understood. Peterson, et al. Expires August 9, 2002 [Page 12] Internet-Draft Using ENUM for SIP Applications February 2002 Caching: A redirection message in SIP can contain an Expires header field that indicates how long the information it contains will be valid. However, this Expires header field is generally only processed by endpoints, which means that each endpoint must cache this data itself. DNS utilizes network-based caching - each ENUM client would presumably place requests through a local caching server that would persist redirection addresses when appropriate. Network-based caching is generally a more scalable architecture for persisting query responses. Forking: SIP has a mechanism for exploring multiple possible destinations for a request called forking. Multiple destinations can be tried in parallel or sequentially, as specified by local policy and some elements in signaling. It is common for redirect servers to return multiple destinations in a redirect message. However, it is less clear that the multiple URIs that are used in ENUM records should be forked in this fashion; this is detailed in Section 4.4. Policy: ENUM is half a technology and half a policy. While a location server could be provisioned with a set of E.164 number keys, nothing prevents any other location server from creating records for the same set of keys with different values. The centralized ENUM model prevents this sort of conflict from arising. ENUM records are also known to be authoritative for the record in question, which reduces the possibility of slamming or other forms of service hijacking. However, this policy introduces some limitations - ENUM can only operate on full E.164 numbers, not on private dialing plans or numbers that have not been rendered in an international format. This may also introduce some complications when dealing with partial numbers (such as when overlap dialing is used from the PSTN) - SIP, on the other hand, has a mechanism for contending with an incomplete address. Query String: When an ENUM query is launched, essentially the only information that is provided in the query is the would-be Request- URI of a SIP request, in ENUM cases a telephone number. However, when a SIP request lands at a redirect server, the redirect server could, if it were so inclined, consult parts of the request other than the Request-URI in order to make a routing decision. For example, the redirect server could inspect the domain of the From field in hopes of learning the closest destination to which it could redirect the client. Performance: DNS is a very lightweight protocol that serves only one purpose - record retrieval. All processing of these records is performed locally at the client. SIP, however, is a textual protocol that requires a great deal of server-side processing. Peterson, et al. Expires August 9, 2002 [Page 13] Internet-Draft Using ENUM for SIP Applications February 2002 SIP requires a minimum of three messages to complete a query (e.g. INVITE/3xx/ACK) whereas DNS requires only two, a query and an answer. It is widely believed that the DNS server model is very scalable. 3.5 Conclusions The distinctions outlined in the preceding section do not address what happens after either ENUM or a SIP redirect server returns a SIP URI to a client - namely, the client sends an appropriate SIP request (such as an INVITE) based on the received URI that expresses the client device's communication capabilities. The expression of these capabilities may entail the usage of SDP to list acceptable types of media supported and favored by the client, the inclusion of Required/Supported headers to negotiate compatibility of extensions, and possibly even the usage of optional SIP mechanisms, for example using caller/callee preferences [7] to communicate request handling dispositions. Proxy servers or endpoints subsequently return responses that allow a true bidirectional capability negotiation process. It must be acknowledged that the process by which SIP endpoints negotiate capabilities can overlap (and in some sense compete) with the primary service provided by NAPTR records: permitting the originating client to select a particular URI for communications based on an ordered list of protocols. ENUM's capability management mechanism is decidedly one-way - the administrator of the telephone number expresses capabilities (in the form of protocol names) and preferences that the client must evaluate without negotiation. It is also not clear that authors of ENUM records will necessarily be able to anticipate the capability of the particular device to which a URI will direct communications requests at any given moment - URIs generally do not always point to the same device (when they do, they might as well be replaced with an IPv4 address). Listing available protocols is also not really comparable to the agreement on session media (down to the codec level) and protocol extension support. The negotiation capabilities in SIP described above clearly are far more versatile and useful than the selection of a protocol for communications. However, although ENUM's vocabulary for expressing capabilities is smaller than SIP's, ENUM has a number of strengths that make it useful for the association of a telephone number with a SIP address- of-record - such as its foundation in policy, and its scalability and delegation characteristics. For that reason, it is the contention of this document that ENUM's primary applicability to SIP is to provide a SIP address-of-record corresponding to an E.164 telephone number. Peterson, et al. Expires August 9, 2002 [Page 14] Internet-Draft Using ENUM for SIP Applications February 2002 Listing SIP contact addresses rather than addresses-of-record in ENUM is discouraged because it hampers the proper operation of SIP; SIP's superior dynamic registration capability makes it far better manager of contact addresses than ENUM, which not only defines no means for devices to register, but moreover ENUM records generally must have some longevity in order for the protocol to scale properly. Many non-SIP URIs associated with real-time communication (tel URLs and instant messaging URLs, for example) seem more like contact addresses that should be managed by the SIP registration process, rather than URIs that might be listed in ENUM. URLs that are not associated with real-time communications, like email or http URLs, are probably better candidates to be provisioned directly in ENUM (it is unlikely that, for example, email addresses would benefit from dynamic registration capabilities). The normative language in the following two sections makes recommendations that follow this view of the relationship and demarcation of ENUM and SIP. Because of the public nature of ENUM, it would be wrong-headed to assume that only clients interested in SIP will attempt to use ENUM records - in any event authors of ENUM records cannot guarantee that only a limited group of users will attempt to contact them. That much said, the primary existing use of telephone numbers is telephony (or more generally real-time communications), and therefore it isn't especially unreasonable to go forward on the assumption that SIP is ENUM's primary customer, nor to create records that are intended for use by SIP clients. For that reason, the recommendations that follow frequently suggest that SIP records be preferred, in various ways, to records of other protocols. Peterson, et al. Expires August 9, 2002 [Page 15] Internet-Draft Using ENUM for SIP Applications February 2002 4. Authoring NAPTR records for SIP The guidelines in this section are oriented towards authoring records specifically for SIP applications. These guidelines assume that the reader is familiar with RFC2915 [9]) and RFC2916 [1]). Only those aspects of NAPTR record authoring that have special bearing on SIP, or that require general clarification, are covered in this document; otherwise the procedures in the appropriate RFCs should be followed. This document makes no assumptions about who authors NAPTR records (service providers or end users), nor about any mechanisms by which a record, once it is authored, may be uploaded to the appropriate DNS servers. Authorship in the context of this document concerns only the processes by which the NAPTR records themselves are constructed. There are a few general guidelines which are applicable to the authoring of DNS records that should be considered by the authors of ENUM NAPTR record sets. The most important is that authors SHOULD keep record sets relatively small - DNS is not optimized for the transference of large files. Having five or six NAPTR records is quite reasonable, but policies that encourage records sets of hundreds of NAPTR records are not appropriate. Also, DNS records are relatively permanent; authors SHOULD NOT use ENUM NAPTR records to express relationships between E.164 numbers and URIs that potentially exist for only a short time. DNS is most scalable when it can assume records will be valid for a reasonable length of time (at least several hours). 4.1 The Service Field The Services field of a NAPTR record contains a string that is composed of two subfields: a 'protocol' subfield and a 'resolution service' subfield. The examples used in RFC2915 suggest that the protocol subfield commonly corresponds to the name of a URI scheme (i.e. 'tel', 'sip', 'mailto'). ENUM in particular defines an 'E2U' (E.164 to URI) resolution service. In all of the examples in RFC2915 and RFC2916 in which a SIP URI is the result of a NAPTR transformation, the 'sip+E2U' token is present in the service field. It is strongly RECOMMENDED that authors of NAPTR records use the 'sip+E2U' service field whenever the regexp contains a SIP URI. Implementers of ENUM have argued in the past that new service fields need to be created that provide a greater level of granularity than the existing 'sip+E2U' token. Some of the motivation for providing granular service fields for SIP is predicated on the use of multiple SIP records in a single ENUM record set to characterize different Peterson, et al. Expires August 9, 2002 [Page 16] Internet-Draft Using ENUM for SIP Applications February 2002 services associated with an identity. This motivation is analyzed below in Section 4.4.2. 4.2 Flags in NAPTR RR Authors of NAPTR records MUST use the terminal "u" flag when any 'E2U' based service field, including 'sip+E2U', is specified. 4.3 Creating the Regular Expression: Matching The authorship of the regular expression (henceforth regexp) in a NAPTR record intended for use by ENUM is vastly simplified by the absence of an antecedent in the substitution (i.e. the section between the first two delimiters). It is RECOMMENDED that implementations use an exclamation point as a delimiter, since this is the only delimiter used throughout the ENUM examples in RFC2915 and RFC2916. Ordinarily, when a NAPTR record is processed, the expression in the antecedent is matched against the starting string (for ENUM, the telephone number); however, in ENUM applications, since the desired record set is located through a reverse resolution in the e164.arpa domain that is based on the starting string, further analysis of the starting string on the client side would be redundant. Therefore, the antecedent of the regular expression is always 'greedy' - it uses the regexp '^.*$', which matches any query string. Authors of records intended to be used for SIP applications SHOULD always use a greedy regexp. Example: "!^.*$!sip:info@tele2.se!" Although the antecedent of the regexp is not factored into ENUM applications, that does not mean that the replacement field provides a viable alternative. Authors of NAPTR records for ENUM MUST NOT use the replacement field in records with an 'E2U' service field. 4.3.1 Creating the Regular Expression: The URI The consequent side of a regexp contains a URI; NAPTR records that are intended to be used for session initiation (including SIP telephony) SHOULD use a SIP URI. While this may not sound especially controversial at first hearing, there are other sorts of URIs that might be considered appropriate for SIP applications: 'tel' URLs, 'im' or 'pres' URLs, or others that describe specific services that might be invoked through SIP are all potentially candidates. While the use of these URLs might seem reasonable under some circumstances, including these in NAPTR records rather than SIP URIs could weaken the proper composition of services and negotiation of capabilities in Peterson, et al. Expires August 9, 2002 [Page 17] Internet-Draft Using ENUM for SIP Applications February 2002 SIP. While there is no hard law in any of the existing literature that states that authors of a NAPTR record for ENUM should match the protocol subfield of the service field with the scheme of the URI in the regexp, this practice is followed in all of the examples, and therefore it is RECOMMENDED that authors of ENUM records should always use the SIP URI scheme when the service field is 'sip+E2U'. SIP URIs within NAPTR record SHOULD contain an address-of-record (as described in Section 3.3) rather than a URI that depends on particular hosts (like an IP address or hostname). Users can register one or more contact addresses with a registrar that will be used by the proxy infrastructure of an administrative domain to contact the end user when requests are received for their address-of- record. Putting URIs corresponding to devices through which a user is sometimes available into NAPTR records is NOT RECOMMENDED. Much of the benefit of using a URI comes from the fact that it represents a logical service associated with a user rather than a device - indeed, if ENUM needed to target devices, 'sip+E2IPv4' would be a more appropriate resolution service to define. 4.4 Provisioning multiple NAPTR records In all of the examples in RFC2916, a single NAPTR record with an 'sip+E2U' service field appears in each set of records. However, this 'sip+E2U' record always appears in conjunction with at least one other record. The circumstances under which authors of records should supply multiple NAPTR records, especially multiple records for the same service field value, are not clear. What would it mean if multiple SIP records were present? The most important question to consider is the rationale for including multiple ENUM records for SIP. One possible reason is that a user might wish to include a NAPTR record corresponding to each SIP device they use regularly - this would however be a mistake. The SIP registration mechanism provides a much more appropriate way to group multiple devices under a single identity; for one thing, registration allows particular devices to represent their availability dynamically. ENUM records are not designed to be updated in real time, and therefore ENUM is not a good mechanism for managing particular devices. Another possibility is that a user may have one or more SIP identities, each of which has its own address-of-record. This could be the case if the user subscribes to SIP services from multiple service providers (with URIs like 'sip:user@sipcarrier1.com' and 'sip:user@sipcarrier2.com'), or has different identities for work and Peterson, et al. Expires August 9, 2002 [Page 18] Internet-Draft Using ENUM for SIP Applications February 2002 for home. How would authors of NAPTR records select only one of these addresses-of-record? Should each be placed in its own NAPTR record in the record set, possibly differentiated by preference? This is a sort of pseudo-problem, since the real issue is where the devices employed by the user will register. If device registrations are distributed across the two addresses-of-record, and this circumstance is for whatever reason outside the user's control, then unfortunately placing both addresses-of-record in ENUM wouldn't help, because the client that originated the ENUM query would have no basis to choose between the two NAPTR records in order to find some particular sort of device. The preferred thing for the NAPTR record author to do in this circumstance is to register one address-of- record under the other (like a work identity registered under a home identity), and then to treat the umbrella address-of-record as the one that should be provisioned within ENUM. Finally, ENUM records are accessible to the public, and therefore the author of a NAPTR record set for ENUM cannot assume that any particular sort of client will be the sole consumer of their NAPTR records. The intention behind the use of multiple NAPTR records for SIP cannot be communicated by ENUM, and thus the author of a record set cannot assume any specific local policy will be applied to the interpretation of these records by any given ENUM client. For these reasons, rather than supplying multiple SIP URIs for an ENUM service, authors of NAPTR record sets for ENUM SHOULD use only one SIP URI. 4.4.1 tel URL v. SIP URI Authors of ENUM record sets might want to include tel URLs and 'tel+E2U' service fields when no SIP service is associated with a given E.164 number. Translating between one telephone number and another via ENUM could be used as a mechanism for implementing permanent call forwarding or various PSTN number translation services. Even when a 'sip+E2U' record is created to correspond to a SIP service, some users may wish to have a separate URI for plain telephony that is not associated with SIP for the benefit of non-SIP clients. In this instance a 'tel+E2U' record MAY also be provisioned alongside a 'sip+E2U' record in order to provide a back-up PSTN URI at which the user can be reached. However, it is probably best to treat a tel URL as a contact address, rather than an address-of- record, and thus implementers are advised to register tel URLs with a SIP location service rather than provisioning them in ENUM. If tel URLS are used in ENUM as a back-up, it is RECOMMENDED that they be Peterson, et al. Expires August 9, 2002 [Page 19] Internet-Draft Using ENUM for SIP Applications February 2002 less preferred than SIP records. Note that returning a telephone number in an ENUM record may very well lead to a subsequent ENUM query. For that reason, authors of NAPTR records SHOULD NOT, in an ENUM record set for a given E.164 number, include a 'tel+E2U' record that translates to that same number - although hopefully, ENUM clients will have some mechanism for detecting potential query loops caused by the receipt of a 'tel' URL. Authors should also be mindful that further queries may compound call setup delays, degrading the overall performance of the system. Although handling fax is outside the scope of this document, similar practices could be recommended for the 'fax' URL and a 'fax+E2U' service field, especially when for whatever reason fax capabilities are not available as part of a user's SIP service. 4.4.2 Composing SIP services with ENUM Some implementers of ENUM systems have suggested that the 'sip+E2U' service field is not sufficiently specific to capture SIP's capabilities - that new service fields should be created corresponding to particular services that might be invoked by a SIP user. Several formats for these new service fields have been proposed, including specifying the communications service that will be used by SIP in the protocol subfield (e.g. 'im+E2U', 'pres+E2U') or as part of the resolution service subfield (e.g. 'sip+E2IM', 'sip+E2PRES'). These proposals raise a couple of concerns. Registration and Negotiation: The first and most serious problem with this approach is that it blurs the demarcation between ENUM and SIP. SIP has its own capabilities for discovering the devices associated with an address-of-record and then negotiating the best way to communicate with these devices (see Section 3.1). Pushing this capability forward into ENUM impoverishes SIP without providing comparable functionality in return. Consider for example that a SIP client can attempt to negotiate, within SDP, both audio and video communications simultaneously for a single request. What should a client do if it downloads an ENUM record set that has different NAPTR records for 'sip+E2VIDEO' and 'sip+E2VOICE'? Which should it choose? Exposing through ENUM the contact address of a device (which necessarily has a limited set of capabilities), rather than an address-of-record, will always significantly hamper SIP's capabilities. Mapping an E.164 identity to a device, rather than to another identity under which devices are intelligently managed, does ENUM a disservice. Proliferation: It is also not clear where the proposed taxonomy of Peterson, et al. Expires August 9, 2002 [Page 20] Internet-Draft Using ENUM for SIP Applications February 2002 SIP services should begin and end. If clients need to be able to identify URIs that are associated with multiple services, then composite service fields will be required with values like 'sip+E2VOICE+E2VIDEO'. Theoretically, support for N services might entail support for N-factorial service fields. But perfectionists could argue that even this doesn't go far enough: if you want to advertise the capabilities of endpoints, why specify merely that they support voice - why not also specify each of the codecs that a particular device supports for voice communications ('sip+E2VOICE.G711')? Any degree of proliferation would obviously make ENUM resolvers more complex to implement, and it isn't clear how slippery the slope of proliferation might be. And again, it's not clear how exactly this taxonomy would surpass the native SIP capabilities for discovering the best way for endpoints to communicate. Use of any service fields for SIP records other than 'sip+E2U' is, again, NOT RECOMMENDED. 4.5 Setting Order and Preference amongst Records Some additional confusion arises from the use of order and preference in NAPTR records. The NAPTR algorithm dictates that once a client has ascertained the lowest order that does not contain an 'inappropriate' NAPTR record for this query, the client MUST choose a NAPTR record of this order. 'Appropriateness' is not defined in the standard, but we might generously assume that the determination of the 'appropriateness' of a NAPTR record hinges on the contents of the service field. The draft does note that ascertaining the lowest order record depends on whether or not the antecedent of the regular expression in the record matches the query. But as we've already seen, the regular expression used in NAPTR records for ENUM is always greedy, and therefore according to the NAPTR algorithm the lowest order is, barring a more specific interpretation of appropriateness, the only order that can be used. So in short, the language surrounding the NAPTR algorithm in RFC2915 is somewhat confusing, and it isn't exactly clear how order should be used, especially since there is also a preference field that should also be taken into consideration when selecting a NAPTR record. Consider that in the following example from RFC2916 (where order is the third field from the left and preference the fourth) Peterson, et al. Expires August 9, 2002 [Page 21] Internet-Draft Using ENUM for SIP Applications February 2002 $ORIGIN 4.3.2.1.6.7.9.8.6.4.e164.arpa. IN NAPTR 100 10 "u" "sip+E2U" "!^.*$!sip:info@tele2.se!" . IN NAPTR 102 10 "u" "mailto+E2U" "!^.*$!mailto:info@tele2.se!" . ... the 'mailto' URI can never be reached if the client believes both 'sip+E2U' and 'mailto+E2U' records to be 'appropriate' and the NAPTR algorithm is strictly obeyed. Regardless of whether or not this requires clarification in future issues of the standard, for maximal compatibility authors of ENUM records SHOULD always use the same order value for all NAPTR records in an ENUM record set. If relative preference among NAPTR records is desirable, it should be expressed solely with the preference field. Generally, for record sets that are intended to be used primarily by SIP clients (perhaps for SIP telephony), when multiple NAPTR records appear alongside a 'SIP+E2U' record, it is RECOMMENDED that the SIP record be the most preferred record. Record sets that are intended for use by versatile clients with multiple protocol capabilities MAY assign a SIP lesser preference, but authors should note that SIP- based clients may choose to disregard these preferences. 4.6 Example of a Well-Formed ENUM NAPTR Record Set $ORIGIN 0.0.6.2.3.3.5.2.0.2.1.e164.arpa. IN NAPTR 100 10 "u" "sip+E2U" "!^.*$!sip:user@sipcarrier.com!" . IN NAPTR 100 20 "u" "mailto+E2U" "!^.*$!mailto:user@sipcarrier.com!" . Peterson, et al. Expires August 9, 2002 [Page 22] Internet-Draft Using ENUM for SIP Applications February 2002 5. Processing ENUM records This section addresses only those procedures in RFC2915 and RFC2916 that might pose questions for implementers concerned primarily with SIP. These guidelines do not by any means exhaustively describe the NAPTR algorithm or the processing of NAPTR records; implementers should familiarize themselves with RFC2915 and RFC2916 before reviewing this section. Ideally, the recommendations above for authoring NAPTR records will be followed to the letter; each NAPTR record set will contain a SIP URI (and if possible nothing else). This section assumes that implementers must be prepared for more complicated scenarios - however, just because we recommend that clients should be generous in what they receive, and try to make sense of potentially confusing NAPTR records, that does not mean that we recommend any of the potentially troublesome authoring practices that make this generosity necessary. 5.1 Selecting a number for a query Before a starting string (the telephone number to be reversed) can be constructed in the manner described in RFC2916, the originator of the query SHOULD make sure that the telephone number it intends to resolve is a complete E.164 address. Network elements SHOULD have some means of determining whether an address is complete in the E.164 system, especially when interworking with networks that use overlap PSTN signaling. In some cases originators of ENUM queries MAY need to modify telephone numbers before creating a query string; for example, in North American networks by removing a leading '011' from the raw number dialed by the end user, or prepending a country code ('1' for North America) or an area code to a national number. 5.2 Examining Service fields When a set of NAPTR records are received by an ENUM client in response to a query, the client must first decide which records, if any, are appropriate for its applications. According to the NAPTR algorithm, clients are permitted to discard any 'inappropriate' records at the outset of processing. Here we will gauge appropriateness by the capabilities of the client; presumably a client will be provisioned with a set of service fields which it supports, and all records whose service fields intersect with this set will be considered appropriate. ENUM clients acting on behalf of a SIP application will generally be interested in NAPTR records that contain Service fields of 'sip+E2U'; Peterson, et al. Expires August 9, 2002 [Page 23] Internet-Draft Using ENUM for SIP Applications February 2002 SIP telephony clients may also be interested in 'tel+E2u'. Clients MAY make a preliminary pass on all received NAPTR records to eliminate all records that do not contain one of these two service fields. If future NAPTR service fields are defined that are relevant to the SIP application, they SHOULD also be retained in this preliminary pass. 5.3 Handling Order and Preference The purpose of the 'order' field of NAPTR records is related to delegation, and is therefore not immediately significant to the ENUM application; there is no particular reason why authors of ENUM records would want to make use of different orders among multiple records. If only a single order is used in the NAPTR record set, then order may be completely ignored and preference taken as a suggestion for how the records should be processed. However, if the most preferred NAPTR record overall does not have a 'sip+E2U' service field, the ENUM client SHOULD seek out the most preferred NAPTR record that contains a 'sip+E2U' service field, disregarding 'tel+E2U' or any other non-SIP schemes. If different orders are present in the NAPTR record set, then the NAPTR algorithm forbids the inspection of records of an order other than the lowest order containing a match for the current query. However, since the usage of 'order' may be confusing to authors of ENUM records, ENUM clients should conflate the 'order' and 'preference' fields. The simplest manner of doing so is to place a decimal point between the 'order' and 'preference' field and to treat the two so combined as a preference. Consider the following example (and please keep in mind that this does not follow the authorship guidelines above): $ORIGIN 4.3.2.1.6.7.9.8.6.4.e164.arpa. IN NAPTR 100 10 "u" "tel+E2U" "!^.*$!tel:info@tele2.se!" . IN NAPTR 102 10 "u" "sip+E2U" "!^.*$!sip:info@tele2.se!" . IN NAPTR 102 20 "u" "mailto+E2U" "!^.*$!mailto:info@tele2.se!" . Following this schema, the 'sip' record would be treated as if it had a preference of 102.1, the 'tel' record a preference of 100.1, and the 'mailto' record a preference of 102.2. Note that in this case the 'sip+E2U' record should still be selected over the 'tel+E2U' record by a SIP client, despite the preference values. Peterson, et al. Expires August 9, 2002 [Page 24] Internet-Draft Using ENUM for SIP Applications February 2002 5.4 Contending with multiple SIP records If an ENUM query returns multiple NAPTR records that have a service field of 'sip+E2U', the ENUM client must first determine whether or not it should attempt to make use of multiple records or select a single one. The pitfalls of intentionally authoring ENUM record sets with multiple NAPTR records for SIP are detailed above in Section 4.4.2 and will not be reiterated here. If the ENUM client is a user agent, then at some point a single NAPTR record must be selected to serve as the Request-URI of the desired SIP request. If the SIP NAPTR records have different preferences, the most preferred record SHOULD be used. If two or more records share most preferred status, the ENUM client SHOULD randomly determine which record will be used, though it MAY defer to a local policy that employs some other means to select a record. If the ENUM client is a proxy server, then it MAY fork the request when it receives multiple 'sip+E2U' NAPTR records in an ENUM record set. Depending on the relative precedence values of the NAPTR records the proxy may wish to fork sequentially or in parallel. Alternatively, the proxy server MAY select a single record in accordance with the NAPTR preference fields (or randomly when no preference is specified, or in accordance with local policy) and proxy the request with a Request-URI corresponding to the URI field of this NAPTR record. Note that there are significant limitations (detailed at the end of Section 3.1) that arise if a proxy server processes ENUM record sets instead of a user agent, and that therefore it is RECOMMENDED that SIP network elements act as redirect servers rather than proxy servers after an ENUM query. If the ENUM client is a redirect server, then it MAY return a 3xx response with more than one Contact header field corresponding to the multiple 'sip+E2U' NAPTR records in an ENUM record set. If the NAPTR records have different preferences, then 'q' values may be used in the Contact header fields to correspond to these preferences. Alternatively, the redirect server MAY select a single record in accordance with the NAPTR preference fields (or randomly when no preference is specified) and send this resulting URI in a Contact header field in a 3xx. 5.5 Processing NATPR records in a client Obviously, when an appropriate NAPTR record has been selected, the URI should be extracted from the regexp field. The URI is between the second and third exclamation points in the string. Once a URI has been extracted from the NAPTR record, it SHOULD be used as the Request-URI of the SIP request for which the ENUM query was launched. Peterson, et al. Expires August 9, 2002 [Page 25] Internet-Draft Using ENUM for SIP Applications February 2002 SIP clients should perform some sanity checks on the URI, primarily to ensure that they support the scheme of the URI, but also to verify that the URI is well-formed. Clients should also check to make sure that the Request-URI does not target themselves. Once an address-of-record has been extracted from the selected NAPTR record, clients should follow the standard SIP mechanisms for determining how to forward the request. This may involve launching subsequent NAPTR or SRV queries in order to determine how best to route to the domain identified by an address-of-record; clients however MUST NOT make the same query recursively. Note that SIP requests based on the use of NAPTR records may fail. If there are multiple NAPTR records relevant to SIP present in an ENUM record set, then after a failure has occurred on an initial attempt with one NAPTR record, SIP clients MAY try their request again with a different NAPTR record from the ENUM record set. Peterson, et al. Expires August 9, 2002 [Page 26] Internet-Draft Using ENUM for SIP Applications February 2002 6. Limits of ENUM This section documents some of the things that ENUM, as it is described in RFC2916, does not do. ENUM has intentionally limited its own scope in order to meet certain policy goals, and as a result there is some potentially desirable functionality for SIP implementers that might, at first glance at the standard, seem like something ENUM provides, but which is actually outside the scope of ENUM as such. Because these limitations of ENUM are largely self-imposed rather than technological restrictions, there are of course other technologies that do not have these constraints. The underlying NAPTR technology behind ENUM is very flexible, and could be applied to all manner of translations beyond ENUM; in time, ENUM may expand its scope to remove some of the limitations described below. Currently, however, RFC2916 provides a very narrow scope for ENUM that allows only one specific form of translation. Specifically, ENUM is not used to query for translations of any of the following: Arbitrary strings: Although NAPTR operates on arbitrary strings, ENUM operates specifically on numbers (telephone numbers, even). No sorts of textual names, numeric strings unrelated to telephony, hostnames, URIs or URNs are resolved and translated by ENUM. Private dialing plans: Many enterprise telephone systems and private branch exchanges use private dialing plans for internal calls; commonly, these are abbreviated numbers (like '82600') in which a single leading digit indicates that the call is local to the enterprise. ENUM, however, operates only on 'public' numbers that are ubiquitously reachable in the PSTN. National numbers: Numbers that are in a national form (such as '2025332600') rather than an international form ('+12025332600') will not resolve properly in ENUM. While it is generally trivial to convert a national number to an international number, ENUM has no mechanism for doing so - figuring out the country code that should be appended to a national number would require some decision in the network based on the originator of the query (guessing at their location, or somehow matching them to a known policy). ENUM does not make origination-based policy decisions when processing queries. Incomplete E.164 numbers: ENUM has no defined mechanism for servers to recognize or indicate that they have received an incomplete address in a query. This might occur, for example, in 'en bloc' Peterson, et al. Expires August 9, 2002 [Page 27] Internet-Draft Using ENUM for SIP Applications February 2002 signaling if a user inputs half of a telephone number to a cell phone and then accidentally hits the 'Talk' button, or in 'overlap' PSTN signaling if only part of the digits dialed by the user are communicated to a network element when it launches an ENUM query. If at all possible, network elements that might make ENUM queries should take care to operate only on complete addresses. E.164 number prefixes: A NAPTR record set grouped under a E.164 number prefix (like '+1202533') might signify any of a number of things. This might be some sort of master record for a zone. It might signify a record intended for prefix-based routing. It might even be there to catch incomplete E.164 number translation attempts. However, the standard is silent about this matter, and therefore the meaning of these records would be ambiguous at best. Neither creating records under partial E.164 numbers nor sending queries for partial E.164 numbers are standard or meaningful behavior in ENUM. Peterson, et al. Expires August 9, 2002 [Page 28] Internet-Draft Using ENUM for SIP Applications February 2002 7. Security Considerations DNS does not make policy decisions about the records that it shares with an inquirer. All DNS records must be assumed to be available to all inquirers at all times. The information provided within an ENUM record set must therefore be considered to be open to the public - which is a cause for some privacy considerations. Ordinarily, when you give someone your telephone number, you don't expect that they will be able to trivially determine your full name and place of employment. If, however, you create a NAPTR record for use with ENUM that maps your telephone number to a SIP URI like 'sip:julia.roberts@vivendi.com', expect to get a lot of calls from excited fans. Unlike a traditional telephone number, the target of a SIP URI may require that callers provide cryptographic credentials for authentication and authorization before a user is alerted. In this respect, ENUM in concert with SIP can actually provide far greater protection from unwanted callers than the existing PSTN, despite the public availability of ENUM records. Users of ENUM who are nevertheless uncomfortable with revealing their names may, since identities on the Internet are not exactly at a premium, publish a less revealing SIP URI, like 'sip:anonymous00045@vivendi.com' or even 'sip:anonymous00045@anonymous-redirector.com', which could in turn point to their internal URI. Peterson, et al. Expires August 9, 2002 [Page 29] Internet-Draft Using ENUM for SIP Applications February 2002 8. IANA Considerations This document introduces no new values for any IANA registries. Peterson, et al. Expires August 9, 2002 [Page 30] Internet-Draft Using ENUM for SIP Applications February 2002 References [1] Faltstrom, P., "E.164 number and DNS", RFC 2916, September 2000. [2] Mockapetris, P., "Domain Names - Concepts and Facilities", RFC 1034, November 1987. [3] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998. [4] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, March 1999. [5] International Telecommunications Union, "Recommendation E.164: The international public telecommunication numbering plan", May 1997, . [6] Vaha-Sipila, A., "URLs for Telephone Calls", RFC 2806, April 2000. [7] Rosenberg, J. and H. Schulzrinne, "SIP Caller Preferences and Callee Capabilities", draft-ietf-sip-callerprefs-05 (work in progress), November 2001. [8] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June 1999. [9] Mealling, M. and R. Daniel, "The Naming Authority Pointer (NAPTR) DNS Resource Record", RFC 2915, September 2000. [10] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998. [11] Rosenberg, J., Squire, M. and H. Salama, "Telephony Routing over IP (TRIP)", draft-ietf-iptel-trip-09 (work in progress), August 2001. [12] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS Standard", draft-ietf-urn-ddds-toc- 00 (work in progress), October 2001. [13] Bush, R., "How ENUM, SIP URIs, TRIP, and Gateways Relate", draft-ymbk-enum-trip-00 (work in progress), July 2001. Peterson, et al. Expires August 9, 2002 [Page 31] Internet-Draft Using ENUM for SIP Applications February 2002 Authors' Addresses Jon Peterson NeuStar, Inc. 1800 Sutter St Suite 570 Concord, CA 94520 USA Phone: +1 925/363-8720 EMail: jon.peterson@neustar.biz URI: http://www.neustar.biz/ Hong Liu NeuStar, Inc. 1120 Vermont St Suite 400 Washington, DC 2005 USA Phone: +1 202/533-2600 EMail: hong.liu@neustar.biz URI: http://www.neustar.biz/ James Yu NeuStar, Inc. 1120 Vermont St Suite 400 Washington, DC 2005 USA Phone: +1 202/533-2814 EMail: james.yu@neustar.biz URI: http://www.neustar.biz/ Ben Campbell dynamicosft 5100 Tennyson Parkway Suite 1200 Plano, TX 75024 USA EMail: bcampbell@dynamicsoft.com URI: http://www.dynamicsoft.com/ Peterson, et al. Expires August 9, 2002 [Page 32] Internet-Draft Using ENUM for SIP Applications February 2002 Appendix A. Acknowledgments The authors would like to thank Richard Shockey for his input on privacy issues, and Tom McGarry and Rohan Mahy for overall comments and analysis. The question of the relationship of ENUM, TRIP and SIP is also explored in a Internet-Draft by Randy Bush [13]. This draft was authored in the XML format described in RFC2629 [8]. Peterson, et al. Expires August 9, 2002 [Page 33] Internet-Draft Using ENUM for SIP Applications February 2002 Appendix B. To Do Update for DDDS: Once the DDDS [12] document-set has been approved by the IESG, RFC2915 will become obsolete, and RFC2916 will presumably be updated accordingly. At such a time new practices for SIP may need to be identified. Comparison with TRIP: It might be interesting to stage a comparison of ENUM-based routing with TRIP [11] along the lines of the analysis in Section 3.4. Update for RFC 2543bis: The new SIP RFC will incorporate a number of changes that are material to the demarcation of ENUM and SIP; once that work is complete, this document should be updated accordingly. Peterson, et al. Expires August 9, 2002 [Page 34] Internet-Draft Using ENUM for SIP Applications February 2002 Full Copyright Statement Copyright (C) The Internet Society (2002). 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. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Peterson, et al. Expires August 9, 2002 [Page 35]