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

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 of guiding principles for the design of this protocol including extensibility and independent transport definitions, a basic data model that meets some of the requirements discussed in DRINKS, and an XML Schema Document.

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 September 9, 2010.

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 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License.

Table of Contents

1.  Introduction
2.  Terminology
3.  Protocol Definition
    3.1.  Protocol Overview and Layering
    3.2.  Data Model
        3.2.1.  Structure of the SPPP Data Model
        3.2.2.  Data Model Objects and Attributes
        3.2.3.  Applicability of the Data Model for Provisioning of LUF-only data into Registries
        3.2.4.  Applicability of the Data Model for Provisioning of LUF+LRF data into Registries
    3.3.  Common Attributes
        3.3.1.  Common Organization Attributes
        3.3.2.  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

1.  Introduction

Several registries are used by service providers and enterprises on the Internet today to assist them in making 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. The problem space this protocol attempts to solve is: how can entities use a common protocol to provision session-related data into those registries so that their communication peers can query it. Multiple company-proprietary solutions exist with different different data models and protocol operations. The requirements and use cases driving this protocol have been documented in [I‑D.ietf‑drinks‑usecases‑requirements] (Channabasappa, S., “DRINKS Use cases and Protocol Requirements,” March 2010.). The reader is expected to be familiar with the terminology defined in the previously mentioned document.

Three types of provisioning flows have been described in the use case document: client to registry provisioning, registry to local data repository and registry-to-registry. This document addresses a subset (client-to-registry provisioning) by defining a Session Peering Provisioning Protocol (SPPP) for provisioning Session Establishment Data (SED) into a Registry (arrow numbered one in the figure below). While the other "provisioning flows" are shown below as separate message flows, no determination has been made for whether one common baseline protocol could be used for all three, or whether distinct protocols are required.

                         *------------*               *------------*
(1). Provisioning SED    |            | (3).Registry  |            |
-----------------------> |  Registry  |<------------->|  Registry  |
     data into Registries|            |  to Registry  |            |
                         *------------*  exchanges    *------------*
                              /  \                          \
                             /    \                          \
                            /      \                          \
                           /        \                          v
                          /          \                         ...
                         /            \
                        / (2).         \
                       / Distributing   \
                      /      SED         \
                     V                    V
                    +----------+       +----------+
                    |Local Data|       |Local Data|
                    |Repository|       |Repository|
                    +----------+       +----------+

3 Registry Provisioning Flows

The data provisioned for session establishment is typically used by various downstream SIP signaling systems to route a call to the next hop associated with the called domain. These systems typically use a local data store ("Local Data Repository") as their source of session routing information. More specifically, the SED data 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 queries (identifier -> target domain) or for lookup and location resolution (identifier -> target domain -> ingress SBE of terminating SSP). In some cases, the Registry may additionally offer a central query resolution service (not shown in the above figure).

A key requirement for the SPPP protocol is to be able to accommodate two basic scenarios deployed in production today:

1. The Registry only serves for the Look-Up function (LUF) to determine for a given request the target domain to which the request should be routed (as described in [RFC5486] (Malas, D. and D. Meyer, “Session Peering for Multimedia Interconnect (SPEERMINT) Terminology,” March 2009.)). Other means are used by peers to perform the Location Routing Function (LRF) which determines for the returned target domain the actual location of the Signaling Function in that domain.
2. The Registry serves for both the Look-Up function (LUF) and the Location Routing Function (LRF), helping develop the SED data fully.

In terms of protocol design, this document specifies a protocol agnostic to its transport. It provides a description of the data model, the protocol operations including the model for request and responses, and most of the needed protocol commands. Reviews are encourage to determine if the proposed model meets the requirements and to improve or change some of the protocol constructs. The protocol also allows for some extensibility with guidelines to manage such extensibility and to achieve 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 ([I‑D.cartwright‑drinks‑sppp‑over‑soap] (Cartwright, K., “SPPP Over SOAP and HTTP,” March 2010.)), one based on the RESTful Web Services approach (for further study) and a file transfer mechanism for batch mode protocol operations (for further study).

This document is organized as follows:

• Section 3 (Protocol Definition) provides an overview of the SPPP protocol, including the layering approach, functional entities and data model;
• Section 4 (Transport Protocol Requirements) defines requirements for SPPP transport protocols;
• Section 5 (XML Considerations) defines XML considerations that XML parsers must meet to conform to this specification.
• Section 6 (Request and Reply Model) describes the protocol request-reply model;
• Section 8 (Protocol Commands) defines the protocol commands for this version of SPPP, and how to extend them;

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.

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.ietf‑drinks‑usecases‑requirements] (Channabasappa, S., “DRINKS Use cases and Protocol Requirements,” March 2010.) 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.ietf‑drinks‑usecases‑requirements] (Channabasappa, S., “DRINKS Use cases and Protocol Requirements,” March 2010.)). 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.ietf‑drinks‑usecases‑requirements] (Channabasappa, S., “DRINKS Use cases and Protocol Requirements,” March 2010.)).

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.ietf‑drinks‑usecases‑requirements] (Channabasappa, S., “DRINKS Use cases and Protocol Requirements,” March 2010.), 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.

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.

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

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.

3.2.  Data Model

The data model illustrated and described in Figure 3 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.

3.2.1.  Structure of the SPPP Data Model

The logical structure presented below is consistent with the terminology and requirements defined in [I‑D.ietf‑drinks‑usecases‑requirements] (Channabasappa, S., “DRINKS Use cases and Protocol Requirements,” March 2010.). 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
                         |
                +-----------------------+
                |Route Group:           |        +----------------+
                |  registrantOrgName*,  |        |                |
                |  registrarOrgName,    |        | Route Record:  |
                |  rteGrpName*,         |        |  rteRecName*,  |
                |  targetDomain,        +------->|  priority,     |
                |  isInService,         |        |  extension     |
                |  resRecs,             |        |                |
                |  sourceOrgs,          |        +----------------+
                |  sourceIdentLabels,   |            ^
                |  activationDate,      |            |Various types
                |  deletionDate,        |            |of Route
                |  extension            |            |Records...
                |                       |           �
                +-----------------------+           �
                         ^
                         |
               +---------+------------+
               |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,     |   |  publicIdTarget,      |
   |  deletionDate,       |   |                       |
   |  extension           |   |  activationDate,      |
   |                      |   |  deletionDate,        |
   |                      |   |  extension            |
   +----------------------+   +-----------------------+

Second Data Model for SPPP for WG Review

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

3.2.2.  Data Model Objects and Attributes

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

• Public Identifier (publicIdentifier):
  A string of numbers or characters that serves as a public identifier. A Public Identifier may be a telephone number, an email address, a PSTN routing number or other type of identity as deemed appropriate.
  
  The Public Identifier object may be associated with a Destination Group which serves as a logical grouping of identifiers that share a common group 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 routes (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.
• Telephone Number Range (TNRange, tnRangeStart .. tnRangeEnd):
  An object that represents an inclusive range of telephone numbers. The TNRange object must be associated with a Destination Group which indirectly defines the route to reach the TNs in that range.
• Destination Group (destGroupName):
  A collection of zero or more Public Identifiers and Telephone Number ranges (TNRanges) that are related to one or more Route Group relationships.
• Route Group (rteGrpName):
  A Route Group contains a target domain (for Look-Up Function resolutions) and it may contain a collection of Route Record objects that can be used to determine the Location Routing of a SIP route.
  A Route Group can be in or out of service (indicated by isInService). It also contains a list of organizations that can query the object and have access to its content (sourceOrgs and sourceIdentLabels), and an activation and deletion date.
• Source Identity Labels attribute (sourceIdentLabels):
  A character string that identifies the source of a resolution lookup and can be used for source-based routing.
• Route Record of different types (rteRec):
  A collection of route records; the currently defined types are mapped to DNS Resource Records such as NAPTR, NS, TXT, etc.
  A Route Record object represents data that resolution systems use to return a route by building a NAPTR record or a SIP 3xx message. It is associated with a Route Group for routes that are not specific to a public identifier.
  An Route Record object has a name (rteRecName), a priority to help sort out the order of multiple routes (priority can be mapped to NAPTR's order field), and additional elements based on its type.
• Organization (orgName):
  Represents an organization (which can be a registrant, a registrar or an organization that is authorized to view the data such as peer SSPs). A peer preference is also represented (peerPrefs).
  All objects are associated with two organizations to identify the registrant and the registrar.

3.2.3.  Applicability of the Data Model for Provisioning of LUF-only data into Registries

This section provides a read-out of the data model for SPPP clients that only provision data for LUF resolution.

The purpose of LUF data provisioning is to provide the target domain given a destination group. As such, a client provisioning LUF-only data only needs to provide one or more route groups that contain a route group name and a target domain.

Note that source-based routing is supported: depending on what entity requests the look-up resolution (sourceOrgs), a different target domain can be returned by using different Route Groups.

Certain protocol operations could be added in future revisions of this document as "short-cuts" for LUF related data provisioning.

              +-----------------------+
              |Route Group:           |
              |  rteGrpName*,         |
              |  isInService,         |
              |  targetDomain,        |
              |  extension            |
              |                       |
              +-----------------------+
                         ^
                         |
               +---------+------------+
               |Destination           |
               |Group:                |
               |  destGroupName*,     |<----+
               |  routeGrpNames*,     |     |
               |  extension           |     |
               +----------------------+     |
                                            |
                              +-------------+---------+
                              |Public                 |
                              |Identifier:            |
                              |  publicIdentifier*,   |
                              |  destGroupName*,      |
                              |  extension            |
                              +-----------------------+

LUF-only Data Model Example for SPPP for DRINKS WG Review

As an example, a request to add a route group where public identifiers resolve into the target domain ssp1.example.com during look-up resolution would be:

<?xml version="1.0" encoding="UTF-8"?>
<addRteGrpsRqst
       xmlns="urn:ietf:params:xml:ns:sppp:base:1"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation=
       "urn:ietf:params:xml:ns:sppp:base:1
       file:/ietf/example1.xsd">
    <basicRqst>
        <clientTransId>id-12317123</clientTransId>
        <minorVer>20</minorVer>
    </basicRqst>
    <rteGrp>
        <base>
            <rantId>registrantID123</rantId>
            <rarId>registrarId0</rarId>
            <activDate>2010-05-04T18:13:51.0Z</activDate>
            <delDate>2010-05-04T18:13:51.0Z</delDate>
        </base>
        <rteGrpName>route_grp_1</rteGrpName>
        <targetDomain>ssp1.example.com</targetDomain>
        <isInSvc>true</isInSvc>
    </rteGrp>
</addRteGrpsRqst>

3.2.4.  Applicability of the Data Model for Provisioning of LUF+LRF data into Registries

This section provides a read-out of the data model for SPPP clients that provision data for both LUF and LRF resolution.

The purpose of LUF+LRF data provisioning is to provide the target domain given a destination group as well as the location routing for that target domain. As such, a client provisioning LUF+LRF data provides one or more route groups that contain a route group name and a target domain and each route group is associated with a Route Record which can be in the form of a URI, or a DNS resource record (NAPTR, NS or TXT).

              +-----------------------+
              |Route Group:           |        +----------------+
              |  rteGrpName*,         |        |                |
              |  isInService,         |        | Route Record:  |
              |  targetDomain,        +------->|  rteRecName*,  |
              |  extension            |        |  priority,     |
              |                       |        |  extension     |
              +-----------------------+                         |
                         ^                     +----------------+
                         |
               +---------+------------+
               |Destination           |
               |Group:                |
               |  destGroupName*,     |<----+

               |  routeGrpNames*,     |     |
               |  extension           |     |
               +----------------------+     |

                                            |
                              +-------------+---------+
                              |Public                 |
                              |Identifier:            |
                              |  publicIdentifier*,   |
                              |  destGroupName*,      |
                              |  extension            |
                              +-----------------------+

LUF+LRF Data Model Example for SPPP for DRINKS WG Review

As an example, a request to add a route group where public identifiers resolve into the target domain ssp1.example.com and NAPTR associated with that domain based on the source Organization would be:

<?xml version="1.0" encoding="UTF-8"?>
<addRteGrpsRqst
       xmlns="urn:ietf:params:xml:ns:sppp:base:1"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation=
       "urn:ietf:params:xml:ns:sppp:base:1
       file:/ietf/example2.xsd">
    <basicRqst>
        <clientTransId>id-12317123</clientTransId>
        <minorVer>20</minorVer>
    </basicRqst>
    <rteGrp>
        <base>
            <rantId>registrantID123</rantId>
            <rarId>registrarId0</rarId>
            <activDate>2010-05-04T18:13:51.0Z</activDate>
            <delDate>2010-05-04T18:13:51.0Z</delDate>
        </base>
        <rteGrpName>route_grp_1</rteGrpName>
        <targetDomain>ssp1.example.com</targetDomain>
        <isInSvc>true</isInSvc>
        <rteRec xsi:type="NAPTRType" ttl="1000" priority="200">
                <order>10</order>
                <pref>100</pref>
                <flags>u</flags>
                <svcs>E2U+sip</svcs>
                <regx>
                    <ere>^(.*)$</ere>
                    <repl>sip:\1;npdi@sbe34-ssp1.example.com;</repl>
                </regx>
        </rteRec>
        <isInSvc>true</isInSvc>
    </rteGrp>
</addRteGrpsRqst>

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.

3.3.1.  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.

3.3.2.  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.

3.4.  Known Issues and Current Limitations of the Data Model

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

• Some use cases and requirements contained in [I‑D.ietf‑drinks‑usecases‑requirements] (Channabasappa, S., “DRINKS Use cases and Protocol Requirements,” March 2010.) such as Data Recipient Groups and Points of Egress to name a few were left out of scope of this version based on the design team consensus. Some require further discussions to be best addressed in the protocol; other will be added in future revisions of this document.
• The support of the selection of a Route Group for a Public Identifier that belongs to two or more Destination Groups is a known issue. It is required to add some additional atribute(s) to allow the selection of a route group by preference, by the type of route (transit SSP vs. carrier-of-record SSP) or by some other means.
• Parts of the proposed draft XML Schema Definition (XSD) may have to change to accomodate various protocol implementations using SOAP and REST. For example, the way the basic request type is defined in the XSD may not be suitable for REST-like protocols and the atomic XML element definitions for add, delete and get operations on most of objects are not friendly to the RESTful Web Services model that employs PUT, GET, and other HTTP operations for those commands.

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

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.ietf‑drinks‑usecases‑requirements] (Channabasappa, S., “DRINKS Use cases and Protocol Requirements,” March 2010.). 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:

• The ability to establish multiple connections between a client and server may be desirable. If so, we may want to specify the relation of transactions between the various connections.
• Pipelining of requests is required at the SPPP protocol layer. It may have impacts at the transport level that need to be outlined.
• Scope: the current scope of this effort is based upon having a connection oriented transport. Is there any need to support a transport protocol with asynchronous operation?
• If it is required that responses arrive in the order of the requests, this must be specified clearly.

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).

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.

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.

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.

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.

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.

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.

4.8.  Request and Response Correlation

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

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.

4.10.  Mandatory Transport

As of this writing of this revision, one transport protocol proposal has been provided in [I‑D.cartwright‑drinks‑sppp‑over‑soap] (Cartwright, K., “SPPP Over SOAP and HTTP,” March 2010.).

This section will define a mandatory transport protocol to be compliant with this RFC.

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.

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.

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"?>

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.

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:

• clientTransId: The client generated transaction ID that identifies this request for tracking purposes. This value is also echoed back to the client in the response. This value will not be checked for uniqueness.
• minorVer: This identifies the minor version of the SPPP API that the client is attempting to use. This is used in conjunction with the major version identifier in the XML namespace. Refer to the Versioning section of this document for more detail.
• ext: This is the standard extension element for this object. Refer to the Extensibility section of this document for more details.

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:

• clientTransId: The echoed back client transaction ID that explicitly identifies this request for tracking purposes. This value is not guaranteed to be unique.
• serverTransId: The server transaction ID that identifies this request for tracking purposes. This value is guaranteed to be unique.
• resCode: The response code that explicitly identifies the result of the request. See the Response Code section for further details.
• resMsg: The human readable response message that accompanies the response code. See the Response Code section for further details.
• ext: This is the standard extension element for this object. Refer to the Extensibility section for more details.

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.):

• The first digit of the response code can only be 1 or 2: 1 = a positive result, 2 = a negative result.
• The second digit of the response code indicates the category: 0 = Protocol Syntax, 1 = Implementation Specific Business Rule, 2 = Security, 3 = Server System.
• The third and fourth digits of the response code indicate the individual message event within the category defines by the first two digits.

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:

• All parameters within a response message are mandatory and MUST be present. Parameters within a response message MUST NOT be left empty.
• Any value provided for the "attribute name" parameter MUST be an exact element name of the protocol data element that the response message is referring to. For example, allowable values for "attribute name" are "destGrpName", "rteGrpName", etc.
• A value provided for the "command/request type" parameter MUST be an exact request object name that the response message is referring to. For example, an allowable value for "request object name" is "delRteGrpsRqst".
• The value for "attribute value" MUST be the value of the data element to which the preceding "attribute name" refers.
• Result code 2104 SHOULD be used whenever an element value does not adhere to data validation rules.
• Result codes 2104 and 2105 MUST NOT be used interchangeably. Response code 2105 SHOULD be returned when the data element(s) used to uniquely identify a pre-existing object do not exist. If the data elements used to uniquely identify an object are malformed, then response code 2104 SHOULD be returned.

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.

8.1.  List of Protocol Commands

The commands listed below are briefly described - the primary goal of this section in this second revision of the document is to give an overview of the envisioned commands for SPPP. It is noted that some commands are missing and the authors seek the input of the WG for the necessary commands.

By design, the protocol operations are restricted to add, delete and get operations. There is no "update" or "modify" command. It is felt that an "add" operation should be sufficient to update a particular element set.

For an actual business process to be performed, several commands are 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.

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.

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:

• The Destination Group identified by the "destGroupName" attribute of the command must exist. If the Destination group does not exist, an error code (TBD) is to be returned.
• The command must be issued by the registrar that is identified by the "registrarOrgName" of the Destination Group that is being deleted. However, local server policy may override this prerequisite, and grant permission to "foreign" registrars. If delete permission is not granted, the error code (TBD) is to be returned.
• No TNRange object and no Public Identifier object must be associated with the Destination Group to be deleted. If there is a TNRange or a Public Identifier object associated with this Destination Group, the error code (TBD) is to be returned.

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

• The "deletionDate" attribute of the Destination Group is set to the current date.
• The Destination Group object is removed.
• Depending on local server policy, a notify message is sent to the Registrant (identified by the "registrantOrgName" attribute)

The command may return the following response codes: TBD.

This command is not extensible.

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.

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)).

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 minOccurs="0" name="targetDomain" type="string"/>
            <element maxOccurs="unbounded" minOccurs="0" name="rteRec"
            type="spppb:RteRecType"/>
            <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="pubIdtarget" type="spppb:RteRecType"
              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 abstract="true" name="RteRecType">
        <attribute name="rteRecName" type="string"/>
        <attribute default="100" name="priority"
type="positiveInteger"/>
    </complexType>
    <complexType abstract="true" name="RDType">
        <complexContent>
            <extension base="spppb:RteRecType">
                <attribute default="900" name="ttl"
type="positiveInteger"/>
            </extension>
        </complexContent>
    </complexType>
    <complexType name="RegexParamType">
        <sequence>
            <element name="ere" type="string" default="^(.*)$"/>
            <element name="repl" type="string"/>
        </sequence>
    </complexType>
    <complexType name="NAPTRType">
        <complexContent>
            <extension base="spppb:RDType">
                <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="spppb:RegexParamType"
minOccurs="0"/>
                    <element name="repl" type="string" minOccurs="0"/>
                    <element name="ext" type="spppb:ExtAnyType"
minOccurs="0"/>
                </sequence>
            </extension>
        </complexContent>
    </complexType>
    <complexType name="NSType">
        <complexContent>
            <extension base="spppb:RDType">
                <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>
            </extension>
        </complexContent>
    </complexType>
    <complexType name="TXTType">
        <complexContent>
            <extension base="spppb:RDType">
                <sequence>
                    <element name="text" type="string"/>
                </sequence>
            </extension>
        </complexContent>
    </complexType>
    <complexType name="URIType">
        <complexContent>
            <extension base="spppb:RteRecType">
                <sequence>
                    <element name="value" type="string"/>
                    <element name="ext" type="spppb:ExtAnyType"
minOccurs="0"/>
                </sequence>
                <attribute name="ere" default="^(.*)$" type="string"/>
            </extension>
        </complexContent>
    </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>

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.

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.

14.  References

14.1. Normative References

14.2. Informative References

Authors' Addresses