--- 1/draft-ietf-drinks-spprov-02.txt 2010-10-22 21:14:52.000000000 +0200 +++ 2/draft-ietf-drinks-spprov-03.txt 2010-10-22 21:14:52.000000000 +0200 @@ -1,23 +1,23 @@ DRINKS J-F. Mule Internet-Draft CableLabs Intended status: Standards Track K. Cartwright -Expires: April 15, 2011 TNS +Expires: April 25, 2011 TNS S. Ali NeuStar A. Mayrhofer enum.at GmbH - October 12, 2010 + October 22, 2010 Session Peering Provisioning Protocol - draft-ietf-drinks-spprov-02 + draft-ietf-drinks-spprov-03 Abstract This document defines a protocol for provisioning session establishment data into Session Data Registries and SIP Service Provider data stores. The provisioned data is typically used by various network elements for session peering. This document describes the Session Peering Provisioning Protocol used by clients to provision registries. The document provides a set @@ -33,21 +33,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." - This Internet-Draft will expire on April 15, 2011. + This Internet-Draft will expire on April 25, 2011. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -84,58 +84,59 @@ 6. Protocol Commands . . . . . . . . . . . . . . . . . . . . . . 27 6.1. Add Route Group Operation . . . . . . . . . . . . . . . . 27 6.2. Get Route Groups Operation . . . . . . . . . . . . . . . . 31 6.3. Add Destination Group Operation . . . . . . . . . . . . . 32 6.4. Get Destination Groups Operation . . . . . . . . . . . . . 33 6.5. Add Route Group Offer Operation . . . . . . . . . . . . . 34 6.6. Accept Route Group Offer Operation . . . . . . . . . . . . 36 6.7. Reject Route Group Offer Operation . . . . . . . . . . . . 37 6.8. Get Route Group Offers Operation . . . . . . . . . . . . . 38 6.9. Public Identifier Operations . . . . . . . . . . . . . . . 40 - 6.10. Egress Route Operations . . . . . . . . . . . . . . . . . 44 - 6.11. Add Route Record Operation . . . . . . . . . . . . . . . . 46 - 6.12. Get Route Records Operation . . . . . . . . . . . . . . . 51 - 6.13. Delete Operation . . . . . . . . . . . . . . . . . . . . . 52 - 7. SPPP Examples . . . . . . . . . . . . . . . . . . . . . . . . 53 - 7.1. Add Destination Group . . . . . . . . . . . . . . . . . . 53 - 7.2. Add Route Records . . . . . . . . . . . . . . . . . . . . 54 - 7.3. Add Route Records -- URIType . . . . . . . . . . . . . . . 55 - 7.4. Add Route Group . . . . . . . . . . . . . . . . . . . . . 56 - 7.5. Add Public Identity -- Successful COR claim . . . . . . . 58 - 7.6. Add LRN . . . . . . . . . . . . . . . . . . . . . . . . . 59 - 7.7. Add TN Range . . . . . . . . . . . . . . . . . . . . . . . 60 - 7.8. Add TN Range with Open Number Plan support . . . . . . . . 61 - 7.9. Enable Peering -- Route Group Offer . . . . . . . . . . . 62 - 7.10. Enable Peering -- Route Group Offer Accept . . . . . . . . 64 - 7.11. Add Egress Route . . . . . . . . . . . . . . . . . . . . . 65 - 7.12. Get Destination Group . . . . . . . . . . . . . . . . . . 66 - 7.13. Get Public Identity . . . . . . . . . . . . . . . . . . . 67 - 7.14. Get Route Group Request . . . . . . . . . . . . . . . . . 68 - 7.15. Get Route Group Offers Request . . . . . . . . . . . . . . 69 - 7.16. Get Egree Route . . . . . . . . . . . . . . . . . . . . . 70 - 7.17. Delete Destination Group . . . . . . . . . . . . . . . . . 72 - 7.18. Delete Public Identity . . . . . . . . . . . . . . . . . . 72 - 7.19. Delete Route Group Request . . . . . . . . . . . . . . . . 73 - 7.20. Delete Route Group Offers Request . . . . . . . . . . . . 74 - 7.21. Delete Egress Route . . . . . . . . . . . . . . . . . . . 75 - 8. XML Considerations . . . . . . . . . . . . . . . . . . . . . . 77 - 8.1. Namespaces . . . . . . . . . . . . . . . . . . . . . . . . 77 - 8.2. Versioning and Character Encoding . . . . . . . . . . . . 77 - 9. Security Considerations . . . . . . . . . . . . . . . . . . . 78 - 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 79 - 11. Formal Specification . . . . . . . . . . . . . . . . . . . . . 80 - 12. Specification Extensibility . . . . . . . . . . . . . . . . . 93 - 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 94 - 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 95 - 14.1. Normative References . . . . . . . . . . . . . . . . . . . 95 - 14.2. Informative References . . . . . . . . . . . . . . . . . . 95 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 97 + 6.10. Egress Route Operations . . . . . . . . . . . . . . . . . 45 + 6.11. Add Route Record Operation . . . . . . . . . . . . . . . . 47 + 6.12. Get Route Records Operation . . . . . . . . . . . . . . . 52 + 6.13. Delete Operation . . . . . . . . . . . . . . . . . . . . . 53 + 7. SPPP Examples . . . . . . . . . . . . . . . . . . . . . . . . 54 + 7.1. Add Destination Group . . . . . . . . . . . . . . . . . . 54 + 7.2. Add Route Records . . . . . . . . . . . . . . . . . . . . 55 + 7.3. Add Route Records -- URIType . . . . . . . . . . . . . . . 56 + 7.4. Add Route Group . . . . . . . . . . . . . . . . . . . . . 57 + 7.5. Add Public Identity -- Successful COR claim . . . . . . . 59 + 7.6. Add LRN . . . . . . . . . . . . . . . . . . . . . . . . . 60 + 7.7. Add TN Range . . . . . . . . . . . . . . . . . . . . . . . 61 + 7.8. Add TN Range with Open Number Plan support . . . . . . . . 62 + 7.9. Add TN Prefix . . . . . . . . . . . . . . . . . . . . . . 63 + 7.10. Enable Peering -- Route Group Offer . . . . . . . . . . . 64 + 7.11. Enable Peering -- Route Group Offer Accept . . . . . . . . 66 + 7.12. Add Egress Route . . . . . . . . . . . . . . . . . . . . . 67 + 7.13. Get Destination Group . . . . . . . . . . . . . . . . . . 68 + 7.14. Get Public Identity . . . . . . . . . . . . . . . . . . . 69 + 7.15. Get Route Group Request . . . . . . . . . . . . . . . . . 70 + 7.16. Get Route Group Offers Request . . . . . . . . . . . . . . 71 + 7.17. Get Egree Route . . . . . . . . . . . . . . . . . . . . . 72 + 7.18. Delete Destination Group . . . . . . . . . . . . . . . . . 74 + 7.19. Delete Public Identity . . . . . . . . . . . . . . . . . . 74 + 7.20. Delete Route Group Request . . . . . . . . . . . . . . . . 75 + 7.21. Delete Route Group Offers Request . . . . . . . . . . . . 76 + 7.22. Delete Egress Route . . . . . . . . . . . . . . . . . . . 77 + 8. XML Considerations . . . . . . . . . . . . . . . . . . . . . . 79 + 8.1. Namespaces . . . . . . . . . . . . . . . . . . . . . . . . 79 + 8.2. Versioning and Character Encoding . . . . . . . . . . . . 79 + 9. Security Considerations . . . . . . . . . . . . . . . . . . . 80 + 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 81 + 11. Formal Specification . . . . . . . . . . . . . . . . . . . . . 82 + 12. Specification Extensibility . . . . . . . . . . . . . . . . . 95 + 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 96 + 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 97 + 14.1. Normative References . . . . . . . . . . . . . . . . . . . 97 + 14.2. Informative References . . . . . . . . . . . . . . . . . . 97 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 99 1. Introduction Service providers and enterprises use registries to make call or session routing decisions for Voice over IP, SMS and MMS traffic exchanges. This document is narrowly focused on the provisioning protocol for these registries. This protocol prescribes a way for an entity to provision session-related data into a registry. The data being provisioned can be optionally shared with other participating peering entities. The requirements and use cases driving this @@ -422,50 +423,50 @@ | extension |<----+ rarId, | +----------------------+ | publicIdentifier, | | destGrpRef, | | rteRec, | | extension | +---------------------+ ^ |Various types |of Public |Identifiers... - +------+------------... - | | | - +-----+ +----+ +-----+ - | TN | |TNR | | RN | - +-----+ +----+ +-----+ ... - + +---------+-------+------------... + | | | | + +------+ +-----+ +-----+ +-----+ + | TN | | TNP | | TNR | | RN | + +------+ +-----+ +-----+ +-----+ SPPP Data Model Figure 3 The objects and attributes that comprise the data model can be described as follows (objects listed from the bottom up): o Public Identifier: A public identifier is a well known attribute that is used as the key to perform lookup functions. For the purposes of this document, a Public Identifier can be a telephone number, a range of telephone numbers, a PSTN Routing Number (RN), or perhaps another type of lookup key. - A Public Identifier may be associated with a Destination Group to + A Public Identifier is associated with a Destination Group to create a logical grouping of Public Identifiers that share a common set of Routes. - A Public Identifier may optionally be associated with zero or more - individual Route Records. This ability for a Public Identifier to - be directly associated with a set of Route Records (e.g. target - URI), as opposed to being associated with a Destination Group, - supports the use cases where the target URI contains data - specifically tailored to an individual Public Identifier. + A TN Public Identifier may optionally be associated with zero or + more individual Route Records. This ability for a Public + Identifier to be directly associated with a set of Route Records + (e.g. target URI), as opposed to being associated with a + Destination Group, supports the use cases where the target URI + contains data specifically tailored to an individual TN Public + Identifier. o Telephone Number Range: A public identifier may represent an inclusive range of telephone numbers. The TN range is defined by the first and last telephone number of the inclusive range. For example, a TN range defined by tn=12125550000 and endTn=12125560000 means all the TNs from 12125550000 to 12125560000 inclusive are included. o Destination Group: A name collection of zero or more Public Identifiers that can be @@ -923,21 +925,21 @@ this result set MUST be empty and the overallResult value MUST indicate success (if no matches are found for the query criteria, the response is considered a success). 5.2. Response Codes and Messages This section contains the listing of response codes and their corresponding human-readable text. The response code numbering scheme generally adheres to the theory - formalized in section 4.2.1 of [RFC2821]: + formalized in section 4.2.1 of [RFC5321]: o The first digit of the response code can only be 1 or 2: 1 = a positive result, 2 = a negative result. o The second digit of the response code indicates the category: 0 = Protocol Syntax, 1 = Implementation Specific Business Rule, 2 = Security, 3 = Server System. o The third and fourth digits of the response code indicate the individual message event within the category defines by the @@ -1640,23 +1642,23 @@ establishment data (SED). In many cases, a Public Identifier is attributed to the end user who has a retail relationship with the service provider or registrant organization. In SPPP, SED can be provisioned by the registrant, or by the registrar on behalf of the registrant. Also, SPPP supports the notion of the carrier-of-record as defined in RFC 5067. Therefore, the entity adding the Public Identity in the Registry can optionally claim to be a carrier-of- record. SPPP identifies three types of Public Identifiers: telephone number - (TN), email address, and the routing number (RN). SPPP also supports - the requirement of adding a contiguous range of TNs including the - length variance associated to the Open Number Plan. + (TN), email address, and the routing number (RN). SPPP provides + structures to manage a single TN, a contiguous range of TNs, and a TN + prefix. The XML schema type definition PubIDType is the generalization of the Public Identifier. PubIDType is an abstract type. In agreement with the data model, PubIDType member 'dgName' represents the name of the destination group that a given Public Identifier is associated to. The PubIDType object structure is defined as follows: @@ -1683,29 +1685,29 @@ o tn: Telephone number to be added to the Registry. o rteRecRef: Optional reference to the route record that is directly associated with the TN Public Identifier. Following the SPPP data model, the route record could be a protocol agnostic URIType or another type. o corInfo: corInfo is an optional parameter of type CORInfoType that allows the registrant organization to set forth a claim to be the carrier-of-record [see RFC 5067]. This is done by - setting the element of the CORInfoType object - structure to true. The other two parameters of the CORInfoType, - and are meant to be set by the Registry to - relay the outcome of the carrier-of-record claim by the + setting the value of element of the CORInfoType + object structure to "true". The other two parameters of the + CORInfoType, and are set by the Registry to + describe the outcome of the carrier-of-record claim by the registrant. In general, inclusion of parameter is useful if the Registry has the authority information, such as, - the number portability, etc., in order to qualify whether the - registrant claim can be satisfied. If the carrier-of-record - claim disagrees with the authority data of the Registry, whether + the number portability data, etc., in order to qualify whether + the registrant claim can be satisfied. If the carrier-of-record + claim disagrees with the authority data in the Registry, whether the TN add operation fails or not is a matter of policy and it is beyond the scope of this document. In the response message , the SPPP Server must include the parameter of the element to let the registrant know the outcome of the claim. TNType object definition is as follows: @@ -1740,51 +1742,82 @@ - A contiguous range of TNs is added with the help of TNRType. This - object type includes an optional "prefix" attribute to indicate that - a given TN range qualifies for the Open Number Plan (ONP). In order - to correctly expand the number range that qualifies for Open Number - Plan, the Registry must have the required data about the national - significant number length for the TN prefix included in the TN range - object. If the Registry encounters an error in adding even a single - TN that is part of the TN range, the whole request will be deemed a - failure. In other words, the TNRType add request is transactional in - nature, and the partial success case is not supported. + A contiguous range of TNs is added with the help of TNRType + structure. The object definition requires a starting TN and the + ending TN that describes the TN range. In addition, TNRType includes + an optional "prefix" attribute to indicate that the given TN range + qualifies for the Open Number Plan (ONP). In order to correctly + expand the number range that qualifies for Open Number Plan, the + Registry must have the required data related to the national + significant number length for the TNs in the TN range object. + Further, is transactional in nature, therefore, + if the Registry encounters an error in adding even a single TN of a + TNRType object, the whole request will be deemed a failure. In other + words, the partial success case is not supported. TNRType is composed of the following attributes: - o endTn: The last number in the TN range + o startTn: Starting TN in the TN range - o corInfo: Optional element of type CORInfoType. + o endTn: The last TN in the TN range + + o corInfo: Optional element of type CORInfoType o prefix: Optional attribute, when set to "true", indicates that - the included TN Range falls under the Open Number Plan. + the Open Number Plan applies to a given TN Range - TNRange object structure is as follows: + TNPType object structure is as follows: - + + - + + + + + + + In some cases, it is useful to describe a set of TNs with the help of + the first few digits of the telephone numbers identified as telephone + number prefix. In many instances, the numbering authority assigns TN + prefix, also referred to as a TN block, to a well-known telephony + service provider. In SPPP, the TNPType structure describes a TN + prefix and it consists of the following attributes: + + o tnPrefix: The telephone number prefix + + o corInfo: Optional element of type CORInfoType. + + TNPType object structure is as follows: + + + + + + + + The object structure of AddPubIdRqstType used to add Public Identifiers is as follows @@ -2078,21 +2113,21 @@ The NAPTRType object is composed of the following elements: o order: Order value in an ENUM NAPTR, relative to other NAPTRType objects in the same Route Group. o svcs: ENUM service(s) that are served by the SBE. This field's - value must be of the form specified in RFC 3761 (e.g., E2U+ + value must be of the form specified in [RFC3761] (e.g., E2U+ pstn:sip+sip). The allowable values are a matter of policy and not limited by this protocol. o regx: NAPTR's regular expression field. If this is not included then the Repl field must be included. o repl: NAPTR replacement field, should only be provided if the Regex field is not provided, otherwise it will be ignored by the server. @@ -2205,27 +2241,27 @@ data in the registry and use SPPP constructs to selectively share the route groups. In the figure below, SSP2 has two ingress SBE instances that are associated with the public identities that SSP2 has the retail relationship with. Also, the two SBE instances for SSP1 are used to show how to use SPPP protocol to associate route preferences for the destination ingress routes and exercise greater control on outbound traffic to the peer's ingress SBEs. ---------------+ +------------------ | | - +---------------+ +---------------+ - | sbe1.ssp1.com | | sbe2.ssp2.com | - +---------------+ +---------------+ + +------+ +------+ + | sbe1 | | sbe2 | + +------+ +------+ SSP1 | | SSP2 - +---------------+ +---------------+ - | sbe3.ssp1.com | | sbe4.ssp2.com | - +---------------+ +---------------+ + +------+ +------+ + | sbe3 | | sbe4 | + +------+ +------+ iana-en:111 | | iana-en:222 ---------------+ +------------------ | | | | | SPPP +------------------+ SPPP | +------->| Registry |<--------+ +------------------+ 7.1. Add Destination Group @@ -2282,21 +2318,21 @@ iana-en:222 iana-en:222 RTE_SSP2_SBE2 10 u E2U+sip ^(.*)$ - sip:\1@sbe2.ssp2.com + sip:\1@sbe2.ssp2.example.com The Registry returns a success response. iana-en:222 iana-en:222 RTE_SSP2_SBE4 ^(.*)$ - sip:\1;npdi@sbe4.ssp2.com + sip:\1;npdi@sbe4.ssp2.example.com The Registry returns a success response. iana-en:222 iana-en:222 DEST_GRP_SSP2_1 - +12026660000 + +12026660000 +12026669999 Registry completes the request successfully and returns a favorable response. iana-en:222 iana-en:222 DEST_GRP_SSP2_1 - +4312315566 + +4312315566 +4312315567 Registry completes the request successfully and returns a favorable response. tx_id_12255598 1000 Request successful -7.9. Enable Peering -- Route Group Offer +7.9. Add TN Prefix + + Next, SSP2 activates a block of ten thousand TNs using the TNPType + structure and identifying a TN prefix. + + + + + + iana-en:222 + iana-en:222 + DEST_GRP_SSP2_1 + +1202777 + + + + + Registry completes the request successfully and returns a favorable + response. + + + + tx_id_12387698 + + 1000 + Request successful + + + +7.10. Enable Peering -- Route Group Offer In order for SSP1 to complete session establishment for a destination TN where the target subscriber has a retail relationship with SSP2, it first requires an asynchronous bi-directional handshake to show mutual consent. To start the process, SSP2 initiates the peering handshake by offering SSP1 access to its route group. tx_id_12277798 1000 Request successful -7.10. Enable Peering -- Route Group Offer Accept +7.11. Enable Peering -- Route Group Offer Accept SSP1 responds to the offer from SSP2 and agrees to have visibility to SSP2 ingress routes. @@ -2658,40 +2730,40 @@ xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:ietf:params:xml:ns:sppp:base:1 sppp.xsd" xmlns="urn:ietf:params:xml:ns:sppp:base:1"> tx_id_12333798 1000 success -7.11. Add Egress Route +7.12. Add Egress Route SSP1 wants to prioritize all outbound traffic to routes associated - with "RTE_GRP_SSP2_1" route group through "sbe1.ssp1.com". + with "RTE_GRP_SSP2_1" route group through "sbe1.ssp1.example.com". tx_9000 iana-en:111 EGR_RTE_01 50 ^(.*@)(.*)$ - \1\2?route=sbe1.ssp1.com + \1\2?route=sbe1.ssp1.example.com iana-en:222 SSP2_RTE_REC_3 Since peering has already been established, the request to add the @@ -2704,21 +2776,21 @@ xmlns="urn:ietf:params:xml:ns:sppp:base:1"> tx_9000 tx_id_12388898 1000 Request successful -7.12. Get Destination Group +7.13. Get Destination Group SSP2 uses the 'GetDestGrpsRqstType' operation to tally the last provisioned record for destination group DEST_GRP_SSP2_1. @@ -2741,21 +2813,21 @@ success iana-en:222 iana-en:222 DEST_GRP_SSP2_1 -7.13. Get Public Identity +7.14. Get Public Identity SSP2 obtains the last provisioned record associated with a given TN. DEST_GRP_1 +12025556666 true true 2010-05-30T09:30:10Z -7.14. Get Route Group Request +7.15. Get Route Group Request SSP2 obtains the last provisioned record for the route group RTE_GRP_SSP2_1. @@ -2839,21 +2911,21 @@ RTE_SSP2_SBE4 101 DEST_GRP_SSP2_1 true 10 -7.15. Get Route Group Offers Request +7.16. Get Route Group Offers Request SSP2 choses to fetch the last provisioned route group sharing offer to the SSP1. @@ -2882,21 +2954,21 @@ iana-en:222 RTE_GRP_SSP2_1 iana-en:111 offered 2006-05-04T18:13:51.0Z -7.16. Get Egree Route +7.17. Get Egree Route SSP1 wants to verify the last provisioned record for the egress route called EGR_RTE_01. @@ -2920,30 +2992,30 @@ iana-en:111 iana-en:111 EGR_RTE_01 50 E2U+sip ^(.*)$ - sip:\1@sbe1.ssp1.com + sip:\1@sbe1.ssp1.example.com iana-en:222 RTE_GRP_SSP2_1 -7.17. Delete Destination Group +7.18. Delete Destination Group SSP2 initiates a request to delete the destination group DEST_GRP_SSP2_1. @@ -2961,21 +3033,21 @@ txid-982543123 1000 Success -7.18. Delete Public Identity +7.19. Delete Public Identity SSP2 choses to de-activate the TN and remove it from the Registry. txid-98298273123 1000 success -7.19. Delete Route Group Request +7.20. Delete Route Group Request SSP2 removes the route group called RTE_GRP_SSP2_1. @@ -3025,21 +3097,21 @@ txid-982543123 1000 msg -7.20. Delete Route Group Offers Request +7.21. Delete Route Group Offers Request SSP2 no longer wants to share route group RTE_GRP_SSP2_1 with SSP1. @@ -3061,21 +3133,21 @@ txid-982543123 1000 Success -7.21. Delete Egress Route +7.22. Delete Egress Route SSP1 decides to remove the egress route with the label EGR_RTE_01. @@ -3248,31 +3320,43 @@ - + + + + + + + + + + + + @@ -3770,80 +3849,74 @@ The protocol defined in this specification is extensible. This section explains how to extend the protocol and what procedures are necessary to follow in order to ensure proper extensions. 13. Acknowledgments This document is a result of various discussions held in the DRINKS working group and within the DRINKS protocol design team, which is comprised of the following individuals, in alphabetical order: - Deborah A Guyton (Telcordia), Sumanth Channabasappa (CableLabs), - Jean-Francois Mule (CableLabs), Kenneth Cartwright (TNSI), Manjul - Maharishi (TNSI), David Schwartz (XConnect), and the co-chairs - Richard Shockey and Alexander Mayrhofer (enum.at GmbH). - - The authors of this document thank the following individuals for - their advice, reviews and comments during the development of this - protocol: Lisa Dusseault, "YOUR NAME HERE" -- send comments to drinks - list. + Alexander Mayrhofer, Deborah A Guyton, David Schwartz, Lisa + Dusseault, Manjul Maharishi, Otmar Lendl, Richard Shockey and Sumanth + Channabasappa. 14. References 14.1. Normative References [I-D.ietf-drinks-sppp-over-soap] Cartwright, K., "SPPP Over SOAP and HTTP", draft-ietf-drinks-sppp-over-soap-00 (work in progress), June 2010. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, January 1998. - [RFC2781] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO - 10646", RFC 2781, February 2000. - [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003. [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004. [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005. 14.2. Informative References [I-D.ietf-drinks-usecases-requirements] Channabasappa, S., "DRINKS Use cases and Protocol Requirements", draft-ietf-drinks-usecases-requirements-03 (work in progress), May 2010. - [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, - April 2001. + [RFC2781] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO + 10646", RFC 2781, February 2000. [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [RFC3761] Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)", RFC 3761, April 2004. [RFC4725] Mayrhofer, A. and B. Hoeneisen, "ENUM Validation Architecture", RFC 4725, November 2006. + [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, + October 2008. + [RFC5486] Malas, D. and D. Meyer, "Session Peering for Multimedia Interconnect (SPEERMINT) Terminology", RFC 5486, March 2009. Authors' Addresses Jean-Francois Mule CableLabs 858 Coal Creek Circle Louisville, CO 80027