One document matched: draft-mule-drinks-proto-02.txt
Differences from draft-mule-drinks-proto-01.txt
DRINKS J-F. Mule
Internet-Draft CableLabs
Intended status: Standards Track K. Cartwright
Expires: September 9, 2010 TNS
S. Ali
NeuStar
A. Mayrhofer
enum.at GmbH
D. Guyton
Telcordia Technologies
March 8, 2010
Session Peering Provisioning Protocol
draft-mule-drinks-proto-02
Abstract
This document defines a protocol for provisioning session
establishment data into Session Data Registries and SIP Service
Provider data stores. The provisioned data is typically used by
various network elements for session peering.
This document describes the Session Peering Provisioning Protocol
used by clients to provision registries. The document provides a set
of guiding principles for the design of this protocol including
extensibility and independent transport definitions, a basic data
model that meets some of the requirements discussed in DRINKS, and an
XML Schema Document.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
Mule, et al. Expires September 9, 2010 [Page 1]
Internet-Draft draft-mule-drinks-proto March 2010
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 9, 2010.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.
Mule, et al. Expires September 9, 2010 [Page 2]
Internet-Draft draft-mule-drinks-proto March 2010
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . intro
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . Termi
3. Protocol Definition . . . . . . . . . . . . . . . . . . . . proto
3.1. Protocol Overview and Layering . . . . . . . . . . . . proto
3.2. Data Model . . . . . . . . . . . . . . . . . . . . . . datam
3.2.1. Structure of the SPPP Data Model . . . . . . . . . datam
3.2.2. Data Model Objects and Attributes . . . . . . . . . DataM
3.2.3. Applicability of the Data Model for Provisioning
of LUF-only data into Registries . . . . . . . . . DataM
3.2.4. Applicability of the Data Model for Provisioning
of LUF+LRF data into Registries . . . . . . . . . . DataM
3.3. Common Attributes . . . . . . . . . . . . . . . . . . . commo
3.3.1. Common Organization Attributes . . . . . . . . . . commo
3.3.2. Common Attributes for Activation and Deletion Dates commo
3.4. Known Issues and Current Limitations of the Data Model openi
4. Transport Protocol Requirements . . . . . . . . . . . . . . trans
4.1. Connection Oriented . . . . . . . . . . . . . . . . . . trans
4.2. Request & Response Model . . . . . . . . . . . . . . . reque
4.3. Connection Lifetime . . . . . . . . . . . . . . . . . . conne
4.4. Authentication . . . . . . . . . . . . . . . . . . . . authe
4.5. Confidentiality & Integrity . . . . . . . . . . . . . . confi
4.6. Near Real Time . . . . . . . . . . . . . . . . . . . . timin
4.7. Request & Response Sizes . . . . . . . . . . . . . . . resps
4.8. Request and Response Correlation . . . . . . . . . . . reqor
4.9. Request Acknowledgement . . . . . . . . . . . . . . . . ack
4.10. Mandatory Transport . . . . . . . . . . . . . . . . . . manda
5. XML Considerations . . . . . . . . . . . . . . . . . . . . xmlco
5.1. Namespaces . . . . . . . . . . . . . . . . . . . . . . names
5.2. Versioning . . . . . . . . . . . . . . . . . . . . . . versi
6. Request and Reply Model . . . . . . . . . . . . . . . . . . Reque
6.1. Request . . . . . . . . . . . . . . . . . . . . . . . . reque
6.2. Reply . . . . . . . . . . . . . . . . . . . . . . . . . reply
7. Response Codes and Messages . . . . . . . . . . . . . . . . resul
8. Protocol Commands . . . . . . . . . . . . . . . . . . . . . proto
8.1. List of Protocol Commands . . . . . . . . . . . . . . . comma
8.2. Example Command Description . . . . . . . . . . . . . . comma
8.2.1. deleteDestinationGroup . . . . . . . . . . . . . . Delet
9. Security Considerations . . . . . . . . . . . . . . . . . . secur
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . IANA
11. Formal Specification . . . . . . . . . . . . . . . . . . . forma
12. Specification Extensibility . . . . . . . . . . . . . . . . speci
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . ancho
14. References . . . . . . . . . . . . . . . . . . . . . . . . ancho
14.1. Normative References . . . . . . . . . . . . . . . . . ancho
14.2. Informative References . . . . . . . . . . . . . . . . ancho
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 0
Mule, et al. Expires September 9, 2010 [Page 3]
Internet-Draft draft-mule-drinks-proto March 2010
1. Introduction
Several registries are used by service providers and enterprises on
the Internet today to assist them in making call or session routing
decisions for Voice over IP, SMS and MMS traffic exchanges.
This document is narrowly focused on the provisioning protocol for
these registries. The problem space this protocol attempts to solve
is: how can entities use a common protocol to provision session-
related data into those registries so that their communication peers
can query it. Multiple company-proprietary solutions exist with
different different data models and protocol operations. The
requirements and use cases driving this protocol have been documented
in [I-D.ietf-drinks-usecases-requirements]. The reader is expected
to be familiar with the terminology defined in the previously
mentioned document.
Three types of provisioning flows have been described in the use case
document: client to registry provisioning, registry to local data
repository and registry-to-registry. This document addresses a
subset (client-to-registry provisioning) by defining a Session
Peering Provisioning Protocol (SPPP) for provisioning Session
Establishment Data (SED) into a Registry (arrow numbered one in the
figure below). While the other "provisioning flows" are shown below
as separate message flows, no determination has been made for whether
one common baseline protocol could be used for all three, or whether
distinct protocols are required.
Mule, et al. Expires September 9, 2010 [Page 4]
Internet-Draft draft-mule-drinks-proto March 2010
*------------* *------------*
(1). Provisioning SED | | (3).Registry | |
-----------------------> | Registry |<------------->| Registry |
data into Registries| | to Registry | |
*------------* exchanges *------------*
/ \ \
/ \ \
/ \ \
/ \ v
/ \ ...
/ \
/ (2). \
/ Distributing \
/ SED \
V V
+----------+ +----------+
|Local Data| |Local Data|
|Repository| |Repository|
+----------+ +----------+
3 Registry Provisioning Flows
Figure 1
The data provisioned for session establishment is typically used by
various downstream SIP signaling systems to route a call to the next
hop associated with the called domain. These systems typically use a
local data store ("Local Data Repository") as their source of session
routing information. More specifically, the SED data is the set of
parameters that the outgoing signaling path border elements (SBEs)
need to initiate the session. See [RFC5486] for more details.
The SED is typically created by the terminating SIP Service Provider
(SSP) for use by the originating SSP. SED is provisioned into a
Registry shared by peer SSPs as part of their service provisioning
process. Subsequently, a Registry may distribute the received data
into local Data Repositories that can be queried to support session
look-up queries (identifier -> target domain) or for lookup and
location resolution (identifier -> target domain -> ingress SBE of
terminating SSP). In some cases, the Registry may additionally offer
a central query resolution service (not shown in the above figure).
A key requirement for the SPPP protocol is to be able to accommodate
two basic scenarios deployed in production today:
1. The Registry only serves for the Look-Up function (LUF) to
determine for a given request the target domain to which the
Mule, et al. Expires September 9, 2010 [Page 5]
Internet-Draft draft-mule-drinks-proto March 2010
request should be routed (as described in [RFC5486]). Other
means are used by peers to perform the Location Routing Function
(LRF) which determines for the returned target domain the actual
location of the Signaling Function in that domain.
2. The Registry serves for both the Look-Up function (LUF) and the
Location Routing Function (LRF), helping develop the SED data
fully.
In terms of protocol design, this document specifies a protocol
agnostic to its transport. It provides a description of the data
model, the protocol operations including the model for request and
responses, and most of the needed protocol commands. Reviews are
encourage to determine if the proposed model meets the requirements
and to improve or change some of the protocol constructs. The
protocol also allows for some extensibility with guidelines to manage
such extensibility and to achieve interoperability.
Transport requirements are provided with the intention that each
underlying transport protocol will be defined in another document.
Current transport protocols under consideration include one based on
SOAP ([I-D.cartwright-drinks-sppp-over-soap]), one based on the
RESTful Web Services approach (for further study) and a file transfer
mechanism for batch mode protocol operations (for further study).
This document is organized as follows:
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;
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 September 9, 2010 [Page 6]
Internet-Draft draft-mule-drinks-proto March 2010
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.ietf-drinks-usecases-requirements] 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.ietf-drinks-usecases-requirements]). It is the primary
scope of this document.
SPDP: Session Peering Distribution Protocol, the protocol used to
distribute data to Local Data Repository (see arrow labeled "2."
in Figure 1 of [I-D.ietf-drinks-usecases-requirements]).
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.ietf-drinks-usecases-requirements], a Registrant
is pictured as a SIP Service Provider in Figure 2.
A Registrant is identified by its name in the data model.
Mule, et al. Expires September 9, 2010 [Page 7]
Internet-Draft draft-mule-drinks-proto March 2010
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.
A Registrar is identified by its name in the data model.
Mule, et al. Expires September 9, 2010 [Page 8]
Internet-Draft draft-mule-drinks-proto March 2010
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 2
Mule, et al. Expires September 9, 2010 [Page 9]
Internet-Draft draft-mule-drinks-proto March 2010
SPPP can be viewed as a set of layers that collectively define the
structure of an SPPP request and response. Layers 3, 4, and 5 are
defined within this specification, while layers 1 and 2 are left to
separate specifications to allow for potentially multiple SPPP
transport, envelope, and authentication technologies.
1. The transport protocol layer provides a communication mechanism
between the client and server. SPPP can be layered over any
transport protocol that provides a set of basic requirements
defined in the Transport Protocol Requirements section.
2. The message envelope layer is optional, but can provide features
that are above the transport technology layer but below the
application messaging layer. Technologies such as HTTP and SOAP
are examples of messaging envelope technologies.
3. The message layer provides a simple, envelope-independent and
transport-independent, SPPP wrapper for SPPP request and response
messages.
4. The operation layer defines the set of base SPPP actions that can
be invoked using an SPPP message. Operations are encoded using
XML encoded actions and objects.
5. The data object layer defines the base set of SPPP data objects
that can be included in update operations or returned in
operation responses.
3.2. Data Model
The data model illustrated and described in Figure 3 defines the
logical objects and the relationships between these objects that the
SPPP protocol supports. SPPP defines the protocol operations through
which an SPPP Client populates a Registry with these logical objects.
Various clients belonging to different Registrants and distinct
Registrars may use the protocol for populating the Registry's data.
3.2.1. Structure of the SPPP Data Model
The logical structure presented below is consistent with the
terminology and requirements defined in
[I-D.ietf-drinks-usecases-requirements]. 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: |
Mule, et al. Expires September 9, 2010 [Page 10]
Internet-Draft draft-mule-drinks-proto March 2010
| types | |orgName*, |
+------+------+ |sourceIdentLabels,|
+------------>|peerPrefs, |
|extension |
All objects are | |
associated with 2 | |
Organizations to +------------------+
identify the ^
registrant and |A Route Group is
the registrar |associated with
|zero or more
|Organizations
|
+-----------------------+
|Route Group: | +----------------+
| registrantOrgName*, | | |
| registrarOrgName, | | Route Record: |
| rteGrpName*, | | rteRecName*, |
| targetDomain, +------->| priority, |
| isInService, | | extension |
| resRecs, | | |
| sourceOrgs, | +----------------+
| sourceIdentLabels, | ^
| activationDate, | |Various types
| deletionDate, | |of Route
| extension | |Records...
| | �
+-----------------------+ �
^
|
+---------+------------+
|Destination |
|Group: |
| registrantOrgName*, |
| registrarOrgName, |
| destGroupName*, |
+--->| routeGrpNames*, |<----+
| | activationDate, | |
| | deletionDate, | |
| | extension | |
| +----------------------+ |
|
| A TNRange is A Public
| associated Identifier is
| with only 1 associated
| Destination with zero or
| Group. 1 Destination Group.
| |
Mule, et al. Expires September 9, 2010 [Page 11]
Internet-Draft draft-mule-drinks-proto March 2010
+----------------------+ +-------------+---------+
|TNRange: | |Public |
| registrantOrgName*, | |Identifier: |
| registrarOrgName, | | registrantOrgName*, |
| tnRangeStart*, | | registrarOrgName, |
| tnRangeEnd*, | | publicIdentifier*, |
| destGroupName*, | | destGroupName*, |
| activationDate, | | publicIdTarget, |
| deletionDate, | | |
| extension | | activationDate, |
| | | deletionDate, |
| | | extension |
+----------------------+ +-----------------------+
Second Data Model for SPPP for WG Review
Figure 3
Note that the attributes whose names end with the character * are
mandatory attributes.
3.2.2. Data Model Objects and Attributes
The objects and attributes that comprise the data model can be
described as follows (objects listed from the bottom up):
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 route records. This ability for a Public Identifier to
be directly associated with a set of routes (e.g. target URI), as
opposed to being associated with a Destination Group, supports the
use cases where the target URI contains data specifically tailored
to an individual Public Identifier.
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.
Mule, et al. Expires September 9, 2010 [Page 12]
Internet-Draft draft-mule-drinks-proto March 2010
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 Route Group contains a target domain (for Look-Up Function
resolutions) and it may contain a collection of Route Record
objects that can be used to determine the Location Routing of a
SIP route.
A Route Group can be in or out of service (indicated by
isInService). It also contains a list of organizations that can
query the object and have access to its content (sourceOrgs and
sourceIdentLabels), and an activation and deletion date.
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 Route Record of different types (rteRec):
A collection of route records; the currently defined types are
mapped to DNS Resource Records such as NAPTR, NS, TXT, etc.
A Route Record object represents data that resolution systems use
to return a route by building a NAPTR record or a SIP 3xx message.
It is associated with a Route Group for routes that are not
specific to a public identifier.
An Route Record object has a name (rteRecName), a priority to help
sort out the order of multiple routes (priority can be mapped to
NAPTR's order field), and additional elements based on its type.
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.2.3. Applicability of the Data Model for Provisioning of LUF-only
data into Registries
This section provides a read-out of the data model for SPPP clients
that only provision data for LUF resolution.
The purpose of LUF data provisioning is to provide the target domain
given a destination group. As such, a client provisioning LUF-only
data only needs to provide one or more route groups that contain a
route group name and a target domain.
Mule, et al. Expires September 9, 2010 [Page 13]
Internet-Draft draft-mule-drinks-proto March 2010
Note that source-based routing is supported: depending on what entity
requests the look-up resolution (sourceOrgs), a different target
domain can be returned by using different Route Groups.
Certain protocol operations could be added in future revisions of
this document as "short-cuts" for LUF related data provisioning.
+-----------------------+
|Route Group: |
| rteGrpName*, |
| isInService, |
| targetDomain, |
| extension |
| |
+-----------------------+
^
|
+---------+------------+
|Destination |
|Group: |
| destGroupName*, |<----+
| routeGrpNames*, | |
| extension | |
+----------------------+ |
|
+-------------+---------+
|Public |
|Identifier: |
| publicIdentifier*, |
| destGroupName*, |
| extension |
+-----------------------+
LUF-only Data Model Example for SPPP for DRINKS WG Review
Figure 4
As an example, a request to add a route group where public
identifiers resolve into the target domain ssp1.example.com during
look-up resolution would be:
Mule, et al. Expires September 9, 2010 [Page 14]
Internet-Draft draft-mule-drinks-proto March 2010
<?xml version="1.0" encoding="UTF-8"?>
<addRteGrpsRqst
xmlns="urn:ietf:params:xml:ns:sppp:base:1"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation=
"urn:ietf:params:xml:ns:sppp:base:1
file:/ietf/example1.xsd">
<basicRqst>
<clientTransId>id-12317123</clientTransId>
<minorVer>20</minorVer>
</basicRqst>
<rteGrp>
<base>
<rantId>registrantID123</rantId>
<rarId>registrarId0</rarId>
<activDate>2010-05-04T18:13:51.0Z</activDate>
<delDate>2010-05-04T18:13:51.0Z</delDate>
</base>
<rteGrpName>route_grp_1</rteGrpName>
<targetDomain>ssp1.example.com</targetDomain>
<isInSvc>true</isInSvc>
</rteGrp>
</addRteGrpsRqst>
Figure 5
3.2.4. Applicability of the Data Model for Provisioning of LUF+LRF data
into Registries
This section provides a read-out of the data model for SPPP clients
that provision data for both LUF and LRF resolution.
The purpose of LUF+LRF data provisioning is to provide the target
domain given a destination group as well as the location routing for
that target domain. As such, a client provisioning LUF+LRF data
provides one or more route groups that contain a route group name and
a target domain and each route group is associated with a Route
Record which can be in the form of a URI, or a DNS resource record
(NAPTR, NS or TXT).
Mule, et al. Expires September 9, 2010 [Page 15]
Internet-Draft draft-mule-drinks-proto March 2010
+-----------------------+
|Route Group: | +----------------+
| rteGrpName*, | | |
| isInService, | | Route Record: |
| targetDomain, +------->| rteRecName*, |
| extension | | priority, |
| | | extension |
+-----------------------+ |
^ +----------------+
|
+---------+------------+
|Destination |
|Group: |
| destGroupName*, |<----+
| routeGrpNames*, | |
| extension | |
+----------------------+ |
|
+-------------+---------+
|Public |
|Identifier: |
| publicIdentifier*, |
| destGroupName*, |
| extension |
+-----------------------+
LUF+LRF Data Model Example for SPPP for DRINKS WG Review
Figure 6
As an example, a request to add a route group where public
identifiers resolve into the target domain ssp1.example.com and NAPTR
associated with that domain based on the source Organization would
be:
Mule, et al. Expires September 9, 2010 [Page 16]
Internet-Draft draft-mule-drinks-proto March 2010
<?xml version="1.0" encoding="UTF-8"?>
<addRteGrpsRqst
xmlns="urn:ietf:params:xml:ns:sppp:base:1"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation=
"urn:ietf:params:xml:ns:sppp:base:1
file:/ietf/example2.xsd">
<basicRqst>
<clientTransId>id-12317123</clientTransId>
<minorVer>20</minorVer>
</basicRqst>
<rteGrp>
<base>
<rantId>registrantID123</rantId>
<rarId>registrarId0</rarId>
<activDate>2010-05-04T18:13:51.0Z</activDate>
<delDate>2010-05-04T18:13:51.0Z</delDate>
</base>
<rteGrpName>route_grp_1</rteGrpName>
<targetDomain>ssp1.example.com</targetDomain>
<isInSvc>true</isInSvc>
<rteRec xsi:type="NAPTRType" ttl="1000" priority="200">
<order>10</order>
<pref>100</pref>
<flags>u</flags>
<svcs>E2U+sip</svcs>
<regx>
<ere>^(.*)$</ere>
<repl>sip:\1;npdi@sbe34-ssp1.example.com;</repl>
</regx>
</rteRec>
<isInSvc>true</isInSvc>
</rteGrp>
</addRteGrpsRqst>
Figure 7
3.3. Common Attributes
This section defines common object attributes. The protocol
exchanges and operations in SPPP take various parameters. Some of
these are common to several objects.
3.3.1. Common Organization Attributes
Two organization roles have been identified in the use cases and in
this protocol. A registrant (registrantOrgName) is the organization
or business entity that "owns" the object while a registrar is an
Mule, et al. Expires September 9, 2010 [Page 17]
Internet-Draft draft-mule-drinks-proto March 2010
entity that can provision an object.
3.3.2. Common Attributes for Activation and Deletion Dates
An object's activation date (activationDate) indicates when the date
at which an object becomes active or valid. Prior to that date, the
object may be stored in the data repository but queries linked with
the object will return responses as if the object did not exist.
An object's deletion date (deletionDate) is the date at which an
object is deleted from the data repository.
3.4. Known Issues and Current Limitations of the Data Model
The data model described in Figure 3 is a preliminary version that
does not address the following needs and requirements:
o Some use cases and requirements contained in
[I-D.ietf-drinks-usecases-requirements] 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.
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 September 9, 2010 [Page 18]
Internet-Draft draft-mule-drinks-proto March 2010
4. Transport Protocol Requirements
This section provides requirements for transport protocols suitable
for SPPP. More specifically, this section specifies the services,
features, and assumptions that SPPP delegates to the chosen transport
and envelope technologies.
Two different groups of use cases are specified in
[I-D.ietf-drinks-usecases-requirements]. 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 September 9, 2010 [Page 19]
Internet-Draft draft-mule-drinks-proto March 2010
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 September 9, 2010 [Page 20]
Internet-Draft draft-mule-drinks-proto March 2010
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 September 9, 2010 [Page 21]
Internet-Draft draft-mule-drinks-proto March 2010
where the provisioning state of the network is inconsistent.
Therefore, a transport protocol for SPPP MUST provide a Response for
each Request, so that a Client can identify whether a Request
succeeded or failed.
4.10. Mandatory Transport
As of this writing of this revision, one transport protocol proposal
has been provided in [I-D.cartwright-drinks-sppp-over-soap].
This section will define a mandatory transport protocol to be
compliant with this RFC.
Mule, et al. Expires September 9, 2010 [Page 22]
Internet-Draft draft-mule-drinks-proto March 2010
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 September 9, 2010 [Page 23]
Internet-Draft draft-mule-drinks-proto March 2010
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 September 9, 2010 [Page 24]
Internet-Draft draft-mule-drinks-proto March 2010
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 September 9, 2010 [Page 25]
Internet-Draft draft-mule-drinks-proto March 2010
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 September 9, 2010 [Page 26]
Internet-Draft draft-mule-drinks-proto March 2010
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 September 9, 2010 [Page 27]
Internet-Draft draft-mule-drinks-proto March 2010
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 September 9, 2010 [Page 28]
Internet-Draft draft-mule-drinks-proto March 2010
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 September 9, 2010 [Page 29]
Internet-Draft draft-mule-drinks-proto March 2010
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 second revision of the document is to give an
overview of the envisioned commands for SPPP. It is noted that some
commands are missing and the authors seek the input of the WG for the
necessary commands.
By design, the protocol operations are restricted to add, delete and
get operations. There is no "update" or "modify" command. It is
felt that an "add" operation should be sufficient to update a
particular element set.
For an actual business process to be performed, several commands are
being typically combined.
add Route Group (addRteGrpsRqst): A Route Group" object is created
or updated with the attributes given in the command.
del Route Group (delRteGrpsRqst): A Route Group object is removed.
The object must be owned by the client, and must not be refered
from other objects.
get Route Group (getRteGrpsRqst): Returns Attributes of a given
Route Group object.
add, delete and get Destination Group (addDestGroupsRqst,
delDestGroupsRqst, getDestGroupsRqst): A Destination Group object is
created or updated with the attributes given in the
addDestGroupsRqst command; it is deleted with delDestGroupsRqst
and its data can be returned using getDestGroupsRqst.
add, delete and get Public Identifier (addPubIdsRqst, delPubIdsRqst,
getPubIdsRqst)
Mule, et al. Expires September 9, 2010 [Page 30]
Internet-Draft draft-mule-drinks-proto March 2010
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.
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
Mule, et al. Expires September 9, 2010 [Page 31]
Internet-Draft draft-mule-drinks-proto March 2010
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.
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 September 9, 2010 [Page 32]
Internet-Draft draft-mule-drinks-proto March 2010
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 September 9, 2010 [Page 33]
Internet-Draft draft-mule-drinks-proto March 2010
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 September 9, 2010 [Page 34]
Internet-Draft draft-mule-drinks-proto March 2010
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 minOccurs="0" name="targetDomain" type="string"/>
<element maxOccurs="unbounded" minOccurs="0" name="rteRec"
type="spppb:RteRecType"/>
<element name="peeringOrg" type="spppb:OrgIdType"
minOccurs="0"
maxOccurs="unbounded"/>
<element name="sourceIdent" type="spppb:SourceIdentType"
minOccurs="0"
maxOccurs="unbounded"/>
<element name="isInSvc" type="boolean"/>
</sequence>
</complexType>
<complexType name="DestGroupType">
<sequence>
<element name="base" type="spppb:BasicObjType"/>
<element name="dgName" type="string"/>
<element name="rteGrpName" type="string" minOccurs="0"
maxOccurs="unbounded"/>
</sequence>
</complexType>
<complexType name="PubIdType">
<sequence>
<element name="base" type="spppb:BasicObjType"/>
Mule, et al. Expires September 9, 2010 [Page 35]
Internet-Draft draft-mule-drinks-proto March 2010
<element name="pubId" type="string"/>
<element name="isRn" type="boolean"/>
<element name="dgName" type="string" minOccurs="0"/>
<element name="pubIdtarget" type="spppb:RteRecType"
minOccurs="0" maxOccurs="unbounded"/>
</sequence>
</complexType>
<complexType name="TNRType">
<sequence>
<element name="base" type="spppb:BasicObjType"/>
<element name="tnRStrt" type="string"/>
<element name="tnREnd" type="string"/>
<element name="dgName" type="string"/>
</sequence>
</complexType>
<complexType abstract="true" name="RteRecType">
<attribute name="rteRecName" type="string"/>
<attribute default="100" name="priority"
type="positiveInteger"/>
</complexType>
<complexType abstract="true" name="RDType">
<complexContent>
<extension base="spppb:RteRecType">
<attribute default="900" name="ttl"
type="positiveInteger"/>
</extension>
</complexContent>
</complexType>
<complexType name="RegexParamType">
<sequence>
<element name="ere" type="string" default="^(.*)$"/>
<element name="repl" type="string"/>
</sequence>
</complexType>
<complexType name="NAPTRType">
<complexContent>
<extension base="spppb:RDType">
<sequence>
<element name="order" type="unsignedShort"/>
<element name="pref" type="unsignedShort"/>
<element name="flags" type="string"
minOccurs="0"/>
<element name="svcs" type="string"/>
<element name="regx" type="spppb:RegexParamType"
minOccurs="0"/>
<element name="repl" type="string" minOccurs="0"/>
<element name="ext" type="spppb:ExtAnyType"
minOccurs="0"/>
Mule, et al. Expires September 9, 2010 [Page 36]
Internet-Draft draft-mule-drinks-proto March 2010
</sequence>
</extension>
</complexContent>
</complexType>
<complexType name="NSType">
<complexContent>
<extension base="spppb:RDType">
<sequence>
<element name="name" type="string"/>
<element name="ipAddr" type="spppb:IPAddrType"
minOccurs="0"
maxOccurs="unbounded"/>
<element name="ext" type="spppb:ExtAnyType"
minOccurs="0"/>
</sequence>
</extension>
</complexContent>
</complexType>
<complexType name="TXTType">
<complexContent>
<extension base="spppb:RDType">
<sequence>
<element name="text" type="string"/>
</sequence>
</extension>
</complexContent>
</complexType>
<complexType name="URIType">
<complexContent>
<extension base="spppb:RteRecType">
<sequence>
<element name="value" type="string"/>
<element name="ext" type="spppb:ExtAnyType"
minOccurs="0"/>
</sequence>
<attribute name="ere" default="^(.*)$" type="string"/>
</extension>
</complexContent>
</complexType>
<simpleType name="OrgIdType">
<restriction base="string"/>
</simpleType>
<simpleType name="TransIdType">
<restriction base="string"/>
</simpleType>
<simpleType name="MinorVerType">
<restriction base="unsignedLong"/>
</simpleType>
Mule, et al. Expires September 9, 2010 [Page 37]
Internet-Draft draft-mule-drinks-proto March 2010
<complexType name="BasicObjType">
<sequence>
<element name="rantId" type="spppb:OrgIdType"/>
<element name="rarId" type="spppb:OrgIdType"/>
<element name="activDate" type="dateTime" minOccurs="0"/>
<element name="delDate" type="dateTime" minOccurs="0"/>
<element name="ext" type="spppb:ExtAnyType"
minOccurs="0"/>
</sequence>
</complexType>
<complexType name="BasicRqstType">
<sequence>
<element name="clientTransId" type="spppb:TransIdType"/>
<element name="minorVer" type="spppb:MinorVerType"/>
<element name="ext" type="spppb:ExtAnyType"
minOccurs="0"/>
</sequence>
</complexType>
<complexType name="BasicQueryType">
<sequence>
<element name="minorVer" type="spppb:MinorVerType"/>
<element name="ext" type="spppb:ExtAnyType"
minOccurs="0"/>
</sequence>
</complexType>
<complexType name="BasicRspnsType">
<sequence>
<element name="clientTransId" type="spppb:TransIdType"/>
<element name="serverTransId" type="spppb:TransIdType"/>
<element name="resCode" type="int"/>
<element name="resMsg" type="string"/>
<element name="ext" type="spppb:ExtAnyType"
minOccurs="0"/>
</sequence>
</complexType>
<complexType name="IPAddrType">
<sequence>
<element name="addr" type="string"/>
<element name="type" type="spppb:IPType"/>
<element name="ext" type="spppb:ExtAnyType"
minOccurs="0"/>
</sequence>
</complexType>
<simpleType name="IPType">
<restriction base="token">
<enumeration value="IPv4"/>
<enumeration value="IPv6"/>
</restriction>
Mule, et al. Expires September 9, 2010 [Page 38]
Internet-Draft draft-mule-drinks-proto March 2010
</simpleType>
<complexType name="SourceIdentType">
<sequence>
<element name="sourceIdentLabel" type="string"/>
<element name="sourceIdentScheme"
type="spppb:SourceIdentSchemeType"/>
<element name="ext" type="spppb:ExtAnyType"
minOccurs="0"/>
</sequence>
</complexType>
<simpleType name="SourceIdentSchemeType">
<restriction base="token">
<enumeration value="URI"/>
<enumeration value="IP"/>
<enumeration value="rootDomain"/>
</restriction>
</simpleType>
<complexType name="SvcMenuType">
<sequence>
<element name="serverStatus"
type="spppb:ServerStatusType"/>
<element name="majMinVersion" type="string"
maxOccurs="unbounded"/>
<element name="objURI" type="anyURI"
maxOccurs="unbounded"/>
<element name="extURI" type="anyURI" minOccurs="0"
maxOccurs="unbounded"/>
</sequence>
</complexType>
<simpleType name="ServerStatusType">
<restriction base="token">
<enumeration value="inService"/>
<enumeration value="outOfService"/>
</restriction>
</simpleType>
<complexType name="ExtAnyType">
<sequence>
<any namespace="##other" maxOccurs="unbounded"/>
</sequence>
</complexType>
<annotation>
<documentation>
-------------- Wrapped Rqst Message Definitions ------------
</documentation>
</annotation>
<element name="addRteGrpsRqst">
<complexType>
<sequence>
Mule, et al. Expires September 9, 2010 [Page 39]
Internet-Draft draft-mule-drinks-proto March 2010
<element name="basicRqst" type="spppb:BasicRqstType"/>
<element name="rteGrp" type="spppb:RteGrpType"
maxOccurs="unbounded"/>
</sequence>
</complexType>
</element>
<element name="delRteGrpsRqst">
<complexType>
<sequence>
<element name="basicRqst" type="spppb:BasicRqstType"/>
<element name="rantId" type="spppb:OrgIdType"/>
<element name="name" type="string"/>
</sequence>
</complexType>
</element>
<element name="getRteGrpsRqst">
<complexType>
<sequence>
<element name="basicRqst"
type="spppb:BasicQueryType"/>
<element name="rantId" type="spppb:OrgIdType"
minOccurs="0"/>
<element name="name" type="string"/>
</sequence>
</complexType>
</element>
<element name="addDestGroupsRqst">
<complexType>
<sequence>
<element name="basicRqst" type="spppb:BasicRqstType"/>
<element name="destGroup" type="spppb:DestGroupType"
maxOccurs="unbounded"/>
</sequence>
</complexType>
</element>
<element name="delDestGroupsRqst">
<complexType>
<sequence>
<element name="basicRqst" type="spppb:BasicRqstType"/>
<element name="rantId" type="spppb:OrgIdType"/>
<element name="name" type="string"/>
</sequence>
</complexType>
</element>
<element name="getDestGroupsRqst">
<complexType>
<sequence>
<element name="basicRqst"
Mule, et al. Expires September 9, 2010 [Page 40]
Internet-Draft draft-mule-drinks-proto March 2010
type="spppb:BasicQueryType"/>
<element name="rantId" type="spppb:OrgIdType"
minOccurs="0"/>
<element name="name" type="string"/>
</sequence>
</complexType>
</element>
<element name="addPubIdsRqst">
<complexType>
<sequence>
<element name="basicRqst" type="spppb:BasicRqstType"/>
<element name="pi" type="spppb:PubIdType"
maxOccurs="unbounded"/>
</sequence>
</complexType>
</element>
<element name="delPubIdsRqst">
<complexType>
<sequence>
<element name="basicRqst" type="spppb:BasicRqstType"/>
<element name="dgName" type="string"/>
<element name="publicIdentifier" type="string"/>
</sequence>
</complexType>
</element>
<element name="getPubIdsRqst">
<complexType>
<sequence>
<element name="basicRqst"
type="spppb:BasicQueryType"/>
<element name="dgName" type="string" minOccurs="0"/>
<element name="publicIdentifier" type="string"/>
</sequence>
</complexType>
</element>
<element name="addTNRsRqst">
<complexType>
<sequence>
<element name="basicRqst" type="spppb:BasicRqstType"/>
<element name="tnR" type="spppb:TNRType"
maxOccurs="unbounded"/>
</sequence>
</complexType>
</element>
<element name="delTNRsRqst">
<complexType>
<sequence>
<element name="basicRqst" type="spppb:BasicRqstType"/>
Mule, et al. Expires September 9, 2010 [Page 41]
Internet-Draft draft-mule-drinks-proto March 2010
<element name="dgName" type="string"/>
<element name="tnRStrt" type="string"/>
<element name="tnREnd" type="string"/>
</sequence>
</complexType>
</element>
<element name="getTNRsRqst">
<complexType>
<sequence>
<element name="basicRqst"
type="spppb:BasicQueryType"/>
<element name="dgName" type="string" minOccurs="0"/>
<element name="tnRStrt" type="string"/>
<element name="tnREnd" type="string"/>
</sequence>
</complexType>
</element>
<element name="getSvcMenuRqst">
<complexType>
<sequence>
<element name="basicRqst"
type="spppb:BasicQueryType"/>
</sequence>
</complexType>
</element>
<annotation>
<documentation>
-------- Wrapped Rspns Message Definitions ---------------
</documentation>
</annotation>
<element name="getRteGrpsRspns">
<complexType>
<sequence>
<element name="rteGrp" type="spppb:RteGrpType"
minOccurs="0" maxOccurs="unbounded"/>
<element name="basicResult"
type="spppb:BasicRspnsType"/>
</sequence>
</complexType>
</element>
<element name="getDestGroupsRspns">
<complexType>
<sequence>
<element name="destGroup" type="spppb:DestGroupType"
minOccurs="0"
maxOccurs="unbounded"/>
<element name="basicResult"
type="spppb:BasicRspnsType"/>
Mule, et al. Expires September 9, 2010 [Page 42]
Internet-Draft draft-mule-drinks-proto March 2010
</sequence>
</complexType>
</element>
<element name="getPubIdsRspns">
<complexType>
<sequence>
<element name="pi" type="spppb:PubIdType"
minOccurs="0" maxOccurs="unbounded"/>
<element name="basicResult"
type="spppb:BasicRspnsType"/>
</sequence>
</complexType>
</element>
<element name="getTNRsRspns">
<complexType>
<sequence>
<element name="tnR" type="spppb:TNRType" minOccurs="0"
maxOccurs="unbounded"/>
<element name="basicResult"
type="spppb:BasicRspnsType"/>
</sequence>
</complexType>
</element>
<element name="getSvcMenuRspns">
<complexType>
<sequence>
<element name="svcMenu" type="spppb:SvcMenuType"/>
<element name="basicResult"
type="spppb:BasicRspnsType"/>
</sequence>
</complexType>
</element>
<element name="cmnRspns">
<complexType>
<sequence>
<element name="rspns" type="spppb:BasicRspnsType"
nillable="false"/>
</sequence>
</complexType>
</element>
<element name="spppRequest">
<complexType>
<sequence>
<any/>
</sequence>
</complexType>
</element>
<element name="spppResponse">
Mule, et al. Expires September 9, 2010 [Page 43]
Internet-Draft draft-mule-drinks-proto March 2010
<complexType>
<sequence>
<any/>
</sequence>
</complexType>
</element>
</schema>
Mule, et al. Expires September 9, 2010 [Page 44]
Internet-Draft draft-mule-drinks-proto March 2010
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 September 9, 2010 [Page 45]
Internet-Draft draft-mule-drinks-proto March 2010
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 September 9, 2010 [Page 46]
Internet-Draft draft-mule-drinks-proto March 2010
14. References
14.1. Normative References
[I-D.cartwright-drinks-sppp-over-soap]
Cartwright, K., "SPPP Over SOAP and HTTP",
draft-cartwright-drinks-sppp-over-soap-00 (work in
progress), February 2010.
[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.ietf-drinks-usecases-requirements]
Channabasappa, S., "DRINKS Use cases and Protocol
Requirements", draft-ietf-drinks-usecases-requirements-00
(work in progress), May 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,
Mule, et al. Expires September 9, 2010 [Page 47]
Internet-Draft draft-mule-drinks-proto March 2010
March 2009.
Mule, et al. Expires September 9, 2010 [Page 48]
Internet-Draft draft-mule-drinks-proto March 2010
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
Syed Wasim Ali
NeuStar
USA
Email: syed.ali@neustar.biz
Alexander Mayrhofer
enum.at GmbH
Karlsplatz 1/9
Wien, A-1010
Austria
Email: alexander.mayrhofer@enum.at
Debbie Guyton
Telcordia Technologies
1 Telcordia Drive/RRC 1E222
Piscataway, NJ 08854
USA
Email: dguyton@telcordia.com
Mule, et al. Expires September 9, 2010 [Page 49]
| PAFTECH AB 2003-2026 | 2026-04-24 14:32:37 |