TOC 
DRINKSJ-F. Mule
Internet-DraftCableLabs
Intended status: Standards TrackK. Cartwright
Expires: January 14, 2010TNS
 D. Guyton
 Telcordia Technologies
 A. Mayrhofer
 enum.at GmbH
 July 13, 2009


Session Peering Provisioning Protocol
draft-mule-drinks-proto-01

Status of this Memo

This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79.

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 January 14, 2010.

Copyright Notice

Copyright (c) 2009 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.

Abstract

This document defines a protocol for provisioning session establishment data into Session Data Registries or SIP Service Provider data stores. The provisioned data may then be used by various network elements for session peering. This document focuses on the Session Peering Provisioning Protocol used by clients to provision registries. The document provides a set of guiding principles for the design of this protocol like extensibility and independent transport definitions, a basic data model that meets some of the requirements discussed in DRINKS and an early XML Schema Document.



Table of Contents

1.  Introduction
2.  Terminology
3.  Protocol Definition
    3.1.  Protocol Overview and Layering
    3.2.  Data Model
    3.3.  Common Attributes
        3.3.1.  Extension Attributes
        3.3.2.  Common Organization Attributes
        3.3.3.  Common Attributes for Activation and Deletion Dates
    3.4.  Known Issues and Current Limitations of the Data Model
4.  Transport Protocol Requirements
    4.1.  Connection Oriented
    4.2.  Request & Response Model
    4.3.  Connection Lifetime
    4.4.  Authentication
    4.5.  Confidentiality & Integrity
    4.6.  Near Real Time
    4.7.  Request & Response Sizes
    4.8.  Request and Response Correlation
    4.9.  Request Acknowledgement
    4.10.  Mandatory Transport
5.  XML Considerations
    5.1.  Namespaces
    5.2.  Versioning
6.  Request and Reply Model
    6.1.  Request
    6.2.  Reply
7.  Response Codes and Messages
8.  Protocol Commands
    8.1.  List of Protocol Commands
    8.2.  Example Command Description
        8.2.1.  deleteDestinationGroup
9.  Security Considerations
10.  IANA Considerations
11.  Formal Specification
12.  Specification Extensibility
13.  Acknowledgments
14.  References
    14.1.  Normative References
    14.2.  Informative References
§  Authors' Addresses




 TOC 

1.  Introduction

This document defines a Session Peering Provisioning Protocol (SPPP) for provisioning Session Establishment Data (SED) into a Registry. The SPPP is based on the requirements and use cases compiled in [I‑D.drinks‑usecases‑requirements‑00] (Channabasappa, S., “DRINKS Use cases and Protocol Requirements,” March 2009.).

The SED data is typically used by various systems to route a call to the next hop associated with the called domain's ingress point. More specifically, the SED is the set of parameters that the outgoing signaling path border elements (SBEs) need to initiate the session. See [RFC5486] (Malas, D. and D. Meyer, “Session Peering for Multimedia Interconnect (SPEERMINT) Terminology,” March 2009.) for more details.

The SED is typically created by the terminating SIP Service Provider (SSP) for use by the originating SSP. SED is provisioned into a Registry shared by peer SSPs as part of their service provisioning process. Subsequently, a Registry may distribute the received data into local Data Repositories that can be queried to support session look-up and or session location resolution. In some cases, the Registry may offer a central query resolution service.

This document is intended to specify a protocol that is agnostic to its transport. It provides a description of the data model, the protocol operations including the model for request and responses, and all of the needed protocol commands. The protocol allows for some extensibility with guidelines to manage such extensibility to better support interoperability.

Transport requirements are provided with the intention that each underlying transport protocol will be defined in another document. Current transport protocols under consideration include one based on SOAP, one based on the RESTful Web Services approach and a file transfer mechanism for batch mode protocol operations.

This document is organized as follows:

Future revisions of this Internet-Draft will include a more complete definition of the Session Peering Provisioning Protocol and considerations and changes to make the protocol implementable using SOAP and RESTful Web Services.



 TOC 

2.  Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).

This document reuses terms from [RFC3261] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.), [RFC5486] (Malas, D. and D. Meyer, “Session Peering for Multimedia Interconnect (SPEERMINT) Terminology,” March 2009.), the DRINKS Use Case and Requirements document [I‑D.drinks‑usecases‑requirements‑00] (Channabasappa, S., “DRINKS Use cases and Protocol Requirements,” March 2009.) and the ENUM Validation Architecture [RFC4725] (Mayrhofer, A. and B. Hoeneisen, “ENUM Validation Architecture,” November 2006.).

In addition, this document specifies the following additional terms.

SPPP:
Session Peering Provisioning Protocol, the protocol used to provision data into a Registry (see arrow labeled "1." in Figure 1 of [I‑D.drinks‑usecases‑requirements‑00] (Channabasappa, S., “DRINKS Use cases and Protocol Requirements,” March 2009.)). It is the primary scope of this document.
SPDP:
Session Peering Distribution Protocol, the protocol used to distribute data to Local Data Repository (see arrow labeled "2." in Figure 1 of [I‑D.drinks‑usecases‑requirements‑00] (Channabasappa, S., “DRINKS Use cases and Protocol Requirements,” March 2009.)).
Client:
An application that supports an SPPP Client; it is sometimes referred to as a "Registry Client".
Registry:
The Registry operates a master database of Session Establishment Data for one or more Registrants.
A Registry acts as an SPPP Server.

Registrant:
In this document, we extend the definition of a Registrant based on [RFC4725] (Mayrhofer, A. and B. Hoeneisen, “ENUM Validation Architecture,” November 2006.). The Registrant is the end-user, the person or organization who is the "holder" of the Session Establishment Data being provisioned into the Registry. For example, in [I‑D.drinks‑usecases‑requirements‑00] (Channabasappa, S., “DRINKS Use cases and Protocol Requirements,” March 2009.), a Registrant is pictured as a SIP Service Provider in Figure 2.
A Registrant is identified by its name in the data model.

Registrar:
In this document, we also extend the definition of a Registrar from [RFC4725] (Mayrhofer, A. and B. Hoeneisen, “ENUM Validation Architecture,” November 2006.). A Registrar performs provisioning operations on behalf of a Registrant by interacting with the Registry, in our case via the SPPP protocol defined in this document.
A Registrar is identified by its name in the data model.



 TOC 

3.  Protocol Definition

This section introduces the structure of the data model and provides the information framework for the SPPP protocol. An overview of the protocol operations is first provided with a typical deployment scenario. The data model is then defined along with all the objects manipulated by the protocol and their relationships.



 TOC 

3.1.  Protocol Overview and Layering

SPPP is a simple request/reply protocol that allows a client application to submit provisioning data and query requests to a server. The SPPP data structures are designed to be protocol agnostic. As a result, the underlying transport technology, messaging envelope technology (if any), and the authentication scheme are not limited or defined by this specification. However, refer to the Transport Protocol Requirements section for assumptions that are made about the chosen transport, envelope, and authentication technologies.




          Layer                      Example
     +-------------+      +-----------------------------+
 (5) |Data Objects |      |      RteGrpType, etc.       |
     +-------------+      +-----------------------------+
           |                           |
     +-------------+      +-----------------------------+
 (4) | Operations  |      |    addRteGrpsRqst, etc.     |
     +-------------+      +-----------------------------+
           |                           |
     +-------------+      +-----------------------------+
 (3) |   Message   |      | spppRequest, spppResponse   |
     +-------------+      +-----------------------------+
           |                           |
     +-------------+      +-----------------------------+
 (2) |   Message   |      |   HTTP, SOAP, None, etc.    |
     |   Envelope  |      |                             |
     +-------------+      +-----------------------------+
           |                           |
     +-------------+      +-----------------------------+
 (1) |  Transport  |      |    TCP, TLS, BEEP, etc.     |
     |   Protocol  |      |                             |
     +-------------+      +-----------------------------+

SPPP Layering

 Figure 1 

SPPP can be viewed as a set of layers that collectively define the structure of an SPPP request and response. Layers 3, 4, and 5 are defined within this specification, while layers 1 and 2 are left to separate specifications to allow for potentially multiple SPPP transport, envelope, and authentication technologies.

  1. The transport protocol layer provides a communication mechanism between the client and server. SPPP can be layered over any transport protocol that provides a set of basic requirements defined in the Transport Protocol Requirements section.
  2. The message envelope layer is optional, but can provide features that are above the transport technology layer but below the application messaging layer. Technologies such as HTTP and SOAP are examples of messaging envelope technologies.
  3. The message layer provides a simple, envelope-independent and transport-independent, SPPP wrapper for SPPP request and response messages.
  4. The operation layer defines the set of base SPPP actions that can be invoked using an SPPP message. Operations are encoded using XML encoded actions and objects.
  5. The data object layer defines the base set of SPPP data objects that can be included in update operations or returned in operation responses.



 TOC 

3.2.  Data Model

The data model illustrated and described in Figure 2 defines the logical objects and the relationships between these objects that the SPPP protocol supports. SPPP defines the protocol operations through which an SPPP Client populates a Registry with these logical objects. Various clients belonging to different Registrants and distinct Registrars may use the protocol for populating the Registry's data.

The logical structure presented below is consistent with the terminology and requirements defined in [I‑D.drinks‑usecases‑requirements‑00] (Channabasappa, S., “DRINKS Use cases and Protocol Requirements,” March 2009.). Note that the current version of this data model does not yet address the notion of Data Recipient Groups (left for a future revision of this document).



+-------------+      +------------------+
| all object  |      |Organization:     |
| types       |      |orgName*,         |
+------+------+      |sourceIdentLabels,|
       +------------>|peerPrefs,        |
                     |extension         |
 All objects are     |                  |
 associated with 2   |                  |
 Organizations to    +------------------+
 identify the            ^
 registrant and          |A Route Group is
 the registrar           |associated with
                         |zero or more         +----------------+
                         |Organizations        |NS:             |
                         |                     |  nsName*,      |
              +-----------------------+        |  ipAddrs,      |
              |Route Group:           |        |  extension     |
              |  registrantOrgName*,  +------->|                |
              |  registrarOrgName,    |        |                |
              |  rteGrpName*,         |        +----------------+
              |  isInService,         |
              |  resRecs,             |        +----------------+
              |  sourceOrgs,          |        |NAPTR:          |
              |  sourceIdentLabels,   |        |  order,        |
              |  activationDate,      +------->|  pref,         |
              |  deletionDate,        |        |  flags,        |
              |  extension            |        |  svcs,         |
              |                       |        |  regx,         |
              |                       |        |  repl,         |
              +----------+------------+        |  extension     |
                         ^                     +----------------+
                         |                                  ^
               +---------+------------+                     |
               |Destination           |                     |
               |Group:                |                     |
               |  registrantOrgName*, |                     |
               |  registrarOrgName,   |                     |
               |  destGroupName*,     |                     |
          +--->|  routeGrpNames*,     |<----+               |
          |    |  activationDate,     |     |               |
          |    |  deletionDate,       |     |               |
          |    |  extension           |     |               |
          |    +----------------------+     |               |
          |                                                 |
          | A TNRange is              A Public              |
          | associated                Identifier is         |
          | with only 1               associated            |
          | Destination               with zero or          |
          | Group.                    1 Destination Group.  |
          |                                 |               |
   +----------------------+   +-------------+---------+     |
   |TNRange:              |   |Public                 |     |
   |  registrantOrgName*, |   |Identifier:            |     |
   |  registrarOrgName,   |   |  registrantOrgName*,  |     |
   |  tnRangeStart*,      |   |  registrarOrgName,    |     |
   |  tnRangeEnd*,        |   |  publicIdentifier*,   |     |
   |  destGroupName*,     |   |  destGroupName*,      |     |
   |  activationDate,     |   |  resRecs,             +-----+
   |  deletionDate,       |   |  isRn,                |
   |  extension           |   |  activationDate,      |
   |                      |   |  deletionDate,        |
   |                      |   |  extension            |
   +----------------------+   +-----------------------+

First Data Model for SPPP for WG Review

 Figure 2 

Note that the attributes whose names end with the character * are mandatory attributes.

The objects and attributes that comprise the data model can be described as follows (objects listed from the bottom up):



 TOC 

3.3.  Common Attributes

This section defines common object attributes. The protocol exchanges and operations in SPPP take various parameters. Some of these are common to several objects.



 TOC 

3.3.1.  Extension Attributes

//TODO in a future revision: define the data model extensibility and the use of extension parameters (extension).



 TOC 

3.3.2.  Common Organization Attributes

Two organization roles have been identified in the use cases and in this protocol. A registrant (registrantOrgName) is the organization or business entity that "owns" the object while a registrar is an entity that can provision an object.

//TODO in a future revision: define the roles of organizations in more details and provide details on how they are populated, what organization type can change a record, etc.



 TOC 

3.3.3.  Common Attributes for Activation and Deletion Dates

An object's activation date (activationDate) indicates when the date at which an object becomes active or valid. Prior to that date, the object may be stored in the data repository but queries linked with the object will return responses as if the object did not exist.

An object's deletion date (deletionDate) is the date at which an object is deleted from the data repository.



 TOC 

3.4.  Known Issues and Current Limitations of the Data Model

The data model described in Figure 2 is a preliminary version that does not address the following needs and requirements:


It is expected that future revisions of this document will address some if not all of the limitations or known issues documented above.



 TOC 

4.  Transport Protocol Requirements

This section provides requirements for transport protocols suitable for SPPP. More specifically, this section specifies the services, features, and assumptions that SPPP delegates to the chosen transport and envelope technologies.

Two different groups of use cases are specified in [I‑D.drinks‑usecases‑requirements‑00] (Channabasappa, S., “DRINKS Use cases and Protocol Requirements,” March 2009.). One group of use cases describes the provisioning of data by a client into a Registry (Section 3.1 of the above referenced document), while the other group describes the distribution of data into local data repositories (Section 3.2). The current version of this document focuses on the first set of use cases (client to registry provisioning).

These use cases may involve the provisioning of very small data sets like the modification or update of a single public identifier. Other provisioning operations may deal with huge datasets like the "download" of a whole local number portability database to a Registry.

As a result, a transport protocol for SPPP must be very flexible and accommodate various sizes of data set sizes.

For the reasons outlined above, it is conceivable that provisioning and distributing may use different transport protocols. This document focuses on the provisioning protocol.

A few topics remain open for discussion:



 TOC 

4.1.  Connection Oriented

The SPPP protocol follows a model where a Client establishes a connection to a Server in order to further exchange provisioning transactions over such point-to-point connection. A transport protocol for SPPP MUST therefore be connection oriented.

Note that the role of the "Client" and the "Server" only applies to the connection, and those roles are not related in any way to the type of entity that participates in a protocol exchange. For example, a Registry might also include a "Client" when such a Registry initiates a connection (for example, for data distribution to SSP).



 TOC 

4.2.  Request & Response Model

Provisioning operations in SPPP follow the request - response model, where a transaction is initiated by a Client using a Request command, and the Server responds to the Client by means of a Response.

Multiple subsequent request-response exchanges MAY be performed over a single connection.

Therefore, a transport protocol for SPPP MUST follow the request-response model by allowing a response to be sent to the request initiator.



 TOC 

4.3.  Connection Lifetime

Some use cases involve provisioning a single request to a network element - connections supporting such provisioning requests might be short-lived, and only established on demand.

Other use cases involve either provisioning a huge set of data, or a constant stream of small updates, which would require long-lived connections.

Therefore, a protocol suitable for SPPP SHOULD support short lived as well as long lived connections.



 TOC 

4.4.  Authentication

Many use cases require the Server to authenticate the Client, and potentially also the Client to authenticate the Server. While authentication of the Server by the Client is expected to be used only to prevent impersonation of the Server, authentication of the Client by the Server is expected to be used to identify and further authorize the Client to certain resources on the Server.

Therefore, an SPPP transport protocol MUST provide means for a Server to authenticate and authorize a Client, and MAY provide means for Clients to authenticate a Server.

However, SPPP transport SHOULD also allow for unauthenticated connections.



 TOC 

4.5.  Confidentiality & Integrity

Data that is transported over the protocol is deemed confidential. Therefore, a transport protocol suitable for SPPP MUST ensure confidentiality and integrity protection by providing encryption capabilities.

Additionally, a DRINKS protocol MUST NOT use an unreliable lower-layer transport protocol that does not provide confidentiality and integrity protection.



 TOC 

4.6.  Near Real Time

Many use cases require near real-time responses from the Server. Therefore, a DRINKS transport protocol MUST support near-real-time response to requests submitted by the Client.



 TOC 

4.7.  Request & Response Sizes

SPPP covers a range of use cases - from cases where provisioning a single public identifier will create very small request and response sizes to cases where millions of data records are submitted or retrieved in one transaction. Therefore, a transport protocol suitable for SPPP MUST support a great variety of request and response sizes.

A transport protocol MAY allow splitting large chunks of data into several smaller chunks.



 TOC 

4.8.  Request and Response Correlation

A transport protocol suitable for SPPP MUST allow responses to be correlated with requests.



 TOC 

4.9.  Request Acknowledgement

Data transported in the SPPP protocol is likely crucial for the operation of the communication network that is being provisioned.

Failed transactions can lead to situations where a subset of public identifiers (or even SSPs) might not be reachable, or situations where the provisioning state of the network is inconsistent.

Therefore, a transport protocol for SPPP MUST provide a Response for each Request, so that a Client can identify whether a Request succeeded or failed.



 TOC 

4.10.  Mandatory Transport

//TODO in a future revision: This section will define a mandatory transport protocol to be compliant with this RFC.



 TOC 

5.  XML Considerations

XML serves as the encoding format for SPPP, allowing complex hierarchical data to be expressed in a text format that can be read, saved, and manipulated with both traditional text tools and tools specific to XML.

XML is case sensitive. Unless stated otherwise, XML specifications and examples provided in this document MUST be interpreted in the character case presented to develop a conforming implementation.

This section discusses a small number of XML-related considerations pertaining to SPPP.



 TOC 

5.1.  Namespaces

All SPPP protocol elements are defined in the following namespace:
urn:ietf:params:xml:ns:sppp:base:1

Namespace and schema definitions are used to identify both the base protocol schema and the schemas for managed objects.



 TOC 

5.2.  Versioning

All XML instances SHOULD begin with an <?xml?> declaration to identify the version of XML that is being used, optionally identify use of the character encoding used, and optionally provide a hint to an XML parser that an external schema file is needed to validate the XML instance.

Conformant XML parsers recognize both UTF-8 (defined in [RFC3629] (Yergeau, F., “UTF-8, a transformation format of ISO 10646,” November 2003.)) and UTF-16 (defined in [RFC2781] (Hoffman, P. and F. Yergeau, “UTF-16, an encoding of ISO 10646,” February 2000.)); per [RFC2277] (Alvestrand, H., “IETF Policy on Character Sets and Languages,” January 1998.) UTF-8 is the RECOMMENDED character encoding for use with SPPP.

Character encodings other than UTF-8 and UTF-16 are allowed by XML. UTF-8 is the default encoding assumed by XML in the absence of an "encoding" attribute or a byte order mark (BOM); thus, the "encoding" attribute in the XML declaration is OPTIONAL if UTF-8 encoding is used. SPPP clients and servers MUST accept a UTF-8 BOM if present, though emitting a UTF-8 BOM is NOT RECOMMENDED.

Example XML declarations:

<?xml?> version="1.0" encoding="UTF-8" standalone="no"?>



 TOC 

6.  Request and Reply Model

An SPPP client interacts with an SPPP server by using one of the supported transport mechanisms to send one or more requests to the server and receive corresponding replies from the server. An SPPP request is wrapped within the <spppRequest> element while an SPPP reply is wrapped within an <spppReply> element. Furthermore, fully formed SPPP requests and replies are comprised of constructs required by the chosen transport technology, and the chosen envelope technology. The supported transport technology and envelope technology specifications will be defined in separate documents, and are not discussed here.



 TOC 

6.1.  Request

An SPPP request object, common to any transport and envelope technology, is contained within the generic <spppRequest> element.


                                <element name="spppRequest">
                                         <complexType>
                                                  <sequence>
                                                           <any/>
                                                  </sequence>
                                         </complexType>
                                </element>

Within any <spppRequest> element is the request object specific to the type of object(s) being operated on and the action(s) being performed on that object. For example, the addRteGroupRqst object, used to create Route Groups, that would be passed within an <spppRequest> is defined as follows:


                                <element name="addRteGrpsRqst">
                                   <complexType>
                                    <sequence>
                                      <element name="basicRqst"
                                        type="spppb:BasicRqstType"/>
                                      <element name="rteGrp"
                                        type="spppb:RteGrpType"
                                        maxOccurs="unbounded"/>
                                    </sequence>
                                   </complexType>
                                </element>

All update requests contain a BasicRqstType object. This object is defined as follows:


                                <complexType name="BasicRqstType">
                                 <sequence>
                                  <element name="clientTransId "
                                           type="spppb:TransIdType"/>
                                  <element name="minorVer"
                                           type="spppb:MinorVerType"/>
                                  <element name="ext"
                                           type="spppb:ExtAnyType"
                                           minOccurs="0"/>
                                 </sequence>
                                </complexType>


                                <simpleType name="TransIdType">
                                    <restriction base="string"/>
                                </simpleType>


                                <simpleType name="MinorVerType">
                                    <restriction base="unsignedLong"/>
                                </simpleType>

The data elements within the BasicRqstType object are primarily “house keeping” data elements. They are described as follows:



 TOC 

6.2.  Reply

An SPPP reply object, common to any transport and envelope technology, is contained within the generic <spppReply> element.


                                <element name="spppReply">
                                         <complexType>
                                                  <sequence>
                                                           <any/>
                                                  </sequence>
                                         </complexType>
                                </element>

Within any <spppReply> element is the reply object containing the result of the request. All create, update, and delete operations result in a common response object structure, defined as follows:


<element name="cmnRspns">
   <complexType>
      <sequence>
         <element name="rspns" type="spppb:BasicRspnsType"/>
     </sequence>
   </complexType>
</element>


                                <complexType name="BasicRspnsType">
                                  <sequence>
                                   <element name="clientTransId"
                                                type="TransIdType"/>
                                   <element name="serverTransId"
                                                type="TransIdType"/>
                                   <element name="resCode"
                                                type="int"/>
                                   <element name="resMsg"
                                                type="string"/>
                                   <element name="ext"
                                                type="spppb:ExtAnyType"
                                                minOccurs="0"/>
                                  </sequence>
                                </complexType>

The data elements within the BasicRspnseType object are described as follows:



 TOC 

7.  Response Codes and Messages

This section contains an initial 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] (Klensin, J., “Simple Mail Transfer Protocol,” April 2001.):



Result CodeText
1000 Request Succeeded.
2001 Request syntax invalid.
2002 Request too large.
2003 Version not supported.
2103 Command invalid.
2104 Attribute value invalid: [attribute name]:[attribute value]:[objectType-objectId].
2105 Object does not exist: [attribute name] : [objectType-objectId].
2106 Object status or ownership does not allow for request: [request name]:[ attributeName]:[objectType-objectId].
2301 System temporarily unavailable.
2302 Unexpected internal system or server error.

 Table 1: Response Codes Numbering Scheme and Messages 

Some response messages are "parameterized" with one or more of the following parameters: "attribute name", "attribute value", "objectType-objectId", and "operation name".

The use of these parameters MUST adhere to the following rules:



 TOC 

8.  Protocol Commands

This section provides a preliminary list of SPPP protocol commands.
At this early stage of the protocol development, the commands are only listed with a brief description.

An example of how a complete command description might look is contained in section Section 8.2 (Example Command Description). It is expected that as the protocol commands get more stable, full descriptions will be provided in future revisions.



 TOC 

8.1.  List of Protocol Commands

The commands listed below are briefly described - the primary goal of this section in this revision of the document is to give an overview of the envisioned commands for SPPP.

For an actual business process to be performed, several commandsare being typically combined.

add Route Group (addRteGrpsRqst):
A Route Group" object is created or updated with the attributes given in the command.
del Route Group (delRteGrpsRqst):
A Route Group object is removed. The object must be owned by the client, and must not be refered from other objects.
get Route Group (getRteGrpsRqst):
Returns Attributes of a given Route Group object.
add, delete and get Destination Group (addDestGroupsRqst, delDestGroupsRqst, getDestGroupsRqst):
A Destination Group object is created or updated with the attributes given in the addDestGroupsRqst command; it is deleted with delDestGroupsRqst and its data can be returned using getDestGroupsRqst.
add, delete and get Public Identifier (addPubIdsRqst, delPubIdsRqst, getPubIdsRqst)
add, delete and get TNRange (addTNRsRqst, delTNRsRqst, getTNRsRqst)
Other commands
For this version and to get a list of the additional commands, please refer to the XSD in Section 11 (Formal Specification). Reviewers of this document are invited to provide feedback on the first list of proposed commands.
//TODO in a future revision: add more details as the draft gets more stable.



 TOC 

8.2.  Example Command Description

As outlined above, the preliminary list of commands provides only an overview of the set of possible commands, rather than a full normative specification. This section contains an example of what a full specification could contain. A full specification of all commands supported for v1.0 of SPPP will be provided in a subsequent version of this draft.



 TOC 

8.2.1.  deleteDestinationGroup

delDestGroupsRqst

This command requests the deletion an existing Destination Group object.

Support for this command is REQUIRED in Servers, and RECOMMENDED in Clients.

This command requires a single mandatory attribute, namely the "destGroupName". The value of this attribute is used to identify the Destination Group object instance that is to be deleted.

For the command to succeed, the following prerequisites must be met:

Once the prerequisites are fulfilled, the Registry performs the following actions:

The command may return the following response codes: TBD.

This command is not extensible.



 TOC 

9.  Security Considerations

The transport protocol section contains some security properties that the transport protocol must provide so that authenticated endpoints can exchange data confidentially and with integrity protection.

More details will be provided in a future revision of this document.



 TOC 

10.  IANA Considerations

This document uses URNs to describe XML namespaces and XML schemas conforming to a registry mechanism described in [RFC3688] (Mealling, M., “The IETF XML Registry,” January 2004.).

Two URI assignments are requested.

Registration request for the SPPP XML namespace:
urn:ietf:params:xml:ns:sppp:base:1
Registrant Contact: IESG
XML: None. Namespace URIs do not represent an XML specification.

Registration request for the XML schema:
URI: urn:ietf:params:xml:schema:sppp:1
Registrant Contact: IESG
XML: See the "Formal Specification" section of this document (Section 11 (Formal Specification)).



 TOC 

11.  Formal Specification

This section provides the draft XML Schema Definition for the SPPP protocol. Please read Section 3.4 (Known Issues and Current Limitations of the Data Model) for known issues.




<?xml version="1.0" encoding="UTF-8"?>
<schema xmlns:spppb="urn:ietf:params:xml:ns:sppp:base:1"
    xmlns="http://www.w3.org/2001/XMLSchema"
    targetNamespace="urn:ietf:params:xml:ns:sppp:base:1"
    elementFormDefault="qualified" xml:lang="EN">

    <annotation>
        <documentation>
        ------------------ Object Type Definitions --------------
        </documentation>
    </annotation>
    <complexType name="RteGrpType">
        <sequence>
            <element name="base" type="spppb:BasicObjType"/>
            <element name="rteGrpName" type="string"/>
            <element name="ns" type="spppb:NSType" minOccurs="0"
                        maxOccurs="unbounded"/>

            <element name="naptr" type="spppb:NAPTRType"
                        minOccurs="0" maxOccurs="unbounded"/>

            <element name="peeringOrg" type="spppb:OrgIdType"
                        minOccurs="0" maxOccurs="unbounded"/>

            <element name="sourceIdent" type="spppb:SourceIdentType"
                        minOccurs="0" maxOccurs="unbounded"/>

            <element name="isInSvc" type="boolean"/>
        </sequence>
    </complexType>
    <complexType name="DestGroupType">
        <sequence>
            <element name="base" type="spppb:BasicObjType"/>
            <element name="dgName" type="string"/>
            <element name="rteGrpName" type="string" minOccurs="0"
                        maxOccurs="unbounded"/>
        </sequence>
    </complexType>
    <complexType name="PubIdType">
        <sequence>
            <element name="base" type="spppb:BasicObjType"/>
            <element name="pubId" type="string"/>
            <element name="isRn" type="boolean"/>
            <element name="dgName" type="string" minOccurs="0"/>
            <element name="naptr" type="spppb:NAPTRType" minOccurs="0"
                        maxOccurs="unbounded"/>
        </sequence>
    </complexType>
    <complexType name="TNRType">
        <sequence>
            <element name="base" type="spppb:BasicObjType"/>
            <element name="tnRStrt" type="string"/>
            <element name="tnREnd" type="string"/>
            <element name="dgName" type="string"/>
        </sequence>
    </complexType>
    <complexType name="NAPTRType">
        <sequence>
            <element name="order" type="unsignedShort"/>
            <element name="pref" type="unsignedShort"/>
            <element name="flags" type="string" minOccurs="0"/>
            <element name="svcs" type="string"/>
            <element name="regx" type="string" minOccurs="0"/>
            <element name="repl" type="string" minOccurs="0"/>
            <element name="ext" type="spppb:ExtAnyType" minOccurs="0"/>
        </sequence>
    </complexType>
    <complexType name="NSType">
        <sequence>
            <element name="name" type="string"/>
            <element name="ipAddr" type="spppb:IPAddrType" minOccurs="0"
                        maxOccurs="unbounded"/>
            <element name="ext" type="spppb:ExtAnyType" minOccurs="0"/>
        </sequence>
    </complexType>
    <simpleType name="OrgIdType">
        <restriction base="string"/>
    </simpleType>
    <simpleType name="TransIdType">
        <restriction base="string"/>
    </simpleType>
    <simpleType name="MinorVerType">
        <restriction base="unsignedLong"/>
    </simpleType>
    <complexType name="BasicObjType">
        <sequence>
            <element name="rantId" type="spppb:OrgIdType"/>
            <element name="rarId" type="spppb:OrgIdType"/>
            <element name="activDate" type="dateTime" minOccurs="0"/>
            <element name="delDate" type="dateTime" minOccurs="0"/>
            <element name="ext" type="spppb:ExtAnyType" minOccurs="0"/>
        </sequence>
    </complexType>
    <complexType name="BasicRqstType">
        <sequence>
            <element name="clientTransId" type="spppb:TransIdType"/>
            <element name="minorVer" type="spppb:MinorVerType"/>
            <element name="ext" type="spppb:ExtAnyType" minOccurs="0"/>
        </sequence>
    </complexType>
    <complexType name="BasicQueryType">
        <sequence>
            <element name="minorVer" type="spppb:MinorVerType"/>
            <element name="ext" type="spppb:ExtAnyType" minOccurs="0"/>
        </sequence>
    </complexType>
    <complexType name="BasicRspnsType">
        <sequence>
            <element name="clientTransId" type="spppb:TransIdType"/>
            <element name="serverTransId" type="spppb:TransIdType"/>
            <element name="resCode" type="int"/>
            <element name="resMsg" type="string"/>
            <element name="ext" type="spppb:ExtAnyType" minOccurs="0"/>
        </sequence>
    </complexType>
    <complexType name="IPAddrType">
        <sequence>
            <element name="addr" type="string"/>
            <element name="type" type="spppb:IPType"/>
            <element name="ext" type="spppb:ExtAnyType" minOccurs="0"/>
        </sequence>
    </complexType>
    <simpleType name="IPType">
        <restriction base="token">
            <enumeration value="IPv4"/>
            <enumeration value="IPv6"/>
        </restriction>
    </simpleType>
    <complexType name="SourceIdentType">
        <sequence>
            <element name="sourceIdentLabel" type="string"/>
            <element name="sourceIdentScheme"
                type="spppb:SourceIdentSchemeType"/>
            <element name="ext" type="spppb:ExtAnyType" minOccurs="0"/>
        </sequence>
    </complexType>
    <simpleType name="SourceIdentSchemeType">
        <restriction base="token">
            <enumeration value="URI"/>
            <enumeration value="IP"/>
            <enumeration value="rootDomain"/>
        </restriction>
    </simpleType>
    <complexType name="SvcMenuType">
        <sequence>
            <element name="serverStatus"
                type="spppb:ServerStatusType"/>
            <element name="majMinVersion"
                type="string" maxOccurs="unbounded"/>
            <element name="objURI" type="anyURI"
                maxOccurs="unbounded"/>
            <element name="extURI" type="anyURI"
                minOccurs="0" maxOccurs="unbounded"/>
        </sequence>
    </complexType>
    <simpleType name="ServerStatusType">
        <restriction base="token">
            <enumeration value="inService"/>
            <enumeration value="outOfService"/>
        </restriction>
    </simpleType>
    <complexType name="ExtAnyType">
        <sequence>
            <any namespace="##other" maxOccurs="unbounded"/>
        </sequence>
    </complexType>
    <annotation>
        <documentation>
        -------------- Wrapped Rqst Message Definitions ------------
        </documentation>
    </annotation>
    <element name="addRteGrpsRqst">
        <complexType>
            <sequence>
                <element name="basicRqst" type="spppb:BasicRqstType"/>
                <element name="rteGrp" type="spppb:RteGrpType"
                        maxOccurs="unbounded"/>
            </sequence>
        </complexType>
    </element>
    <element name="delRteGrpsRqst">
        <complexType>
            <sequence>
                <element name="basicRqst" type="spppb:BasicRqstType"/>
                <element name="rantId" type="spppb:OrgIdType"/>
                <element name="name" type="string"/>
            </sequence>
        </complexType>
    </element>
    <element name="getRteGrpsRqst">
        <complexType>
            <sequence>
                <element name="basicRqst" type="spppb:BasicQueryType"/>
                <element name="rantId" type="spppb:OrgIdType"
                                        minOccurs="0"/>
                <element name="name" type="string"/>
            </sequence>
        </complexType>
    </element>
    <element name="addDestGroupsRqst">
        <complexType>
            <sequence>
                <element name="basicRqst"
                                        type="spppb:BasicRqstType"/>
                <element name="destGroup"
                                        type="spppb:DestGroupType"
                        maxOccurs="unbounded"/>
            </sequence>
        </complexType>
    </element>
    <element name="delDestGroupsRqst">
        <complexType>
            <sequence>
                <element name="basicRqst"
                                type="spppb:BasicRqstType"/>
                <element name="rantId"
                                type="spppb:OrgIdType"/>
                <element name="name"
                                type="string"/>
            </sequence>
        </complexType>
    </element>
    <element name="getDestGroupsRqst">
        <complexType>
            <sequence>
                <element name="basicRqst"
                                type="spppb:BasicQueryType"/>
                <element name="rantId"
                                type="spppb:OrgIdType" minOccurs="0"/>
                <element name="name"
                                type="string"/>
            </sequence>
        </complexType>
    </element>
    <element name="addPubIdsRqst">
        <complexType>
            <sequence>
                <element name="basicRqst"
                                type="spppb:BasicRqstType"/>
                <element name="pi" type="spppb:PubIdType"
                                maxOccurs="unbounded"/>
            </sequence>
        </complexType>
    </element>
    <element name="delPubIdsRqst">
        <complexType>
            <sequence>
                <element name="basicRqst"
                                type="spppb:BasicRqstType"/>
                <element name="dgName"
                                type="string"/>
                <element name="publicIdentifier"
                                type="string"/>
            </sequence>
        </complexType>
    </element>
    <element name="getPubIdsRqst">
        <complexType>
            <sequence>
                <element name="basicRqst"
                                type="spppb:BasicQueryType"/>
                <element name="dgName"
                                type="string" minOccurs="0"/>
                <element name="publicIdentifier"
                                type="string"/>
            </sequence>
        </complexType>
    </element>
    <element name="addTNRsRqst">
        <complexType>
            <sequence>
                <element name="basicRqst"
                                type="spppb:BasicRqstType"/>
                <element name="tnR"
                                type="spppb:TNRType"
                                maxOccurs="unbounded"/>
            </sequence>
        </complexType>
    </element>
    <element name="delTNRsRqst">
        <complexType>
            <sequence>
                <element name="basicRqst"
                                type="spppb:BasicRqstType"/>
                <element name="dgName" type="string"/>
                <element name="tnRStrt" type="string"/>
                <element name="tnREnd" type="string"/>
            </sequence>
        </complexType>
    </element>
    <element name="getTNRsRqst">
        <complexType>
            <sequence>
                <element name="basicRqst"
                                type="spppb:BasicQueryType"/>
                <element name="dgName"
                                type="string" minOccurs="0"/>
                <element name="tnRStrt" type="string"/>
                <element name="tnREnd" type="string"/>
            </sequence>
        </complexType>
    </element>
    <element name="getSvcMenuRqst">
        <complexType>
            <sequence>
                <element name="basicRqst"
                                type="spppb:BasicQueryType"/>
            </sequence>
        </complexType>
    </element>
    <annotation>
        <documentation>
        -------- Wrapped Rspns Message Definitions ---------------
        </documentation>
    </annotation>
    <element name="getRteGrpsRspns">
        <complexType>
            <sequence>
                <element name="rteGrp"
                        type="spppb:RteGrpType" minOccurs="0"
                        maxOccurs="unbounded"/>
                <element name="basicResult"
                        type="spppb:BasicRspnsType"/>
            </sequence>
        </complexType>
    </element>
    <element name="getDestGroupsRspns">
        <complexType>
            <sequence>
                <element name="destGroup"
                        type="spppb:DestGroupType" minOccurs="0"
                        maxOccurs="unbounded"/>
                <element name="basicResult"
                        type="spppb:BasicRspnsType"/>
            </sequence>
        </complexType>
    </element>
    <element name="getPubIdsRspns">
        <complexType>
            <sequence>
                <element name="pi"
                        type="spppb:PubIdType" minOccurs="0"
                        maxOccurs="unbounded"/>
                <element name="basicResult"
                        type="spppb:BasicRspnsType"/>
            </sequence>
        </complexType>
    </element>
    <element name="getTNRsRspns">
        <complexType>
            <sequence>
                <element name="tnR" type="spppb:TNRType"
                        minOccurs="0"
                        maxOccurs="unbounded"/>
                <element name="basicResult"
                        type="spppb:BasicRspnsType"/>
            </sequence>
        </complexType>
    </element>
    <element name="getSvcMenuRspns">
        <complexType>
            <sequence>
                <element name="svcMenu"
                        type="spppb:SvcMenuType"/>
                <element name="basicResult"
                        type="spppb:BasicRspnsType"/>
            </sequence>
        </complexType>
    </element>
    <element name="cmnRspns">
        <complexType>
            <sequence>
                <element name="rspns"
                        type="spppb:BasicRspnsType"
                        nillable="false"/>
            </sequence>
        </complexType>
    </element>
    <element name="spppRequest">
        <complexType>
            <sequence>
                <any/>
            </sequence>
        </complexType>
    </element>
    <element name="spppResponse">
        <complexType>
            <sequence>
                <any/>
            </sequence>
        </complexType>
    </element>
</schema>






 TOC 

12.  Specification Extensibility

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.

//TODO in a future revision: add more details as the draft gets more stable.



 TOC 

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), Spencer Dawkins (Huawei Technologies (USA)), 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.



 TOC 

14.  References



 TOC 

14.1. Normative References

[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML).
[RFC2277] Alvestrand, H., “IETF Policy on Character Sets and Languages,” BCP 18, RFC 2277, January 1998 (TXT, HTML, XML).
[RFC2781] Hoffman, P. and F. Yergeau, “UTF-16, an encoding of ISO 10646,” RFC 2781, February 2000 (TXT).
[RFC3629] Yergeau, F., “UTF-8, a transformation format of ISO 10646,” STD 63, RFC 3629, November 2003 (TXT).
[RFC3688] Mealling, M., “The IETF XML Registry,” BCP 81, RFC 3688, January 2004 (TXT).


 TOC 

14.2. Informative References

[I-D.drinks-usecases-requirements-00] Channabasappa, S., “DRINKS Use cases and Protocol Requirements,” draft-ietf-drinks-usecases-requirements-00 (work in progress), March 2009 (HTML).
[RFC2821] Klensin, J., “Simple Mail Transfer Protocol,” RFC 2821, April 2001 (TXT).
[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 (TXT).
[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 (TXT).
[RFC4725] Mayrhofer, A. and B. Hoeneisen, “ENUM Validation Architecture,” RFC 4725, November 2006 (TXT).
[RFC5486] Malas, D. and D. Meyer, “Session Peering for Multimedia Interconnect (SPEERMINT) Terminology,” RFC 5486, March 2009 (TXT).


 TOC 

Authors' Addresses

  Jean-Francois Mule
  CableLabs
  858 Coal Creek Circle
  Louisville, CO 80027
  USA
Email:  jfm@cablelabs.com
  
  Kenneth Cartwright
  TNS
  1939 Roland Clarke Place
  Reston, VA 20191
  USA
Email:  kcartwright@tnsi.com
  
  Debbie Guyton
  Telcordia Technologies
  1 Telcordia Drive/RRC 1E222
  Piscataway, NJ 08854
  USA
Email:  dguyton@telcordia.com
  
  Alexander Mayrhofer
  enum.at GmbH
  Karlsplatz 1/9
  Wien, A-1010
  Austria
Email:  alexander.mayrhofer@enum.at