DRINKS J-F. Mule
Internet-Draft CableLabs
Intended status: Standards Track K. Cartwright
Expires: January 7, 2010 TNS
D. Guyton
Telcordia Technologies
A. Mayrhofer
enum.at GmbH
July 6, 2009
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.
Mule, et al. Expires January 7, 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, 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.
Mule, et al. Expires January 7, 2010 [Page 2]
Internet-Draft draft-mule-drinks-proto July 2009
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Protocol Definition . . . . . . . . . . . . . . . . . . . . . 7
3.1. Protocol Overview . . . . . . . . . . . . . . . . . . . . 7
3.2. Layering . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.3. Data Model . . . . . . . . . . . . . . . . . . . . . . . . 7
3.4. Common Attributes . . . . . . . . . . . . . . . . . . . . 10
3.4.1. Extension Attributes . . . . . . . . . . . . . . . . . 10
3.4.2. Common Organization Attributes . . . . . . . . . . . . 10
3.4.3. Common Attributes for Activation and Deletion Dates . 10
3.5. Known Issues and Current Limitations of the Data Model . . 10
4. Transport Protocol Requirements . . . . . . . . . . . . . . . 12
4.1. Connection Oriented . . . . . . . . . . . . . . . . . . . 13
4.2. Request & Response Model . . . . . . . . . . . . . . . . . 13
4.3. Connection Lifetime . . . . . . . . . . . . . . . . . . . 13
4.4. Authentication . . . . . . . . . . . . . . . . . . . . . . 13
4.5. Confidentiality & Integrity . . . . . . . . . . . . . . . 14
4.6. Near Real Time . . . . . . . . . . . . . . . . . . . . . . 14
4.7. Request & Response Sizes . . . . . . . . . . . . . . . . . 14
4.8. Request and Response Correlation . . . . . . . . . . . . . 14
4.9. Request Acknowledgement . . . . . . . . . . . . . . . . . 14
4.10. Mandatory Transport . . . . . . . . . . . . . . . . . . . 15
5. XML Considerations . . . . . . . . . . . . . . . . . . . . . . 16
5.1. Namespaces . . . . . . . . . . . . . . . . . . . . . . . . 16
5.2. Versioning . . . . . . . . . . . . . . . . . . . . . . . . 16
6. Request and Reply Model . . . . . . . . . . . . . . . . . . . 17
7. Protocol Commands . . . . . . . . . . . . . . . . . . . . . . 18
8. Security Considerations . . . . . . . . . . . . . . . . . . . 19
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
10. Formal Specification . . . . . . . . . . . . . . . . . . . . . 21
11. Specification Extensibility . . . . . . . . . . . . . . . . . 31
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33
13.1. Normative References . . . . . . . . . . . . . . . . . . . 33
13.2. Informative References . . . . . . . . . . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34
Mule, et al. Expires January 7, 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 and one based on the RESTful Wed Services approach.
This document is organized as follows:
o Section 3 and Section 6 describe the SPPP protocol's functional
entities, its layering approach, the extensible data model, and
the request-reply model
o Section 4 defines some requirements to be met for transport
protocols suitable for SPPP,
o Section 7 defines the protocol commands for this version of
SPPP, and how to extend them,
o Section 5 defines XML considerations that XML parsers must meet
to conform to this specification,
Mule, et al. Expires January 7, 2010 [Page 4]
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] (e.g., SIP), [RFC5486]
(e.g., LUF, LRF), 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]). 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]. 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
document
Mule, et al. Expires January 7, 2010 [Page 5]
Internet-Draft draft-mule-drinks-proto July 2009
A Registrar is identified by its name in the data model.
Mule, et al. Expires January 7, 2010 [Page 6]
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
//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]. 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: |
Mule, et al. Expires January 7, 2010 [Page 7]
Internet-Draft draft-mule-drinks-proto July 2009
| | 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, |
Mule, et al. Expires January 7, 2010 [Page 8]
Internet-Draft draft-mule-drinks-proto July 2009
| extension | | activationDate, |
| | | deletionDate, |
| | | extension |
+----------------------+ | |
| |
| |
+-----------------------+
First Data Model for SPPP for WG Review
Figure 1
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.
o 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).
Mule, et al. Expires January 7, 2010 [Page 9]
Internet-Draft draft-mule-drinks-proto July 2009
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.
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.
o 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:
o Some use cases and requirements contained in
[I-D.drinks-usecases-requirements-00] such as Data Recipient
Mule, et al. Expires January 7, 2010 [Page 10]
Internet-Draft draft-mule-drinks-proto July 2009
Groups and Points of Egress to name a few were left out of scope
of this version based on the design team consensus.
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.
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 7, 2010 [Page 11]
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.
TODO: 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 it ok to defer other
asynchronous transport properties?
o If it is required that responses arrive in the order of the
requests, it must be specified clearly.
Mule, et al. Expires January 7, 2010 [Page 12]
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 7, 2010 [Page 13]
Internet-Draft draft-mule-drinks-proto July 2009
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
Mule, et al. Expires January 7, 2010 [Page 14]
Internet-Draft draft-mule-drinks-proto July 2009
succeeded or failed.
4.10. Mandatory Transport
TODO: This section will define a mandatory transport protocol to be
compliant with this RFC.
Mule, et al. Expires January 7, 2010 [Page 15]
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-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])
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 7, 2010 [Page 16]
Internet-Draft draft-mule-drinks-proto July 2009
6. Request and Reply Model
This section will be provided in draft-01 which is intended to be
published before July 13, 2009.
Mule, et al. Expires January 7, 2010 [Page 17]
Internet-Draft draft-mule-drinks-proto July 2009
7. Protocol Commands
This section will be provided in draft-01 which is intended to be
published before July 13, 2009.
Mule, et al. Expires January 7, 2010 [Page 18]
Internet-Draft draft-mule-drinks-proto July 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.
Mule, et al. Expires January 7, 2010 [Page 19]
Internet-Draft draft-mule-drinks-proto July 2009
9. 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 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).
Mule, et al. Expires January 7, 2010 [Page 20]
Internet-Draft draft-mule-drinks-proto July 2009
10. Formal Specification
This section provides the draft XML Schema Definition for the SPPP
protocol. Please read Section 3.5 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">
Mule, et al. Expires January 7, 2010 [Page 21]
Internet-Draft draft-mule-drinks-proto July 2009
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"/>
Mule, et al. Expires January 7, 2010 [Page 22]
Internet-Draft draft-mule-drinks-proto July 2009
<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"/>
Mule, et al. Expires January 7, 2010 [Page 23]
Internet-Draft draft-mule-drinks-proto July 2009
<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>
Mule, et al. Expires January 7, 2010 [Page 24]
Internet-Draft draft-mule-drinks-proto July 2009
</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"/>
Mule, et al. Expires January 7, 2010 [Page 25]
Internet-Draft draft-mule-drinks-proto July 2009
</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">
Mule, et al. Expires January 7, 2010 [Page 26]
Internet-Draft draft-mule-drinks-proto July 2009
<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" >
Mule, et al. Expires January 7, 2010 [Page 27]
Internet-Draft draft-mule-drinks-proto July 2009
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>
Mule, et al. Expires January 7, 2010 [Page 28]
Internet-Draft draft-mule-drinks-proto July 2009
</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>
Mule, et al. Expires January 7, 2010 [Page 29]
Internet-Draft draft-mule-drinks-proto July 2009
<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>
Mule, et al. Expires January 7, 2010 [Page 30]
Internet-Draft draft-mule-drinks-proto July 2009
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.
Mule, et al. Expires January 7, 2010 [Page 31]
Internet-Draft draft-mule-drinks-proto July 2009
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.
Mule, et al. Expires January 7, 2010 [Page 32]
Internet-Draft draft-mule-drinks-proto July 2009
13. References
13.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.
13.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.
[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 7, 2010 [Page 33]
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 7, 2010 [Page 34]