diff options
Diffstat (limited to 'doc/rfc/rfc3824.txt')
| -rw-r--r-- | doc/rfc/rfc3824.txt | 899 |
1 files changed, 899 insertions, 0 deletions
diff --git a/doc/rfc/rfc3824.txt b/doc/rfc/rfc3824.txt new file mode 100644 index 0000000..e4b556c --- /dev/null +++ b/doc/rfc/rfc3824.txt @@ -0,0 +1,899 @@ + + + + + + +Network Working Group J. Peterson +Request for Comments: 3824 H. Liu +Category: Informational J. Yu + NeuStar + B. Campbell + dynamicsoft + June 2004 + + + Using E.164 numbers with the Session Initiation Protocol (SIP) + +Status of this Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2004). + +Abstract + + There are a number of contexts in which telephone numbers are + employed by Session Initiation Protocol (SIP) applications, many of + which can be addressed by ENUM. Although SIP was one of the primary + applications for which ENUM was created, there is nevertheless a need + to define procedures for integrating ENUM with SIP implementations. + This document illustrates how the two protocols might work in + concert, and clarifies the authoring and processing of ENUM records + for SIP applications. It also provides guidelines for instances in + which ENUM, for whatever reason, cannot be used to resolve a + telephone number. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 + 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 3. Handling Telephone Numbers in SIP . . . . . . . . . . . . . . 3 + 4. Design Principles . . . . . . . . . . . . . . . . . . . . . . 5 + 5. Authoring NAPTR Records for SIP . . . . . . . . . . . . . . . 6 + 5.1. The Service Field . . . . . . . . . . . . . . . . . . . 6 + 5.2. Creating the Regular Expression: Matching . . . . . . . 6 + 5.3. Creating the Regular Expression: The URI . . . . . . . . 7 + 5.4. Setting Order and Preference amongst Records . . . . . . 8 + 5.5. Example of a Well-Formed ENUM NAPTR Record Set for SIP. 8 + 6. Processing ENUM Records . . . . . . . . . . . . . . . . . . . 8 + 6.1. Contending with Multiple SIP records . . . . . . . . . . 8 + + + +Peterson, et al. Informational [Page 1] + +RFC 3824 SIPPING E.164 June 2004 + + + 6.2. Processing the Selected NAPTR Record . . . . . . . . . . 9 + 7. Compatibility with RFC 3761. . . . . . . . . . . . . . . . . . 10 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 + 9.1. Normative References . . . . . . . . . . . . . . . . . . 11 + 9.2. Informative References . . . . . . . . . . . . . . . . . 12 + A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 15 + Full Copyright Statement . . . . . . . . . . . . . . . . . . . 16 + +1. Introduction + + ENUM (E.164 Number Mapping, RFC 3761 [1]) is a system that uses DNS + (Domain Name Service, RFC 1034 [4]) in order to translate certain + telephone numbers, like '+12025332600', into URIs (Uniform Resource + Identifiers, RFC 2396 [9]), 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. E.164 [10] is the ITU-T standard international + numbering plan, under which all globally-reachable telephone numbers + are organized. + + SIP (Session Initiation Protocol, RFC 3261 [2]) 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 most widespread application for SIP today is Voice-over-IP + (VoIP). As such, there are a number of cases in which SIP + applications are forced to contend with telephone numbers. + Unfortunately, telephone numbers cannot be routing in accordance with + the traditional DNS resolution procedures standardized for SIP (see + [14]), which rely on SIP URIs. ENUM provides a method for + translating E.164 numbers into URIs, including potentially SIP URIs. + This document therefore provides an account of how SIP can handle + telephone numbers by making use of ENUM. 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. + + The guidelines in this document are oriented towards authoring and + processing ENUM records specifically for SIP applications. These + guidelines assume that the reader is familiar with Naming Authority + Pointer (NAPTR) records (RFC 3403 [6]) and ENUM (RFC 3761 [1]). Only + those aspects of NAPTR record authoring and processing that have + + + +Peterson, et al. Informational [Page 2] + +RFC 3824 SIPPING E.164 June 2004 + + + special bearing on SIP, or that require general clarification, are + covered in this document; these procedures do not update or override + the NAPTR or ENUM core documents. + + Note that the ENUM specification has undergone a revision shortly + before the publication of this document, driven by the update of the + NAPTR system described in RFC 2915 [12] to the Dynamic Delegation + Discovery System (DDDS) family of specifications (including RFC + 3403). This document therefore provides some guidance for handling + records designed for the original RFC 2916 [16]. + + The remainder of this document is organized as follows: Section 3 + suggests general behavior for SIP user agents that encounter + telephone numbers; Section 4 provides an overview of the intersection + of SIP and ENUM; proposed normative guidelines for ENUM record + authoring and processing in the context of SIP are described in + Section 5, and Section 6 respectively; some considerations relevant + to the revision of RFC 2916 are given in Section 7. + +2. Terminology + + In this document, the key words "MUST", "MUST NOT", "REQUIRED", + "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT + RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as + described in RFC 2119 [3] and indicate requirement levels for + compliant SIP implementations. + +3. Handling Telephone Numbers in SIP + + 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 most cases, these are requests for + a telephony session (voice communication), though numerous other + services are also reached through telephone numbers (including + instant messaging services). + + Unlike a URI, a telephone number does not contain a host name, or any + hints as to where one might deliver a request targeting a telephone + number on the Internet. While SIP user agents or proxy servers could + be statically provisioned with a mapping of destinations + corresponding to particular telephone numbers or telephone number + + + +Peterson, et al. Informational [Page 3] + +RFC 3824 SIPPING E.164 June 2004 + + + ranges, considering the size and complexity of a complete mapping, it + would be preferable for SIP user agents to be able to query as needed + for a destination appropriate for a particular telephone number. + + In such cases a user agent might use ENUM to discover a URI + associated with the E.164 number - including a SIP URI. URIs + discovered through ENUM can then be used normally to route SIP + requests to their destination. Note that support for the NAPTR DNS + resource record format is specified for ordinary SIP URI processing + in [14], and thus support for ENUM is not a significant departure + from baseline SIP DNS routing. + + Most of the remainder of this document provides procedures for the + use of ENUM, but a few guidelines are given in the remainder of this + section for cases in which ENUM is not used, for whatever reason. + + If a user agent is unable to translate an E.164 number with ENUM, 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 RFC 2806 [8] 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 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 can contain a tel URL (without the scheme string, like + sip:+12025332600@carrier.com;user=phone). 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. + + In the absence of support for ENUM, or if ENUM requests return no + records corresponding to a telephone number, local policy can be used + to determine how to forward SIP requests with an E.164 number in the + Request-URI. Frequently, such calls are routed to gateways that + interconnect SIP networks with the PSTN. These proxy server policies + might be provisioned dynamically with routing information for + telephone numbers by TRIP [15]. As a matter of precedence, SIP user + agents should attempt to translate telephone numbers to URIs with + ENUM, if implemented, before creating a tel URL, and deferring the + routing of this request to a SIP proxy server. + + + + + + + + +Peterson, et al. Informational [Page 4] + +RFC 3824 SIPPING E.164 June 2004 + + +4. Design Principles + + Although the applicability of ENUM to SIP has always been clear, the + exact way in which the two should cooperate has been a subject of + some controversy. How many SIP URIs should appear in ENUM, what kind + of URIs they are, whether or not the "service" field of NAPTR records + should contain capability information - numerous questions have + arisen around the authoring, and interpretation of ENUM records for + SIP consumers. The following, then, is a statement of the particular + philosophy that has motivated the recommendations in this document: + + Address-of-record SIP URIs appear in ENUM, not contact address + URIs. Roughly speaking, an address-of-record is the canonical + identity of a SIP user - it usually appears in the From field of + SIP requests sent by that user; a contact address is the URI of a + device. The process of registration in SIP (using the REGISTER + method), for example, temporarily binds the contact address of a + device to the address-of-record of a user. A DNS record has a + long time-to-live when compared with the timeframe of SIP + registrations. The availability of an address-of-record also + transcends the availability of any single device. ENUM is more + suitable for representing an long-term identity than the URI of + any device with which a user is temporarily associated. If ENUM + were purposed to map to specific devices, it would be better to + translate telephone numbers to IPv4 addresses than to URIs (which + express something richer). + + SIP URIs in ENUM do not convey capability information. SIP has + its own methods for negotiating capability information between + user agents (see SDP [13], the use of Require/Supported to + negotiate extensions in RFC 3261, and callee capabilities [11]); + providing more limited capability information within ENUM is at + best redundant and at worst potentially misleading to SIP's + negotiation system. Also, addresses-of-record do not have + capabilities (only devices registered under an address-of-record + have actual capabilities), and putting contact addresses in ENUM + is not recommended. + + Only one SIP URI, ideally, appears in an ENUM record set for a + telephone number. While it may initially seem attractive to + provide multiple SIP URIs that reach the same user within ENUM, if + there are multiple addresses at which a user can be contacted, + considerably greater flexibility is afforded if multiple URIs are + managed by a SIP location service that is identified by a single + record in ENUM. Behavior for parallel and sequential forking in + SIP, for example, is better managed in SIP than in a set of ENUM + records. + + + + +Peterson, et al. Informational [Page 5] + +RFC 3824 SIPPING E.164 June 2004 + + + User agents, rather than proxy servers, should process ENUM + records. The assumptions underlying the processing of NAPTR + records dictate that the ENUM client knows the set of enumservices + supported by the entity that is attempting to communicate. A SIP + proxy server is unlikely to know the enumservices supported by the + originator of a SIP request. + +5. Authoring NAPTR Records for SIP + + 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). + +5.1. The Service Field + + The Service field of a NAPTR record (per RFC 3403) contains a string + token that designates the protocol or service associated with a + particular record (and which imparts some inkling of the sort of URI + that will result from the use of the record). ENUM [1] requires the + IANA registration of service fields known as "enumservices". + + An enumservice for SIP has been developed in the ENUM working group + (see [7]) which uses the format 'E2U+sip' to designate that a SIP + address-of-record appears in the URI field of a NAPTR record. It is + strongly RECOMMENDED that authors of NAPTR records use the 'E2U+sip' + service field whenever the regexp contains a SIP address-of-record + URI. + +5.2. 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 + + + +Peterson, et al. Informational [Page 6] + +RFC 3824 SIPPING E.164 June 2004 + + + 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 core specification. + + When a NAPTR record is processed, the expression in the antecedent is + matched against the starting string (for ENUM, the telephone number) + to assist in locating the proper record in a set; 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 will usually be unnecessary. In such cases, the + antecedent of the regular expression is commonly 'greedy' - it uses + the regexp '^.*$', which matches any starting string. Some authors + of ENUM record sets may want to use the full power of regexps, and + create non-greedy antecedents; the DDDS standard requires that ENUM + resolvers support these regexps when they are present. For providing + a trivial mapping from a telephone number to a SIP URI, the use of a + greedy regexp usually suffices. + + Example: "!^.*$!sip:user@example.com!" + + Note that when the antecedent of the regexp is greedy, this does not + mean that the replacement field in NAPTR records provides a viable + alternative to authoring with a regexp. Authors of NAPTR records for + ENUM MUST NOT use the replacement field in records with an 'E2U+sip' + service field. + +5.3. 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' URIs, + 'im' or 'pres' URIs, or others that describe specific services that + might be invoked through SIP are all potentially candidates. While + the use of these URIs 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 + SIP. + + It is RECOMMENDED that authors of ENUM records should always use the + SIP or SIPS URI scheme when the service field is 'E2U+sip', and the + URIs in question MUST be addresses-of-record, not contact addresses. + + Users of SIP can register one or more contact addresses with a SIP + registrar that will be consulted by the proxy infrastructure of an + administrative domain to contact the end user when requests are + + + +Peterson, et al. Informational [Page 7] + +RFC 3824 SIPPING E.164 June 2004 + + + received for their address-of-record. 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 needs + to target specific devices rather than URIs, then a hypothetical + 'E2IPv4+sip' enumservice would be more appropriate. + +5.4. Setting Order and Preference amongst Records + + For maximal compatibility authors of ENUM records for SIP 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. + +5.5. Example of a Well-Formed ENUM NAPTR Record Set for SIP + + $ORIGIN 0.0.6.2.3.3.5.2.0.2.1.e164.arpa. + IN NAPTR 100 10 "u" "E2U+sip" "!^.*$!sip:user@example.com!" . + IN NAPTR 100 20 "u" "E2U+mailto" "!^.*$!mailto:info@example.com!" . + +6. Processing ENUM Records + + These guidelines do not by any means exhaustively describe the NAPTR + algorithm or the processing of NAPTR records; implementers should + familiarize themselves with the DDDS algorithm and ENUM before + reviewing this section. + + Although in some cases, ENUM record sets will consist only a single + 'E2U+sip' record, this section assumes that integrators of ENUM and + SIP 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. + +6.1. Contending with Multiple SIP records + + If an ENUM query returns multiple NAPTR records that have a service + field of 'E2U+sip', or other service field that may be used by SIP + (such as 'E2U+pres', see [17]) 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. + + 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 given NAPTR records have different preferences, + the most preferred record SHOULD be used. If two or more records + + + +Peterson, et al. Informational [Page 8] + +RFC 3824 SIPPING E.164 June 2004 + + + 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 SIP intermediary that can act a redirect + server, then it SHOULD return a 3xx response with more than one + Contact header field corresponding to the multiple selected 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 response. + + Otherwise, if the ENUM client is a SIP intermediary that can act as a + proxy server, then it MAY fork the request when it receives multiple + appropriate 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. However, the proxy MUST build a + route set from these NAPTR records that consists exclusively of SIP + or SIPS URIs, not other URI schemes. 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 - though again, + it MUST select a record that contains a SIP or SIPS URI. Note that + there are significant limitations 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 performing an ENUM query. + +6.2. Processing the Selected NAPTR Record + + 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. + + 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 MUST at least verify that the + Request-URI does not target themselves. + + Once an address-of-record has been extracted from the selected NAPTR + record, clients follow the standard SIP mechanisms (see [14]) for + determining how to forward the request. This may involve launching + subsequent NAPTR or SRV queries in order to determine how best to + + + +Peterson, et al. Informational [Page 9] + +RFC 3824 SIPPING E.164 June 2004 + + + route to the domain identified by an address-of-record; clients + however MUST NOT make the same ENUM query recursively (if the URI + returned by ENUM is or contains a tel URL, see [8]). + + Note that SIP requests based on the use of NAPTR records may fail for + any number of reasons. 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 user agents + MAY try their request again with a different NAPTR record from the + ENUM record set. + +7. Compatibility with RFC 2916 + + The ENUM specification is currently undergoing a revision in the ENUM + WG. The new specification, RFC 3761 [1], is based on the Dynamic + Delegation Discovery System [5] revision to the NAPTR resource record + specified in RFC 2915 [12]. For the most part, DDDS is an + organizational revision that makes the algorithmic aspects of record + processing separable from any underlying database format (such as the + NAPTR DNS resource record). + + The most important revision in RFC 3761 is the concept of + enumservices. The original ENUM specification, RFC 2916, specified a + number of "service" values that could be used for ENUM, including the + "sip+E2U" service field. RFC 3761 introduces an IANA registration + system with new guidelines for the registration of enumservices, + which are no longer necessarily divided into discreet "service" and + "protocol" fields, and which admit of more complex structures. In + order to differentiate enumservices in RFC 3761 from those in RFC + 2916, the string "E2U" is the leading element in an enumservice + field, whereas by RFC 2916 it was the trailing element. + + An enumservice for SIP addresses-of-record is described in [7]. This + enumservice uses the enumservice field "E2U+sip". RFC 3761-compliant + authors of ENUM records for SIP MUST therefore use the "E2U+sip" + enumservice field instead of the "sip+E2U" field. For backwards + compatibility with existing legacy records, however, the 'sip+E2U' + field SHOULD be supported by an ENUM client that support SIP. + + Also note that the terminology of DDDS differs in a number of + respects from the initial NAPTR terminology in RFC 2916. DDDS + introduces the concept of an Application, an Application Specific + String, a First Well Known Rule, and so on. The terminology used in + this document is a little looser (it refers to a 'starting string', + for example, where 'Application Specific String' would be used for + DDDS). The new terminology is reflected in RFC 3761. + + + + + +Peterson, et al. Informational [Page 10] + +RFC 3824 SIPPING E.164 June 2004 + + +8. 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 + 'julia.roberts@example.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@example.com' or even + 'sip:anonymous00045@anonymous-redirector.example.org', which could in + turn point to their internal URI. + + An analysis of threats specific to the dependence of ENUM on the DNS, + and the applicability of DNSSEC [18] to these, is provided in [1]. + +9. References + +9.1. Normative References + + [1] Faltstrom, P. and M. Mealling, "E.164 to Uniform Resource + Identifiers (URI) Dynamic Delegation Discovery System (DDDS) + Application (ENUM)", RFC 3761, April 2004. + + [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., + Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: + Session Initiation Protocol", RFC 3261, May 2002. + + [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + + + + +Peterson, et al. Informational [Page 11] + +RFC 3824 SIPPING E.164 June 2004 + + + [4] Mockapetris, P., "Domain Names - Concepts and Facilities", + STD13, RFC 1034, November 1987. + + [5] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part + One: The Comprehensive DDDS", RFC 3401, October 2002. + + [6] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part + Three: The Domain Name System (DNS) Database", RFC 3403, + October 2002. + + [7] Peterson, J., "enumservice registration for SIP Addresses-of- + Record", RFC 3764, April 2004. + + [8] Vaha-Sipila, A., "URLs for Telephone Calls", RFC 2806, April + 2000. + + [9] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform + Resource Identifiers (URI): Generic Syntax", RFC 2396, August + 1998. + +9.2. Informative References + + [10] International Telecommunications Union, "Recommendation E.164: + The international public telecommunication numbering plan", May + 1997, <http://www.itu.int>. + + [11] Rosenberg, J., Schulzrinne, H. and P. Kyzviat, "Indicating User + Agent Capabilities in the Session Initiation Protocol (SIP)", + Work in Progress, June 2003. + + [12] Mealling, M. and R. Daniel, "The Naming Authority Pointer + (NAPTR) DNS Resource Record", RFC 2915, September 2000. + + [13] Handley, M. and V. Jacobson, "SDP: Session Description + Protocol", RFC 2327, April 1998. + + [14] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol: + Locating SIP Servers", RFC 3263, June 2002. + + [15] Rosenberg, J., Squire, M., and H. Salama, "Telephony Routing + over IP (TRIP)", RFC 3219, August 2001. + + [16] Faltstrom, P., "E.164 number and DNS", RFC 2916, September + 2000. + + + + + + + +Peterson, et al. Informational [Page 12] + +RFC 3824 SIPPING E.164 June 2004 + + + [17] Peterson, J., "Enumservice Registration for Presence Services", + Work in Progress, February 2003. + + [18] Arends, R., et al., "Protocol Modifications for the DNS + Security Extensions", Work in Progress, May 2004. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Peterson, et al. Informational [Page 13] + +RFC 3824 SIPPING E.164 June 2004 + + +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. Thanks are due as well to Juan Heinanen and Lawrence + E. Conroy for advice on updating this document to better reflect RFC + 3761. Special thanks are given to Patrik Faltstrom and Michael + Mealling for significantly reducing the size of this document by + producing a tight and well-specified successor to RFC 2916. Richard + Stastny and Patrik Faltstrom also provided valuable notes on the + valid usage of non-greedy regexp antecedents. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Peterson, et al. Informational [Page 14] + +RFC 3824 SIPPING E.164 June 2004 + + +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. + 46000 Center Oak Plaza + Sterling, VA 20166 + USA + + EMail: hong.liu@neustar.biz + URI: http://www.neustar.biz/ + + + James Yu + NeuStar, Inc. + 46000 Center Oak Plaza + Sterling, VA 20166 + USA + + Phone: +1 571/434-5572 + EMail: james.yu@neustar.biz + URI: http://www.neustar.biz/ + + + Ben Campbell + dynamicsoft + 5100 Tennyson Parkway + Suite 1200 + Plano, TX 75024 + USA + + EMail: bcampbell@dynamicsoft.com + URI: http://www.dynamicsoft.com/ + + + + + + + +Peterson, et al. Informational [Page 15] + +RFC 3824 SIPPING E.164 June 2004 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2004). This document is subject + to the rights, licenses and restrictions contained in BCP 78, and + except as set forth therein, the authors retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM 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. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at ietf- + ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + +Peterson, et al. Informational [Page 16] + |