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

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 7, 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, data that 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.

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.

Table of Contents

1.  Introduction
2.  Terminology
3.  Protocol Definition
    3.1.  Protocol Overview
    3.2.  Layering
    3.3.  Data Model
    3.4.  Common Attributes
        3.4.1.  Extension Attributes
        3.4.2.  Common Organization Attributes
        3.4.3.  Common Attributes for Activation and Deletion Dates
    3.5.  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
7.  Protocol Commands
8.  Security Considerations
9.  IANA Considerations
10.  Formal Specification
11.  Specification Extensibility
12.  Acknowledgments
13.  References
    13.1.  Normative References
    13.2.  Informative References
§  Authors' Addresses

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 and one based on the RESTful Wed Services approach.

This document is organized as follows:

• Section 3 (Protocol Definition) and Section 6 (Request and Reply Model) describe the SPPP protocol's functional entities, its layering approach, the extensible data model, and the request-reply model
• Section 4 (Transport Protocol Requirements) defines some requirements to be met for transport protocols suitable for SPPP,
• Section 7 (Protocol Commands) defines the protocol commands for this version of SPPP, and how to extend them,
• Section 5 (XML Considerations) defines XML considerations that XML parsers must meet to conform to this specification,

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.) (e.g., SIP), [RFC5486] (Malas, D. and D. Meyer, “Session Peering for Multimedia Interconnect (SPEERMINT) Terminology,” March 2009.) (e.g., LUF, LRF), 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.)). It is presently left out of scope of this document.

Registry Client:

An SPPP 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.

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

//TODO

3.2.  Layering

//TODO

3.3.  Data Model

The data model illustrated and described in Figure 1 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  |      |                  |
| types       |      |Organization:     |
|             |      |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                Identify 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

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

• 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 NAPTR records. This ability for a Public Identifier to be directly associated with a set of NAPTRs, as opposed to being associated with a Destination Group, supports the use cases where the NAPTR may contain 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 collection of objects that can be used to determine a SIP route (for example the NAPTR record, or by using the domain name of a NAPTR record field, or an NS record).
• source Identity Labels attribute (sourceIdentLabels): A character string that identifies the source of a resolution lookup and can be used for source-based routing.
• resRecs attribute (resRecs): A collection of NS or NAPTR resource records.
• NS (nsName): An NS object is representing the data structure of a DNS NS record. It is associated with a Route Group for routes that can be resolved through a subsequent DNS resolution.
• NAPTR: A NAPTR object is representing the data structure of a NAPTR record. It is associated with a Route Group for routes that are not specific to a public identifier.
• Organization (orgName): a registrant or registrar organization.

3.4.  Common Attributes

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

3.4.1.  Extension Attributes

//TODO: define the data model extensibility and the use of extension parameters.

3.4.2.  Common Organization Attributes

//TODO: define the roles of organizations, describe registrantOrgName, registrarOrgName parameters and provide details on how they are populated, what organization type can change a record, etc.

3.4.3.  Common Attributes for Activation and Deletion Dates

//TODO: define the activationDate, deletionDate parameters and provide one or two examples, etc.

3.5.  Known Issues and Current Limitations of the Data Model

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

• Some use cases and requirements contained in [I‑D.drinks‑usecases‑requirements‑00] (Channabasappa, S., “DRINKS Use cases and Protocol Requirements,” March 2009.) 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.
• 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.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.

TODO: 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 it ok to defer other asynchronous transport properties?
• If it is required that responses arrive in the order of the requests, it 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 for a Server to authenticate/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 as well as ensure completeness of the data. Therefore, a DRINKS protocol MUST NOT use an unreliable lower-layer transport protocol.

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

DRINKS covers a range of use cases - from cases where provisioning a single public identifier is expected to create very small request and response sizes to cases where millions of data records are submitted / 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 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

TODO: 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-1.0

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

This section will be provided in draft-01 which is intended to be published before July 13, 2009.

7.  Protocol Commands

This section will be provided in draft-01 which is intended to be published before July 13, 2009.

8.  Security Considerations

The transport protocol section contains some security properties that the transport protocol must provide so that the data exchanged using SPPP can be confidential and exchanged between authenticated endpoints.

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

9.  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 extension namespace:
urn:ietf:params:xml:ns:sppp-1.0
Registrant Contact: IESG
XML: None. Namespace URIs do not represent an XML specification.

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

10.  Formal Specification

This section provides the draft XML Schema Definition for the SPPP protocol. Please read Section 3.5 (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="unsignedLong"/>
   </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="BasicRspnsType">
      <sequence>
         <element name="resCode" type="int"/>
         <element name="resMsg" type="string"/>
         <element name="ext" type="spppb:ExtAnyType"
         minOccurs="0"/>
      </sequence>
   </complexType>
   <complexType name="BasicRqstType">
      <sequence>
         <element name="clientId" type="spppb:OrgIdType"/>
         <element name="transId" 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="clientId" type="spppb:OrgIdType"/>
         <element name="minorVer" type="spppb:MinorVerType"/>
         <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="BatchUpdateType">
      <sequence>
         <element name="op" type="spppb:BatchOpType"
         maxOccurs="unbounded"/>
      </sequence>
   </complexType>
   <complexType name="BatchOpType">
      <sequence>
         <element name="rteGrpDel" type="string"
         minOccurs="0" maxOccurs="unbounded"/>
         <element name="rteGrpAdd" type="spppb:RteGrpType"
         minOccurs="0" maxOccurs="unbounded"/>
         <element name="destGrpDel" type="string" minOccurs="0>
" maxOccurs="unbounded"/>
         <element name="destGrpAdd" type="spppb:DestGroupType"
         minOccurs="0" maxOccurs="unbounded"/>
         <element name="piDel" type="string" minOccurs="0">
 maxOccurs="unbounded"/>
         <element name="piAdd" type="spppb:PubIdType"
         minOccurs="0" maxOccurs="unbounded"/>
         <element name="tnRDel" type="string" minOccurs="0">
 maxOccurs="unbounded"/>
         <element name="tnRAdd" type="spppb:TNRType"
         minOccurs="0" maxOccurs="unbounded"/>
      </sequence>
   </complexType>
   <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="name" type="string" maxOccurs="unbounded"/>
         </sequence>
      </complexType>
   </element>
   <element name="getRteGrpsRqst">
      <complexType>
         <sequence>
            <element name="basicRqst" type="spppb:BasicQueryType"/>
            <element name="name" type="string" maxOccurs="unbounded"/>
         </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="name" type="string" maxOccurs="unbounded"/>
         </sequence>
      </complexType>
   </element>
   <element name="getDestGroupsRqst">
      <complexType>
         <sequence>
            <element name="basicRqst" type="spppb:BasicQueryType"/>
            <element name="name" type="string" maxOccurs="unbounded"/>
         </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="name" type="string">
 maxOccurs="unbounded"/>
         </sequence>
      </complexType>
   </element>
   <element name="getPubIdsRqst">
      <complexType>
         <sequence>
            <element name="basicRqst" type="spppb:BasicQueryType"/>
            <element name="name" type="string">
 maxOccurs="unbounded"/>
         </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="name" type="string">
 maxOccurs="unbounded"/>
         </sequence>
      </complexType>
   </element>
   <element name="getTNRsRqst">
      <complexType>
         <sequence>
            <element name="basicRqst" type="spppb:BasicQueryType"/>
            <element name="name" type="string" maxOccurs="unbounded"/>
         </sequence>
      </complexType>
   </element>
   <element name="addNAPTRsRqst">
      <complexType>
         <sequence>
            <element name="basicRqst" type="spppb:BasicRqstType"/>
            <element name="naptr" type="spppb:NAPTRType">
 maxOccurs="unbounded"/>
         </sequence>
      </complexType>
   </element>
   <element name="delNAPTRsRqst">
      <complexType>
         <sequence>
            <element name="basicRqst" type="spppb:BasicRqstType"/>
            <element name="name" type="string">
 maxOccurs="unbounded"/>
         </sequence>
      </complexType>
   </element>
   <element name="getNAPTRsRqst">
      <complexType>
         <sequence>
            <element name="basicRqst" type="spppb:BasicQueryType"/>
            <element name="name" type="string" >
maxOccurs="unbounded"/>
         </sequence>
      </complexType>
   </element>
   <element name="addNSsRqst">
      <complexType>
         <sequence>
            <element name="basicRqst" type="spppb:BasicRqstType"/>
            <element name="naptr" type="spppb:NSType">
 maxOccurs="unbounded"/>
         </sequence>
      </complexType>
   </element>
   <element name="delNSsRqst">
      <complexType>
         <sequence>
            <element name="basicRqst" type="spppb:BasicRqstType"/>
            <element name="name" type="string" maxOccurs="unbounded"/>
         </sequence>
      </complexType>
   </element>
   <element name="getNSsRqst">
      <complexType>
         <sequence>
            <element name="basicRqst" type="spppb:BasicQueryType"/>
            <element name="name" type="string" maxOccurs="unbounded"/>
         </sequence>
      </complexType>
   </element>
   <element name="batchUpdateRqst">
      <complexType>
         <sequence>
            <element name="basicRqst" type="spppb:BasicRqstType"/>
            <element name="batchUpdate" type="spppb:BatchUpdateType"/>
         </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="getNAPTRsRspns">
      <complexType>
         <sequence>
            <element name="naptr" type="spppb:NAPTRType">
 minOccurs="0" maxOccurs="unbounded"/>
            <element name="basicResult" type="spppb:BasicRspnsType"/>
         </sequence>
      </complexType>
   </element>
   <element name="getNSsRspns">
      <complexType>
         <sequence>
            <element name="ns" type="spppb:NSType">
 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>

11.  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: add more details as the draft gets more stable.

12.  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, and the co-chairs Richard Shockey and Alexander Mayrhofer (enum.at GmbH).

The authors of this document thank the following individuals for their advise, reviews and comments during the development of this protocol: Lisa Dusseault, "YOUR NAME HERE" -- send comments to drinks list.

13.  References

13.1. Normative References

13.2. Informative References

Authors' Addresses