[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02

DRINKS                                                         J-F. Mule
Internet-Draft                                                 CableLabs
Intended status: Standards Track                           K. Cartwright
Expires: January 14, 2010                                            TNS
                                                               D. Guyton
                                                  Telcordia Technologies
                                                            A. Mayrhofer
                                                            enum.at GmbH
                                                           July 13, 2009


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

Status of this Memo

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

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on January 14, 2010.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.




Mule, et al.            Expires January 14, 2010                [Page 1]


Internet-Draft           draft-mule-drinks-proto               July 2009


Abstract

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







































Mule, et al.            Expires January 14, 2010                [Page 2]


Internet-Draft           draft-mule-drinks-proto               July 2009


Table of Contents

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








Mule, et al.            Expires January 14, 2010                [Page 3]


Internet-Draft           draft-mule-drinks-proto               July 2009


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

   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] for more details.

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

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

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

   This document is organized as follows:

   o    Section 3 provides an overview of the SPPP protocol, including
        the layering approach, functional entities and data model;

   o    Section 4 defines requirements for SPPP transport protocols;

   o    Section 5 defines XML considerations that XML parsers must meet
        to conform to this specification.

   o    Section 6 describes the protocol request-reply model;

   o    Section 8 defines the protocol commands for this version of
        SPPP, and how to extend them;



Mule, et al.            Expires January 14, 2010                [Page 4]


Internet-Draft           draft-mule-drinks-proto               July 2009


   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.















































Mule, et al.            Expires January 14, 2010                [Page 5]


Internet-Draft           draft-mule-drinks-proto               July 2009


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

   This document reuses terms from [RFC3261], [RFC5486], the DRINKS Use
   Case and Requirements document [I-D.drinks-usecases-requirements-00]
   and the ENUM Validation Architecture [RFC4725].

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


   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].  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], 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].  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



Mule, et al.            Expires January 14, 2010                [Page 6]


Internet-Draft           draft-mule-drinks-proto               July 2009


      document.

      A Registrar is identified by its name in the data model.
















































Mule, et al.            Expires January 14, 2010                [Page 7]


Internet-Draft           draft-mule-drinks-proto               July 2009


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

                                 Figure 1



Mule, et al.            Expires January 14, 2010                [Page 8]


Internet-Draft           draft-mule-drinks-proto               July 2009


   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 2 defines the
   logical objects and the relationships between these objects that the
   SPPP protocol supports.  SPPP defines the protocol operations through
   which an SPPP Client populates a Registry with these logical objects.
   Various clients belonging to different Registrants and distinct
   Registrars may use the protocol for populating the Registry's data.

   The logical structure presented below is consistent with the
   terminology and requirements defined in
   [I-D.drinks-usecases-requirements-00].  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,|



Mule, et al.            Expires January 14, 2010                [Page 9]


Internet-Draft           draft-mule-drinks-proto               July 2009


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



Mule, et al.            Expires January 14, 2010               [Page 10]


Internet-Draft           draft-mule-drinks-proto               July 2009


        |  registrantOrgName*, |   |Identifier:            |     |
        |  registrarOrgName,   |   |  registrantOrgName*,  |     |
        |  tnRangeStart*,      |   |  registrarOrgName,    |     |
        |  tnRangeEnd*,        |   |  publicIdentifier*,   |     |
        |  destGroupName*,     |   |  destGroupName*,      |     |
        |  activationDate,     |   |  resRecs,             +-----+
        |  deletionDate,       |   |  isRn,                |
        |  extension           |   |  activationDate,      |
        |                      |   |  deletionDate,        |
        |                      |   |  extension            |
        +----------------------+   +-----------------------+

                  First Data Model for SPPP for WG Review

                                 Figure 2

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

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

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

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

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



Mule, et al.            Expires January 14, 2010               [Page 11]


Internet-Draft           draft-mule-drinks-proto               July 2009


   o  Route Group (rteGrpName):
      A collection of objects that can be used to determine a SIP route
      (for example by resolving the NAPTR record of a Route Group, or
      the domain name of a NAPTR record field, or an NS record).
      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.

   o  Source Identity Labels attribute (sourceIdentLabels):
      A character string that identifies the source of a resolution
      lookup and can be used for source-based routing.

   o  resRecs attribute (resRecs):
      A collection of NS or NAPTR resource records.

   o  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.
      An NS object has a name (nsName) and a set of DNS name server IP
      addresses.

   o  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.
      An NAPTR object has all the fields of a NAPTR record as object
      attributes.

   o  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.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.  Extension Attributes

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




Mule, et al.            Expires January 14, 2010               [Page 12]


Internet-Draft           draft-mule-drinks-proto               July 2009


3.3.2.  Common Organization Attributes

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

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

3.3.3.  Common Attributes for Activation and Deletion Dates

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

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

3.4.  Known Issues and Current Limitations of the Data Model

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

   o  Some use cases and requirements contained in
      [I-D.drinks-usecases-requirements-00] 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.

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

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



Mule, et al.            Expires January 14, 2010               [Page 13]


Internet-Draft           draft-mule-drinks-proto               July 2009


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

















































Mule, et al.            Expires January 14, 2010               [Page 14]


Internet-Draft           draft-mule-drinks-proto               July 2009


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

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

   o  Pipelining of requests is required at the SPPP protocol layer.  It
      may have impacts at the transport level that need to be outlined.

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

   o  If it is required that responses arrive in the order of the
      requests, this must be specified clearly.








Mule, et al.            Expires January 14, 2010               [Page 15]


Internet-Draft           draft-mule-drinks-proto               July 2009


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.



Mule, et al.            Expires January 14, 2010               [Page 16]


Internet-Draft           draft-mule-drinks-proto               July 2009


   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



Mule, et al.            Expires January 14, 2010               [Page 17]


Internet-Draft           draft-mule-drinks-proto               July 2009


   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 in a future revision: This section will define a mandatory
   transport protocol to be compliant with this RFC.









































Mule, et al.            Expires January 14, 2010               [Page 18]


Internet-Draft           draft-mule-drinks-proto               July 2009


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])
   and UTF-16 (defined in [RFC2781]); per [RFC2277] 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"?>







Mule, et al.            Expires January 14, 2010               [Page 19]


Internet-Draft           draft-mule-drinks-proto               July 2009


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>



Mule, et al.            Expires January 14, 2010               [Page 20]


Internet-Draft           draft-mule-drinks-proto               July 2009


   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:

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

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

   o    ext: This is the standard extension element for this object.
        Refer to the Extensibility section of this document for more
        details.



Mule, et al.            Expires January 14, 2010               [Page 21]


Internet-Draft           draft-mule-drinks-proto               July 2009


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>



Mule, et al.            Expires January 14, 2010               [Page 22]


Internet-Draft           draft-mule-drinks-proto               July 2009


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

   o    clientTransId: The echoed back client transaction ID that
        explicitly identifies this request for tracking purposes.  This
        value is not guaranteed to be unique.

   o    serverTransId: The server transaction ID that identifies this
        request for tracking purposes.  This value is guaranteed to be
        unique.

   o    resCode: The response code that explicitly identifies the result
        of the request.  See the Response Code section for further
        details.

   o    resMsg: The human readable response message that accompanies the
        response code.  See the Response Code section for further
        details.

   o    ext: This is the standard extension element for this object.
        Refer to the Extensibility section for more details.






























Mule, et al.            Expires January 14, 2010               [Page 23]


Internet-Draft           draft-mule-drinks-proto               July 2009


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

   o    The first digit of the response code can only be 1 or 2: 1 = a
        positive result, 2 = a negative result.

   o    The second digit of the response code indicates the category: 0
        = Protocol Syntax, 1 = Implementation Specific Business Rule, 2
        = Security, 3 = Server System.

   o    The third and fourth digits of the response code indicate the
        individual message event within the category defines by the
        first two digits.

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

           Table 1: Response Codes Numbering Scheme and Messages



Mule, et al.            Expires January 14, 2010               [Page 24]


Internet-Draft           draft-mule-drinks-proto               July 2009


   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:

   o    All parameters within a response message are mandatory and MUST
        be present.  Parameters within a response message MUST NOT be
        left empty.

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

   o    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".

   o    The value for "attribute value" MUST be the value of the data
        element to which the preceding "attribute name" refers.

   o    Result code 2104 SHOULD be used whenever an element value does
        not adhere to data validation rules.

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




















Mule, et al.            Expires January 14, 2010               [Page 25]


Internet-Draft           draft-mule-drinks-proto               July 2009


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.  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 revision of the document is to give an overview
   of the envisioned commands for SPPP.

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

   add Route Group (addRteGrpsRqst):  A Route Group" object is created
      or updated with the attributes given in the command.

   del Route Group (delRteGrpsRqst):  A Route Group object is removed.
      The object must be owned by the client, and must not be refered
      from other objects.

   get Route Group (getRteGrpsRqst):  Returns Attributes of a given
      Route Group object.

   add, delete and get Destination  Group (addDestGroupsRqst,
   delDestGroupsRqst, getDestGroupsRqst):  A Destination Group object is
      created or updated with the attributes given in the
      addDestGroupsRqst command; it is deleted with delDestGroupsRqst
      and its data can be returned using getDestGroupsRqst.

   add, delete and get Public Identifier (addPubIdsRqst, delPubIdsRqst,
   getPubIdsRqst)

   add, delete and get TNRange (addTNRsRqst, delTNRsRqst, getTNRsRqst)

   Other commands  For this version and to get a list of the additional
      commands, please refer to the XSD in Section 11.  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.



Mule, et al.            Expires January 14, 2010               [Page 26]


Internet-Draft           draft-mule-drinks-proto               July 2009


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:

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

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

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

   o  The "deletionDate" attribute of the Destination Group is set to
      the current date.





Mule, et al.            Expires January 14, 2010               [Page 27]


Internet-Draft           draft-mule-drinks-proto               July 2009


   o  The Destination Group object is removed.

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











































Mule, et al.            Expires January 14, 2010               [Page 28]


Internet-Draft           draft-mule-drinks-proto               July 2009


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.












































Mule, et al.            Expires January 14, 2010               [Page 29]


Internet-Draft           draft-mule-drinks-proto               July 2009


10.  IANA Considerations

   This document uses URNs to describe XML namespaces and XML schemas
   conforming to a registry mechanism described in [RFC3688].

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


































Mule, et al.            Expires January 14, 2010               [Page 30]


Internet-Draft           draft-mule-drinks-proto               July 2009


11.  Formal Specification

   This section provides the draft XML Schema Definition for the SPPP
   protocol.  Please read Section 3.4 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">



Mule, et al.            Expires January 14, 2010               [Page 31]


Internet-Draft           draft-mule-drinks-proto               July 2009


        <sequence>
            <element name="base" type="spppb:BasicObjType"/>
            <element name="pubId" type="string"/>
            <element name="isRn" type="boolean"/>
            <element name="dgName" type="string" minOccurs="0"/>
            <element name="naptr" type="spppb:NAPTRType" minOccurs="0"
                        maxOccurs="unbounded"/>
        </sequence>
    </complexType>
    <complexType name="TNRType">
        <sequence>
            <element name="base" type="spppb:BasicObjType"/>
            <element name="tnRStrt" type="string"/>
            <element name="tnREnd" type="string"/>
            <element name="dgName" type="string"/>
        </sequence>
    </complexType>
    <complexType name="NAPTRType">
        <sequence>
            <element name="order" type="unsignedShort"/>
            <element name="pref" type="unsignedShort"/>
            <element name="flags" type="string" minOccurs="0"/>
            <element name="svcs" type="string"/>
            <element name="regx" type="string" minOccurs="0"/>
            <element name="repl" type="string" minOccurs="0"/>
            <element name="ext" type="spppb:ExtAnyType" minOccurs="0"/>
        </sequence>
    </complexType>
    <complexType name="NSType">
        <sequence>
            <element name="name" type="string"/>
            <element name="ipAddr" type="spppb:IPAddrType" minOccurs="0"
                        maxOccurs="unbounded"/>
            <element name="ext" type="spppb:ExtAnyType" minOccurs="0"/>
        </sequence>
    </complexType>
    <simpleType name="OrgIdType">
        <restriction base="string"/>
    </simpleType>
    <simpleType name="TransIdType">
        <restriction base="string"/>
    </simpleType>
    <simpleType name="MinorVerType">
        <restriction base="unsignedLong"/>
    </simpleType>
    <complexType name="BasicObjType">
        <sequence>
            <element name="rantId" type="spppb:OrgIdType"/>



Mule, et al.            Expires January 14, 2010               [Page 32]


Internet-Draft           draft-mule-drinks-proto               July 2009


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



Mule, et al.            Expires January 14, 2010               [Page 33]


Internet-Draft           draft-mule-drinks-proto               July 2009


    </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>



Mule, et al.            Expires January 14, 2010               [Page 34]


Internet-Draft           draft-mule-drinks-proto               July 2009


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



Mule, et al.            Expires January 14, 2010               [Page 35]


Internet-Draft           draft-mule-drinks-proto               July 2009


            </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>



Mule, et al.            Expires January 14, 2010               [Page 36]


Internet-Draft           draft-mule-drinks-proto               July 2009


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



Mule, et al.            Expires January 14, 2010               [Page 37]


Internet-Draft           draft-mule-drinks-proto               July 2009


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



Mule, et al.            Expires January 14, 2010               [Page 38]


Internet-Draft           draft-mule-drinks-proto               July 2009


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

































Mule, et al.            Expires January 14, 2010               [Page 39]


Internet-Draft           draft-mule-drinks-proto               July 2009


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.











































Mule, et al.            Expires January 14, 2010               [Page 40]


Internet-Draft           draft-mule-drinks-proto               July 2009


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.





































Mule, et al.            Expires January 14, 2010               [Page 41]


Internet-Draft           draft-mule-drinks-proto               July 2009


14.  References

14.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2277]  Alvestrand, H., "IETF Policy on Character Sets and
              Languages", BCP 18, RFC 2277, January 1998.

   [RFC2781]  Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO
              10646", RFC 2781, February 2000.

   [RFC3629]  Yergeau, F., "UTF-8, a transformation format of ISO
              10646", STD 63, RFC 3629, November 2003.

   [RFC3688]  Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
              January 2004.

14.2.  Informative References

   [I-D.drinks-usecases-requirements-00]
              Channabasappa, S., "DRINKS Use cases and Protocol
              Requirements", draft-ietf-drinks-usecases-requirements-00
              (work in progress), March 2009.

   [RFC2821]  Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
              April 2001.

   [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
              A., Peterson, J., Sparks, R., Handley, M., and E.
              Schooler, "SIP: Session Initiation Protocol", RFC 3261,
              June 2002.

   [RFC3761]  Faltstrom, P. and M. Mealling, "The E.164 to Uniform
              Resource Identifiers (URI) Dynamic Delegation Discovery
              System (DDDS) Application (ENUM)", RFC 3761, April 2004.

   [RFC4725]  Mayrhofer, A. and B. Hoeneisen, "ENUM Validation
              Architecture", RFC 4725, November 2006.

   [RFC5486]  Malas, D. and D. Meyer, "Session Peering for Multimedia
              Interconnect (SPEERMINT) Terminology", RFC 5486,
              March 2009.







Mule, et al.            Expires January 14, 2010               [Page 42]


Internet-Draft           draft-mule-drinks-proto               July 2009


Authors' Addresses

   Jean-Francois Mule
   CableLabs
   858 Coal Creek Circle
   Louisville, CO  80027
   USA

   Email: jfm@cablelabs.com


   Kenneth Cartwright
   TNS
   1939 Roland Clarke Place
   Reston, VA  20191
   USA

   Email: kcartwright@tnsi.com


   Debbie Guyton
   Telcordia Technologies
   1 Telcordia Drive/RRC 1E222
   Piscataway, NJ  08854
   USA

   Email: dguyton@telcordia.com


   Alexander Mayrhofer
   enum.at GmbH
   Karlsplatz 1/9
   Wien,   A-1010
   Austria

   Email: alexander.mayrhofer@enum.at















Mule, et al.            Expires January 14, 2010               [Page 43]


Html markup produced by rfcmarkup 1.124, available from https://tools.ietf.org/tools/rfcmarkup/