One document matched: draft-mule-drinks-proto-01.txt
Differences from draft-mule-drinks-proto-00.txt
DRINKS J-F. Mule
Internet-Draft CableLabs
Intended status: Standards Track K. Cartwright
Expires: January 14, 2010 TNS
D. Guyton
Telcordia Technologies
A. Mayrhofer
enum.at GmbH
July 13, 2009
Session Peering Provisioning Protocol
draft-mule-drinks-proto-01
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 14, 2010.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Mule, et al. Expires January 14, 2010 [Page 1]
Internet-Draft draft-mule-drinks-proto July 2009
Abstract
This document defines a protocol for provisioning session
establishment data into Session Data Registries or SIP Service
Provider data stores. The provisioned data may then be used by
various network elements for session peering. This document focuses
on the Session Peering Provisioning Protocol used by clients to
provision registries. The document provides a set of guiding
principles for the design of this protocol like extensibility and
independent transport definitions, a basic data model that meets some
of the requirements discussed in DRINKS and an early XML Schema
Document.
Mule, et al. Expires January 14, 2010 [Page 2]
Internet-Draft draft-mule-drinks-proto July 2009
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Protocol Definition . . . . . . . . . . . . . . . . . . . . . 8
3.1. Protocol Overview and Layering . . . . . . . . . . . . . . 8
3.2. Data Model . . . . . . . . . . . . . . . . . . . . . . . . 9
3.3. Common Attributes . . . . . . . . . . . . . . . . . . . . 12
3.3.1. Extension Attributes . . . . . . . . . . . . . . . . . 12
3.3.2. Common Organization Attributes . . . . . . . . . . . . 13
3.3.3. Common Attributes for Activation and Deletion Dates . 13
3.4. Known Issues and Current Limitations of the Data Model . . 13
4. Transport Protocol Requirements . . . . . . . . . . . . . . . 15
4.1. Connection Oriented . . . . . . . . . . . . . . . . . . . 16
4.2. Request & Response Model . . . . . . . . . . . . . . . . . 16
4.3. Connection Lifetime . . . . . . . . . . . . . . . . . . . 16
4.4. Authentication . . . . . . . . . . . . . . . . . . . . . . 16
4.5. Confidentiality & Integrity . . . . . . . . . . . . . . . 17
4.6. Near Real Time . . . . . . . . . . . . . . . . . . . . . . 17
4.7. Request & Response Sizes . . . . . . . . . . . . . . . . . 17
4.8. Request and Response Correlation . . . . . . . . . . . . . 17
4.9. Request Acknowledgement . . . . . . . . . . . . . . . . . 17
4.10. Mandatory Transport . . . . . . . . . . . . . . . . . . . 18
5. XML Considerations . . . . . . . . . . . . . . . . . . . . . . 19
5.1. Namespaces . . . . . . . . . . . . . . . . . . . . . . . . 19
5.2. Versioning . . . . . . . . . . . . . . . . . . . . . . . . 19
6. Request and Reply Model . . . . . . . . . . . . . . . . . . . 20
6.1. Request . . . . . . . . . . . . . . . . . . . . . . . . . 20
6.2. Reply . . . . . . . . . . . . . . . . . . . . . . . . . . 22
7. Response Codes and Messages . . . . . . . . . . . . . . . . . 24
8. Protocol Commands . . . . . . . . . . . . . . . . . . . . . . 26
8.1. List of Protocol Commands . . . . . . . . . . . . . . . . 26
8.2. Example Command Description . . . . . . . . . . . . . . . 27
8.2.1. deleteDestinationGroup . . . . . . . . . . . . . . . . 27
9. Security Considerations . . . . . . . . . . . . . . . . . . . 29
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
11. Formal Specification . . . . . . . . . . . . . . . . . . . . . 31
12. Specification Extensibility . . . . . . . . . . . . . . . . . 40
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 41
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 42
14.1. Normative References . . . . . . . . . . . . . . . . . . . 42
14.2. Informative References . . . . . . . . . . . . . . . . . . 42
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 43
Mule, et al. Expires January 14, 2010 [Page 3]
Internet-Draft draft-mule-drinks-proto July 2009
1. Introduction
This document defines a Session Peering Provisioning Protocol (SPPP)
for provisioning Session Establishment Data (SED) into a Registry.
The SPPP is based on the requirements and use cases compiled in
[I-D.drinks-usecases-requirements-00].
The SED data is typically used by various systems to route a call to
the next hop associated with the called domain's ingress point. More
specifically, the SED is the set of parameters that the outgoing
signaling path border elements (SBEs) need to initiate the session.
See [RFC5486] for more details.
The SED is typically created by the terminating SIP Service Provider
(SSP) for use by the originating SSP. SED is provisioned into a
Registry shared by peer SSPs as part of their service provisioning
process. Subsequently, a Registry may distribute the received data
into local Data Repositories that can be queried to support session
look-up and or session location resolution. In some cases, the
Registry may offer a central query resolution service.
This document is intended to specify a protocol that is agnostic to
its transport. It provides a description of the data model, the
protocol operations including the model for request and responses,
and all of the needed protocol commands. The protocol allows for
some extensibility with guidelines to manage such extensibility to
better support interoperability.
Transport requirements are provided with the intention that each
underlying transport protocol will be defined in another document.
Current transport protocols under consideration include one based on
SOAP, one based on the RESTful Web Services approach and a file
transfer mechanism for batch mode protocol operations.
This document is organized as follows:
o Section 3 provides an overview of the SPPP protocol, including
the layering approach, functional entities and data model;
o Section 4 defines requirements for SPPP transport protocols;
o Section 5 defines XML considerations that XML parsers must meet
to conform to this specification.
o Section 6 describes the protocol request-reply model;
o Section 8 defines the protocol commands for this version of
SPPP, and how to extend them;
Mule, et al. Expires January 14, 2010 [Page 4]
Internet-Draft draft-mule-drinks-proto July 2009
Future revisions of this Internet-Draft will include a more complete
definition of the Session Peering Provisioning Protocol and
considerations and changes to make the protocol implementable using
SOAP and RESTful Web Services.
Mule, et al. Expires January 14, 2010 [Page 5]
Internet-Draft draft-mule-drinks-proto July 2009
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
This document reuses terms from [RFC3261], [RFC5486], the DRINKS Use
Case and Requirements document [I-D.drinks-usecases-requirements-00]
and the ENUM Validation Architecture [RFC4725].
In addition, this document specifies the following additional terms.
SPPP: Session Peering Provisioning Protocol, the protocol used to
provision data into a Registry (see arrow labeled "1." in Figure 1
of [I-D.drinks-usecases-requirements-00]). It is the primary
scope of this document.
SPDP: Session Peering Distribution Protocol, the protocol used to
distribute data to Local Data Repository (see arrow labeled "2."
in Figure 1 of [I-D.drinks-usecases-requirements-00]).
Client: An application that supports an SPPP Client; it is
sometimes referred to as a "Registry Client".
Registry: The Registry operates a master database of Session
Establishment Data for one or more Registrants.
A Registry acts as an SPPP Server.
Registrant: In this document, we extend the definition of a
Registrant based on [RFC4725]. The Registrant is the end-user,
the person or organization who is the "holder" of the Session
Establishment Data being provisioned into the Registry. For
example, in [I-D.drinks-usecases-requirements-00], a Registrant is
pictured as a SIP Service Provider in Figure 2.
A Registrant is identified by its name in the data model.
Registrar: In this document, we also extend the definition of a
Registrar from [RFC4725]. A Registrar performs provisioning
operations on behalf of a Registrant by interacting with the
Registry, in our case via the SPPP protocol defined in this
Mule, et al. Expires January 14, 2010 [Page 6]
Internet-Draft draft-mule-drinks-proto July 2009
document.
A Registrar is identified by its name in the data model.
Mule, et al. Expires January 14, 2010 [Page 7]
Internet-Draft draft-mule-drinks-proto July 2009
3. Protocol Definition
This section introduces the structure of the data model and provides
the information framework for the SPPP protocol. An overview of the
protocol operations is first provided with a typical deployment
scenario. The data model is then defined along with all the objects
manipulated by the protocol and their relationships.
3.1. Protocol Overview and Layering
SPPP is a simple request/reply protocol that allows a client
application to submit provisioning data and query requests to a
server. The SPPP data structures are designed to be protocol
agnostic. As a result, the underlying transport technology,
messaging envelope technology (if any), and the authentication scheme
are not limited or defined by this specification. However, refer to
the Transport Protocol Requirements section for assumptions that are
made about the chosen transport, envelope, and authentication
technologies.
Layer Example
+-------------+ +-----------------------------+
(5) |Data Objects | | RteGrpType, etc. |
+-------------+ +-----------------------------+
| |
+-------------+ +-----------------------------+
(4) | Operations | | addRteGrpsRqst, etc. |
+-------------+ +-----------------------------+
| |
+-------------+ +-----------------------------+
(3) | Message | | spppRequest, spppResponse |
+-------------+ +-----------------------------+
| |
+-------------+ +-----------------------------+
(2) | Message | | HTTP, SOAP, None, etc. |
| Envelope | | |
+-------------+ +-----------------------------+
| |
+-------------+ +-----------------------------+
(1) | Transport | | TCP, TLS, BEEP, etc. |
| Protocol | | |
+-------------+ +-----------------------------+
SPPP Layering
Figure 1
Mule, et al. Expires January 14, 2010 [Page 8]
Internet-Draft draft-mule-drinks-proto July 2009
SPPP can be viewed as a set of layers that collectively define the
structure of an SPPP request and response. Layers 3, 4, and 5 are
defined within this specification, while layers 1 and 2 are left to
separate specifications to allow for potentially multiple SPPP
transport, envelope, and authentication technologies.
1. The transport protocol layer provides a communication mechanism
between the client and server. SPPP can be layered over any
transport protocol that provides a set of basic requirements
defined in the Transport Protocol Requirements section.
2. The message envelope layer is optional, but can provide features
that are above the transport technology layer but below the
application messaging layer. Technologies such as HTTP and SOAP
are examples of messaging envelope technologies.
3. The message layer provides a simple, envelope-independent and
transport-independent, SPPP wrapper for SPPP request and response
messages.
4. The operation layer defines the set of base SPPP actions that can
be invoked using an SPPP message. Operations are encoded using
XML encoded actions and objects.
5. The data object layer defines the base set of SPPP data objects
that can be included in update operations or returned in
operation responses.
3.2. Data Model
The data model illustrated and described in Figure 2 defines the
logical objects and the relationships between these objects that the
SPPP protocol supports. SPPP defines the protocol operations through
which an SPPP Client populates a Registry with these logical objects.
Various clients belonging to different Registrants and distinct
Registrars may use the protocol for populating the Registry's data.
The logical structure presented below is consistent with the
terminology and requirements defined in
[I-D.drinks-usecases-requirements-00]. Note that the current version
of this data model does not yet address the notion of Data Recipient
Groups (left for a future revision of this document).
+-------------+ +------------------+
| all object | |Organization: |
| types | |orgName*, |
+------+------+ |sourceIdentLabels,|
Mule, et al. Expires January 14, 2010 [Page 9]
Internet-Draft draft-mule-drinks-proto July 2009
+------------>|peerPrefs, |
|extension |
All objects are | |
associated with 2 | |
Organizations to +------------------+
identify the ^
registrant and |A Route Group is
the registrar |associated with
|zero or more +----------------+
|Organizations |NS: |
| | nsName*, |
+-----------------------+ | ipAddrs, |
|Route Group: | | extension |
| registrantOrgName*, +------->| |
| registrarOrgName, | | |
| rteGrpName*, | +----------------+
| isInService, |
| resRecs, | +----------------+
| sourceOrgs, | |NAPTR: |
| sourceIdentLabels, | | order, |
| activationDate, +------->| pref, |
| deletionDate, | | flags, |
| extension | | svcs, |
| | | regx, |
| | | repl, |
+----------+------------+ | extension |
^ +----------------+
| ^
+---------+------------+ |
|Destination | |
|Group: | |
| registrantOrgName*, | |
| registrarOrgName, | |
| destGroupName*, | |
+--->| routeGrpNames*, |<----+ |
| | activationDate, | | |
| | deletionDate, | | |
| | extension | | |
| +----------------------+ | |
| |
| A TNRange is A Public |
| associated Identifier is |
| with only 1 associated |
| Destination with zero or |
| Group. 1 Destination Group. |
| | |
+----------------------+ +-------------+---------+ |
|TNRange: | |Public | |
Mule, et al. Expires January 14, 2010 [Page 10]
Internet-Draft draft-mule-drinks-proto July 2009
| registrantOrgName*, | |Identifier: | |
| registrarOrgName, | | registrantOrgName*, | |
| tnRangeStart*, | | registrarOrgName, | |
| tnRangeEnd*, | | publicIdentifier*, | |
| destGroupName*, | | destGroupName*, | |
| activationDate, | | resRecs, +-----+
| deletionDate, | | isRn, |
| extension | | activationDate, |
| | | deletionDate, |
| | | extension |
+----------------------+ +-----------------------+
First Data Model for SPPP for WG Review
Figure 2
Note that the attributes whose names end with the character * are
mandatory attributes.
The objects and attributes that comprise the data model can be
described as follows (objects listed from the bottom up):
o Public Identifier (publicIdentifier):
A string of numbers or characters that serves as a public
identifier. A Public Identifier may be a telephone number, an
email address, a PSTN routing number or other type of identity as
deemed appropriate.
The Public Identifier object may be associated with a Destination
Group which serves as a logical grouping of identifiers that share
a common group of Routes.
A Public Identifier may optionally be associated with zero or more
individual NAPTR records. This ability for a Public Identifier to
be directly associated with a set of NAPTRs, as opposed to being
associated with a Destination Group, supports the use cases where
the NAPTR may contain data specifically tailored to an individual
Public Identifier.
o Telephone Number Range (TNRange, tnRangeStart .. tnRangeEnd):
An object that represents an inclusive range of telephone numbers.
The TNRange object must be associated with a Destination Group
which indirectly defines the route to reach the TNs in that range.
o Destination Group (destGroupName):
A collection of zero or more Public Identifiers and Telephone
Number ranges (TNRanges) that are related to one or more Route
Group relationships.
Mule, et al. Expires January 14, 2010 [Page 11]
Internet-Draft draft-mule-drinks-proto July 2009
o Route Group (rteGrpName):
A collection of objects that can be used to determine a SIP route
(for example by resolving the NAPTR record of a Route Group, or
the domain name of a NAPTR record field, or an NS record).
A Route Group can be in or out of service (indicated by
isInService). It also contains a list of organizations that can
query the object and have access to its content (sourceOrgs and
sourceIdentLabels), and an activation and deletion date.
o Source Identity Labels attribute (sourceIdentLabels):
A character string that identifies the source of a resolution
lookup and can be used for source-based routing.
o resRecs attribute (resRecs):
A collection of NS or NAPTR resource records.
o NS (nsName):
An NS object is representing the data structure of a DNS NS
record. It is associated with a Route Group for routes that can
be resolved through a subsequent DNS resolution.
An NS object has a name (nsName) and a set of DNS name server IP
addresses.
o NAPTR:
A NAPTR object is representing the data structure of a NAPTR
record. It is associated with a Route Group for routes that are
not specific to a public identifier.
An NAPTR object has all the fields of a NAPTR record as object
attributes.
o Organization (orgName):
Represents an organization (which can be a registrant, a registrar
or an organization that is authorized to view the data such as
peer SSPs). A peer preference is also represented (peerPrefs).
All objects are associated with two organizations to identify the
registrant and the registrar.
3.3. Common Attributes
This section defines common object attributes. The protocol
exchanges and operations in SPPP take various parameters. Some of
these are common to several objects.
3.3.1. Extension Attributes
//TODO in a future revision: define the data model extensibility and
the use of extension parameters (extension).
Mule, et al. Expires January 14, 2010 [Page 12]
Internet-Draft draft-mule-drinks-proto July 2009
3.3.2. Common Organization Attributes
Two organization roles have been identified in the use cases and in
this protocol. A registrant (registrantOrgName) is the organization
or business entity that "owns" the object while a registrar is an
entity that can provision an object.
//TODO in a future revision: define the roles of organizations in
more details and provide details on how they are populated, what
organization type can change a record, etc.
3.3.3. Common Attributes for Activation and Deletion Dates
An object's activation date (activationDate) indicates when the date
at which an object becomes active or valid. Prior to that date, the
object may be stored in the data repository but queries linked with
the object will return responses as if the object did not exist.
An object's deletion date (deletionDate) is the date at which an
object is deleted from the data repository.
3.4. Known Issues and Current Limitations of the Data Model
The data model described in Figure 2 is a preliminary version that
does not address the following needs and requirements:
o Some use cases and requirements contained in
[I-D.drinks-usecases-requirements-00] such as Data Recipient
Groups and Points of Egress to name a few were left out of scope
of this version based on the design team consensus. Some require
further discussions to be best addressed in the protocol; other
will be added in future revisions of this document.
o The support of the selection of a Route Group for a Public
Identifier that belongs to two or more Destination Groups is a
known issue. It is required to add some additional atribute(s) to
allow the selection of a route group by preference, by the type of
route (transit SSP vs. carrier-of-record SSP) or by some other
means.
o Parts of the proposed draft XML Schema Definition (XSD) may have
to change to accomodate various protocol implementations using
SOAP and REST. For example, the way the basic request type is
defined in the XSD may not be suitable for REST-like protocols and
the atomic XML element definitions for add, delete and get
operations on most of objects are not friendly to the RESTful Web
Services model that employs PUT, GET, and other HTTP operations
for those commands.
Mule, et al. Expires January 14, 2010 [Page 13]
Internet-Draft draft-mule-drinks-proto July 2009
It is expected that future revisions of this document will address
some if not all of the limitations or known issues documented above.
Mule, et al. Expires January 14, 2010 [Page 14]
Internet-Draft draft-mule-drinks-proto July 2009
4. Transport Protocol Requirements
This section provides requirements for transport protocols suitable
for SPPP. More specifically, this section specifies the services,
features, and assumptions that SPPP delegates to the chosen transport
and envelope technologies.
Two different groups of use cases are specified in
[I-D.drinks-usecases-requirements-00]. One group of use cases
describes the provisioning of data by a client into a Registry
(Section 3.1 of the above referenced document), while the other group
describes the distribution of data into local data repositories
(Section 3.2). The current version of this document focuses on the
first set of use cases (client to registry provisioning).
These use cases may involve the provisioning of very small data sets
like the modification or update of a single public identifier. Other
provisioning operations may deal with huge datasets like the
"download" of a whole local number portability database to a
Registry.
As a result, a transport protocol for SPPP must be very flexible and
accommodate various sizes of data set sizes.
For the reasons outlined above, it is conceivable that provisioning
and distributing may use different transport protocols. This
document focuses on the provisioning protocol.
A few topics remain open for discussion:
o The ability to establish multiple connections between a client and
server may be desirable. If so, we may want to specify the
relation of transactions between the various connections.
o Pipelining of requests is required at the SPPP protocol layer. It
may have impacts at the transport level that need to be outlined.
o Scope: the current scope of this effort is based upon having a
connection oriented transport. Is there any need to support a
transport protocol with asynchronous operation?
o If it is required that responses arrive in the order of the
requests, this must be specified clearly.
Mule, et al. Expires January 14, 2010 [Page 15]
Internet-Draft draft-mule-drinks-proto July 2009
4.1. Connection Oriented
The SPPP protocol follows a model where a Client establishes a
connection to a Server in order to further exchange provisioning
transactions over such point-to-point connection. A transport
protocol for SPPP MUST therefore be connection oriented.
Note that the role of the "Client" and the "Server" only applies to
the connection, and those roles are not related in any way to the
type of entity that participates in a protocol exchange. For
example, a Registry might also include a "Client" when such a
Registry initiates a connection (for example, for data distribution
to SSP).
4.2. Request & Response Model
Provisioning operations in SPPP follow the request - response model,
where a transaction is initiated by a Client using a Request command,
and the Server responds to the Client by means of a Response.
Multiple subsequent request-response exchanges MAY be performed over
a single connection.
Therefore, a transport protocol for SPPP MUST follow the request-
response model by allowing a response to be sent to the request
initiator.
4.3. Connection Lifetime
Some use cases involve provisioning a single request to a network
element - connections supporting such provisioning requests might be
short-lived, and only established on demand.
Other use cases involve either provisioning a huge set of data, or a
constant stream of small updates, which would require long-lived
connections.
Therefore, a protocol suitable for SPPP SHOULD support short lived as
well as long lived connections.
4.4. Authentication
Many use cases require the Server to authenticate the Client, and
potentially also the Client to authenticate the Server. While
authentication of the Server by the Client is expected to be used
only to prevent impersonation of the Server, authentication of the
Client by the Server is expected to be used to identify and further
authorize the Client to certain resources on the Server.
Mule, et al. Expires January 14, 2010 [Page 16]
Internet-Draft draft-mule-drinks-proto July 2009
Therefore, an SPPP transport protocol MUST provide means for a Server
to authenticate and authorize a Client, and MAY provide means for
Clients to authenticate a Server.
However, SPPP transport SHOULD also allow for unauthenticated
connections.
4.5. Confidentiality & Integrity
Data that is transported over the protocol is deemed confidential.
Therefore, a transport protocol suitable for SPPP MUST ensure
confidentiality and integrity protection by providing encryption
capabilities.
Additionally, a DRINKS protocol MUST NOT use an unreliable lower-
layer transport protocol that does not provide confidentiality and
integrity protection.
4.6. Near Real Time
Many use cases require near real-time responses from the Server.
Therefore, a DRINKS transport protocol MUST support near-real-time
response to requests submitted by the Client.
4.7. Request & Response Sizes
SPPP covers a range of use cases - from cases where provisioning a
single public identifier will create very small request and response
sizes to cases where millions of data records are submitted or
retrieved in one transaction. Therefore, a transport protocol
suitable for SPPP MUST support a great variety of request and
response sizes.
A transport protocol MAY allow splitting large chunks of data into
several smaller chunks.
4.8. Request and Response Correlation
A transport protocol suitable for SPPP MUST allow responses to be
correlated with requests.
4.9. Request Acknowledgement
Data transported in the SPPP protocol is likely crucial for the
operation of the communication network that is being provisioned.
Failed transactions can lead to situations where a subset of public
identifiers (or even SSPs) might not be reachable, or situations
Mule, et al. Expires January 14, 2010 [Page 17]
Internet-Draft draft-mule-drinks-proto July 2009
where the provisioning state of the network is inconsistent.
Therefore, a transport protocol for SPPP MUST provide a Response for
each Request, so that a Client can identify whether a Request
succeeded or failed.
4.10. Mandatory Transport
//TODO in a future revision: This section will define a mandatory
transport protocol to be compliant with this RFC.
Mule, et al. Expires January 14, 2010 [Page 18]
Internet-Draft draft-mule-drinks-proto July 2009
5. XML Considerations
XML serves as the encoding format for SPPP, allowing complex
hierarchical data to be expressed in a text format that can be read,
saved, and manipulated with both traditional text tools and tools
specific to XML.
XML is case sensitive. Unless stated otherwise, XML specifications
and examples provided in this document MUST be interpreted in the
character case presented to develop a conforming implementation.
This section discusses a small number of XML-related considerations
pertaining to SPPP.
5.1. Namespaces
All SPPP protocol elements are defined in the following namespace:
urn:ietf:params:xml:ns:sppp:base:1
Namespace and schema definitions are used to identify both the base
protocol schema and the schemas for managed objects.
5.2. Versioning
All XML instances SHOULD begin with an <?xml?> declaration to
identify the version of XML that is being used, optionally identify
use of the character encoding used, and optionally provide a hint to
an XML parser that an external schema file is needed to validate the
XML instance.
Conformant XML parsers recognize both UTF-8 (defined in [RFC3629])
and UTF-16 (defined in [RFC2781]); per [RFC2277] UTF-8 is the
RECOMMENDED character encoding for use with SPPP.
Character encodings other than UTF-8 and UTF-16 are allowed by XML.
UTF-8 is the default encoding assumed by XML in the absence of an
"encoding" attribute or a byte order mark (BOM); thus, the "encoding"
attribute in the XML declaration is OPTIONAL if UTF-8 encoding is
used. SPPP clients and servers MUST accept a UTF-8 BOM if present,
though emitting a UTF-8 BOM is NOT RECOMMENDED.
Example XML declarations:
<?xml?> version="1.0" encoding="UTF-8" standalone="no"?>
Mule, et al. Expires January 14, 2010 [Page 19]
Internet-Draft draft-mule-drinks-proto July 2009
6. Request and Reply Model
An SPPP client interacts with an SPPP server by using one of the
supported transport mechanisms to send one or more requests to the
server and receive corresponding replies from the server. An SPPP
request is wrapped within the <spppRequest> element while an SPPP
reply is wrapped within an <spppReply> element. Furthermore, fully
formed SPPP requests and replies are comprised of constructs required
by the chosen transport technology, and the chosen envelope
technology. The supported transport technology and envelope
technology specifications will be defined in separate documents, and
are not discussed here.
6.1. Request
An SPPP request object, common to any transport and envelope
technology, is contained within the generic <spppRequest> element.
<element name="spppRequest">
<complexType>
<sequence>
<any/>
</sequence>
</complexType>
</element>
Within any <spppRequest> element is the request object specific to
the type of object(s) being operated on and the action(s) being
performed on that object. For example, the addRteGroupRqst object,
used to create Route Groups, that would be passed within an
<spppRequest> is defined as follows:
<element name="addRteGrpsRqst">
<complexType>
<sequence>
<element name="basicRqst"
type="spppb:BasicRqstType"/>
<element name="rteGrp"
type="spppb:RteGrpType"
maxOccurs="unbounded"/>
</sequence>
</complexType>
</element>
Mule, et al. Expires January 14, 2010 [Page 20]
Internet-Draft draft-mule-drinks-proto July 2009
All update requests contain a BasicRqstType object. This object is
defined as follows:
<complexType name="BasicRqstType">
<sequence>
<element name="clientTransId "
type="spppb:TransIdType"/>
<element name="minorVer"
type="spppb:MinorVerType"/>
<element name="ext"
type="spppb:ExtAnyType"
minOccurs="0"/>
</sequence>
</complexType>
<simpleType name="TransIdType">
<restriction base="string"/>
</simpleType>
<simpleType name="MinorVerType">
<restriction base="unsignedLong"/>
</simpleType>
The data elements within the BasicRqstType object are primarily
"house keeping" data elements. They are described as follows:
o clientTransId: The client generated transaction ID that
identifies this request for tracking purposes. This value is
also echoed back to the client in the response. This value will
not be checked for uniqueness.
o minorVer: This identifies the minor version of the SPPP API that
the client is attempting to use. This is used in conjunction
with the major version identifier in the XML namespace. Refer
to the Versioning section of this document for more detail.
o ext: This is the standard extension element for this object.
Refer to the Extensibility section of this document for more
details.
Mule, et al. Expires January 14, 2010 [Page 21]
Internet-Draft draft-mule-drinks-proto July 2009
6.2. Reply
An SPPP reply object, common to any transport and envelope
technology, is contained within the generic <spppReply> element.
<element name="spppReply">
<complexType>
<sequence>
<any/>
</sequence>
</complexType>
</element>
Within any <spppReply> element is the reply object containing the
result of the request. All create, update, and delete operations
result in a common response object structure, defined as follows:
<element name="cmnRspns">
<complexType>
<sequence>
<element name="rspns" type="spppb:BasicRspnsType"/>
</sequence>
</complexType>
</element>
<complexType name="BasicRspnsType">
<sequence>
<element name="clientTransId"
type="TransIdType"/>
<element name="serverTransId"
type="TransIdType"/>
<element name="resCode"
type="int"/>
<element name="resMsg"
type="string"/>
<element name="ext"
type="spppb:ExtAnyType"
minOccurs="0"/>
</sequence>
</complexType>
Mule, et al. Expires January 14, 2010 [Page 22]
Internet-Draft draft-mule-drinks-proto July 2009
The data elements within the BasicRspnseType object are described as
follows:
o clientTransId: The echoed back client transaction ID that
explicitly identifies this request for tracking purposes. This
value is not guaranteed to be unique.
o serverTransId: The server transaction ID that identifies this
request for tracking purposes. This value is guaranteed to be
unique.
o resCode: The response code that explicitly identifies the result
of the request. See the Response Code section for further
details.
o resMsg: The human readable response message that accompanies the
response code. See the Response Code section for further
details.
o ext: This is the standard extension element for this object.
Refer to the Extensibility section for more details.
Mule, et al. Expires January 14, 2010 [Page 23]
Internet-Draft draft-mule-drinks-proto July 2009
7. Response Codes and Messages
This section contains an initial listing of response codes and their
corresponding human readable text.
The response code numbering scheme generally adheres to the theory
formalized in section 4.2.1 of [RFC2821]:
o The first digit of the response code can only be 1 or 2: 1 = a
positive result, 2 = a negative result.
o The second digit of the response code indicates the category: 0
= Protocol Syntax, 1 = Implementation Specific Business Rule, 2
= Security, 3 = Server System.
o The third and fourth digits of the response code indicate the
individual message event within the category defines by the
first two digits.
+--------+----------------------------------------------------------+
| Result | Text |
| Code | |
+--------+----------------------------------------------------------+
| 1000 | Request Succeeded. |
| | |
| 2001 | Request syntax invalid. |
| | |
| 2002 | Request too large. |
| | |
| 2003 | Version not supported. |
| | |
| 2103 | Command invalid. |
| | |
| 2104 | Attribute value invalid: [attribute name]:[attribute |
| | value]:[objectType-objectId]. |
| | |
| 2105 | Object does not exist: [attribute name] : |
| | [objectType-objectId]. |
| | |
| 2106 | Object status or ownership does not allow for request: |
| | [request name]:[ attributeName]:[objectType-objectId]. |
| | |
| 2301 | System temporarily unavailable. |
| | |
| 2302 | Unexpected internal system or server error. |
+--------+----------------------------------------------------------+
Table 1: Response Codes Numbering Scheme and Messages
Mule, et al. Expires January 14, 2010 [Page 24]
Internet-Draft draft-mule-drinks-proto July 2009
Some response messages are "parameterized" with one or more of the
following parameters: "attribute name", "attribute value",
"objectType-objectId", and "operation name".
The use of these parameters MUST adhere to the following rules:
o All parameters within a response message are mandatory and MUST
be present. Parameters within a response message MUST NOT be
left empty.
o Any value provided for the "attribute name" parameter MUST be an
exact element name of the protocol data element that the
response message is referring to. For example, allowable values
for "attribute name" are "destGrpName", "rteGrpName", etc.
o A value provided for the "command/request type" parameter MUST
be an exact request object name that the response message is
referring to. For example, an allowable value for "request
object name" is "delRteGrpsRqst".
o The value for "attribute value" MUST be the value of the data
element to which the preceding "attribute name" refers.
o Result code 2104 SHOULD be used whenever an element value does
not adhere to data validation rules.
o Result codes 2104 and 2105 MUST NOT be used interchangeably.
Response code 2105 SHOULD be returned when the data element(s)
used to uniquely identify a pre-existing object do not exist.
If the data elements used to uniquely identify an object are
malformed, then response code 2104 SHOULD be returned.
Mule, et al. Expires January 14, 2010 [Page 25]
Internet-Draft draft-mule-drinks-proto July 2009
8. Protocol Commands
This section provides a preliminary list of SPPP protocol commands.
At this early stage of the protocol development, the commands are
only listed with a brief description.
An example of how a complete command description might look is
contained in section Section 8.2. It is expected that as the
protocol commands get more stable, full descriptions will be provided
in future revisions.
8.1. List of Protocol Commands
The commands listed below are briefly described - the primary goal of
this section in this revision of the document is to give an overview
of the envisioned commands for SPPP.
For an actual business process to be performed, several commandsare
being typically combined.
add Route Group (addRteGrpsRqst): A Route Group" object is created
or updated with the attributes given in the command.
del Route Group (delRteGrpsRqst): A Route Group object is removed.
The object must be owned by the client, and must not be refered
from other objects.
get Route Group (getRteGrpsRqst): Returns Attributes of a given
Route Group object.
add, delete and get Destination Group (addDestGroupsRqst,
delDestGroupsRqst, getDestGroupsRqst): A Destination Group object is
created or updated with the attributes given in the
addDestGroupsRqst command; it is deleted with delDestGroupsRqst
and its data can be returned using getDestGroupsRqst.
add, delete and get Public Identifier (addPubIdsRqst, delPubIdsRqst,
getPubIdsRqst)
add, delete and get TNRange (addTNRsRqst, delTNRsRqst, getTNRsRqst)
Other commands For this version and to get a list of the additional
commands, please refer to the XSD in Section 11. Reviewers of
this document are invited to provide feedback on the first list of
proposed commands.
//TODO in a future revision: add more details as the draft gets
more stable.
Mule, et al. Expires January 14, 2010 [Page 26]
Internet-Draft draft-mule-drinks-proto July 2009
8.2. Example Command Description
As outlined above, the preliminary list of commands provides only an
overview of the set of possible commands, rather than a full
normative specification. This section contains an example of what a
full specification could contain. A full specification of all
commands supported for v1.0 of SPPP will be provided in a subsequent
version of this draft.
8.2.1. deleteDestinationGroup
delDestGroupsRqst
This command requests the deletion an existing Destination Group
object.
Support for this command is REQUIRED in Servers, and RECOMMENDED in
Clients.
This command requires a single mandatory attribute, namely the
"destGroupName". The value of this attribute is used to identify the
Destination Group object instance that is to be deleted.
For the command to succeed, the following prerequisites must be met:
o The Destination Group identified by the "destGroupName" attribute
of the command must exist. If the Destination group does not
exist, an error code (TBD) is to be returned.
o The command must be issued by the registrar that is identified by
the "registrarOrgName" of the Destination Group that is being
deleted. However, local server policy may override this
prerequisite, and grant permission to "foreign" registrars. If
delete permission is not granted, the error code (TBD) is to be
returned.
o No TNRange object and no Public Identifier object must be
associated with the Destination Group to be deleted. If there is
a TNRange or a Public Identifier object associated with this
Destination Group, the error code (TBD) is to be returned.
Once the prerequisites are fulfilled, the Registry performs the
following actions:
o The "deletionDate" attribute of the Destination Group is set to
the current date.
Mule, et al. Expires January 14, 2010 [Page 27]
Internet-Draft draft-mule-drinks-proto July 2009
o The Destination Group object is removed.
o Depending on local server policy, a notify message is sent to the
Registrant (identified by the "registrantOrgName" attribute)
The command may return the following response codes: TBD.
This command is not extensible.
Mule, et al. Expires January 14, 2010 [Page 28]
Internet-Draft draft-mule-drinks-proto July 2009
9. Security Considerations
The transport protocol section contains some security properties that
the transport protocol must provide so that authenticated endpoints
can exchange data confidentially and with integrity protection.
More details will be provided in a future revision of this document.
Mule, et al. Expires January 14, 2010 [Page 29]
Internet-Draft draft-mule-drinks-proto July 2009
10. IANA Considerations
This document uses URNs to describe XML namespaces and XML schemas
conforming to a registry mechanism described in [RFC3688].
Two URI assignments are requested.
Registration request for the SPPP XML namespace:
urn:ietf:params:xml:ns:sppp:base:1
Registrant Contact: IESG
XML: None. Namespace URIs do not represent an XML specification.
Registration request for the XML schema:
URI: urn:ietf:params:xml:schema:sppp:1
Registrant Contact: IESG
XML: See the "Formal Specification" section of this document
(Section 11).
Mule, et al. Expires January 14, 2010 [Page 30]
Internet-Draft draft-mule-drinks-proto July 2009
11. Formal Specification
This section provides the draft XML Schema Definition for the SPPP
protocol. Please read Section 3.4 for known issues.
<?xml version="1.0" encoding="UTF-8"?>
<schema xmlns:spppb="urn:ietf:params:xml:ns:sppp:base:1"
xmlns="http://www.w3.org/2001/XMLSchema"
targetNamespace="urn:ietf:params:xml:ns:sppp:base:1"
elementFormDefault="qualified" xml:lang="EN">
<annotation>
<documentation>
------------------ Object Type Definitions --------------
</documentation>
</annotation>
<complexType name="RteGrpType">
<sequence>
<element name="base" type="spppb:BasicObjType"/>
<element name="rteGrpName" type="string"/>
<element name="ns" type="spppb:NSType" minOccurs="0"
maxOccurs="unbounded"/>
<element name="naptr" type="spppb:NAPTRType"
minOccurs="0" maxOccurs="unbounded"/>
<element name="peeringOrg" type="spppb:OrgIdType"
minOccurs="0" maxOccurs="unbounded"/>
<element name="sourceIdent" type="spppb:SourceIdentType"
minOccurs="0" maxOccurs="unbounded"/>
<element name="isInSvc" type="boolean"/>
</sequence>
</complexType>
<complexType name="DestGroupType">
<sequence>
<element name="base" type="spppb:BasicObjType"/>
<element name="dgName" type="string"/>
<element name="rteGrpName" type="string" minOccurs="0"
maxOccurs="unbounded"/>
</sequence>
</complexType>
<complexType name="PubIdType">
Mule, et al. Expires January 14, 2010 [Page 31]
Internet-Draft draft-mule-drinks-proto July 2009
<sequence>
<element name="base" type="spppb:BasicObjType"/>
<element name="pubId" type="string"/>
<element name="isRn" type="boolean"/>
<element name="dgName" type="string" minOccurs="0"/>
<element name="naptr" type="spppb:NAPTRType" minOccurs="0"
maxOccurs="unbounded"/>
</sequence>
</complexType>
<complexType name="TNRType">
<sequence>
<element name="base" type="spppb:BasicObjType"/>
<element name="tnRStrt" type="string"/>
<element name="tnREnd" type="string"/>
<element name="dgName" type="string"/>
</sequence>
</complexType>
<complexType name="NAPTRType">
<sequence>
<element name="order" type="unsignedShort"/>
<element name="pref" type="unsignedShort"/>
<element name="flags" type="string" minOccurs="0"/>
<element name="svcs" type="string"/>
<element name="regx" type="string" minOccurs="0"/>
<element name="repl" type="string" minOccurs="0"/>
<element name="ext" type="spppb:ExtAnyType" minOccurs="0"/>
</sequence>
</complexType>
<complexType name="NSType">
<sequence>
<element name="name" type="string"/>
<element name="ipAddr" type="spppb:IPAddrType" minOccurs="0"
maxOccurs="unbounded"/>
<element name="ext" type="spppb:ExtAnyType" minOccurs="0"/>
</sequence>
</complexType>
<simpleType name="OrgIdType">
<restriction base="string"/>
</simpleType>
<simpleType name="TransIdType">
<restriction base="string"/>
</simpleType>
<simpleType name="MinorVerType">
<restriction base="unsignedLong"/>
</simpleType>
<complexType name="BasicObjType">
<sequence>
<element name="rantId" type="spppb:OrgIdType"/>
Mule, et al. Expires January 14, 2010 [Page 32]
Internet-Draft draft-mule-drinks-proto July 2009
<element name="rarId" type="spppb:OrgIdType"/>
<element name="activDate" type="dateTime" minOccurs="0"/>
<element name="delDate" type="dateTime" minOccurs="0"/>
<element name="ext" type="spppb:ExtAnyType" minOccurs="0"/>
</sequence>
</complexType>
<complexType name="BasicRqstType">
<sequence>
<element name="clientTransId" type="spppb:TransIdType"/>
<element name="minorVer" type="spppb:MinorVerType"/>
<element name="ext" type="spppb:ExtAnyType" minOccurs="0"/>
</sequence>
</complexType>
<complexType name="BasicQueryType">
<sequence>
<element name="minorVer" type="spppb:MinorVerType"/>
<element name="ext" type="spppb:ExtAnyType" minOccurs="0"/>
</sequence>
</complexType>
<complexType name="BasicRspnsType">
<sequence>
<element name="clientTransId" type="spppb:TransIdType"/>
<element name="serverTransId" type="spppb:TransIdType"/>
<element name="resCode" type="int"/>
<element name="resMsg" type="string"/>
<element name="ext" type="spppb:ExtAnyType" minOccurs="0"/>
</sequence>
</complexType>
<complexType name="IPAddrType">
<sequence>
<element name="addr" type="string"/>
<element name="type" type="spppb:IPType"/>
<element name="ext" type="spppb:ExtAnyType" minOccurs="0"/>
</sequence>
</complexType>
<simpleType name="IPType">
<restriction base="token">
<enumeration value="IPv4"/>
<enumeration value="IPv6"/>
</restriction>
</simpleType>
<complexType name="SourceIdentType">
<sequence>
<element name="sourceIdentLabel" type="string"/>
<element name="sourceIdentScheme"
type="spppb:SourceIdentSchemeType"/>
<element name="ext" type="spppb:ExtAnyType" minOccurs="0"/>
</sequence>
Mule, et al. Expires January 14, 2010 [Page 33]
Internet-Draft draft-mule-drinks-proto July 2009
</complexType>
<simpleType name="SourceIdentSchemeType">
<restriction base="token">
<enumeration value="URI"/>
<enumeration value="IP"/>
<enumeration value="rootDomain"/>
</restriction>
</simpleType>
<complexType name="SvcMenuType">
<sequence>
<element name="serverStatus"
type="spppb:ServerStatusType"/>
<element name="majMinVersion"
type="string" maxOccurs="unbounded"/>
<element name="objURI" type="anyURI"
maxOccurs="unbounded"/>
<element name="extURI" type="anyURI"
minOccurs="0" maxOccurs="unbounded"/>
</sequence>
</complexType>
<simpleType name="ServerStatusType">
<restriction base="token">
<enumeration value="inService"/>
<enumeration value="outOfService"/>
</restriction>
</simpleType>
<complexType name="ExtAnyType">
<sequence>
<any namespace="##other" maxOccurs="unbounded"/>
</sequence>
</complexType>
<annotation>
<documentation>
-------------- Wrapped Rqst Message Definitions ------------
</documentation>
</annotation>
<element name="addRteGrpsRqst">
<complexType>
<sequence>
<element name="basicRqst" type="spppb:BasicRqstType"/>
<element name="rteGrp" type="spppb:RteGrpType"
maxOccurs="unbounded"/>
</sequence>
</complexType>
</element>
<element name="delRteGrpsRqst">
<complexType>
<sequence>
Mule, et al. Expires January 14, 2010 [Page 34]
Internet-Draft draft-mule-drinks-proto July 2009
<element name="basicRqst" type="spppb:BasicRqstType"/>
<element name="rantId" type="spppb:OrgIdType"/>
<element name="name" type="string"/>
</sequence>
</complexType>
</element>
<element name="getRteGrpsRqst">
<complexType>
<sequence>
<element name="basicRqst" type="spppb:BasicQueryType"/>
<element name="rantId" type="spppb:OrgIdType"
minOccurs="0"/>
<element name="name" type="string"/>
</sequence>
</complexType>
</element>
<element name="addDestGroupsRqst">
<complexType>
<sequence>
<element name="basicRqst"
type="spppb:BasicRqstType"/>
<element name="destGroup"
type="spppb:DestGroupType"
maxOccurs="unbounded"/>
</sequence>
</complexType>
</element>
<element name="delDestGroupsRqst">
<complexType>
<sequence>
<element name="basicRqst"
type="spppb:BasicRqstType"/>
<element name="rantId"
type="spppb:OrgIdType"/>
<element name="name"
type="string"/>
</sequence>
</complexType>
</element>
<element name="getDestGroupsRqst">
<complexType>
<sequence>
<element name="basicRqst"
type="spppb:BasicQueryType"/>
<element name="rantId"
type="spppb:OrgIdType" minOccurs="0"/>
<element name="name"
type="string"/>
Mule, et al. Expires January 14, 2010 [Page 35]
Internet-Draft draft-mule-drinks-proto July 2009
</sequence>
</complexType>
</element>
<element name="addPubIdsRqst">
<complexType>
<sequence>
<element name="basicRqst"
type="spppb:BasicRqstType"/>
<element name="pi" type="spppb:PubIdType"
maxOccurs="unbounded"/>
</sequence>
</complexType>
</element>
<element name="delPubIdsRqst">
<complexType>
<sequence>
<element name="basicRqst"
type="spppb:BasicRqstType"/>
<element name="dgName"
type="string"/>
<element name="publicIdentifier"
type="string"/>
</sequence>
</complexType>
</element>
<element name="getPubIdsRqst">
<complexType>
<sequence>
<element name="basicRqst"
type="spppb:BasicQueryType"/>
<element name="dgName"
type="string" minOccurs="0"/>
<element name="publicIdentifier"
type="string"/>
</sequence>
</complexType>
</element>
<element name="addTNRsRqst">
<complexType>
<sequence>
<element name="basicRqst"
type="spppb:BasicRqstType"/>
<element name="tnR"
type="spppb:TNRType"
maxOccurs="unbounded"/>
</sequence>
</complexType>
</element>
Mule, et al. Expires January 14, 2010 [Page 36]
Internet-Draft draft-mule-drinks-proto July 2009
<element name="delTNRsRqst">
<complexType>
<sequence>
<element name="basicRqst"
type="spppb:BasicRqstType"/>
<element name="dgName" type="string"/>
<element name="tnRStrt" type="string"/>
<element name="tnREnd" type="string"/>
</sequence>
</complexType>
</element>
<element name="getTNRsRqst">
<complexType>
<sequence>
<element name="basicRqst"
type="spppb:BasicQueryType"/>
<element name="dgName"
type="string" minOccurs="0"/>
<element name="tnRStrt" type="string"/>
<element name="tnREnd" type="string"/>
</sequence>
</complexType>
</element>
<element name="getSvcMenuRqst">
<complexType>
<sequence>
<element name="basicRqst"
type="spppb:BasicQueryType"/>
</sequence>
</complexType>
</element>
<annotation>
<documentation>
-------- Wrapped Rspns Message Definitions ---------------
</documentation>
</annotation>
<element name="getRteGrpsRspns">
<complexType>
<sequence>
<element name="rteGrp"
type="spppb:RteGrpType" minOccurs="0"
maxOccurs="unbounded"/>
<element name="basicResult"
type="spppb:BasicRspnsType"/>
</sequence>
</complexType>
</element>
<element name="getDestGroupsRspns">
Mule, et al. Expires January 14, 2010 [Page 37]
Internet-Draft draft-mule-drinks-proto July 2009
<complexType>
<sequence>
<element name="destGroup"
type="spppb:DestGroupType" minOccurs="0"
maxOccurs="unbounded"/>
<element name="basicResult"
type="spppb:BasicRspnsType"/>
</sequence>
</complexType>
</element>
<element name="getPubIdsRspns">
<complexType>
<sequence>
<element name="pi"
type="spppb:PubIdType" minOccurs="0"
maxOccurs="unbounded"/>
<element name="basicResult"
type="spppb:BasicRspnsType"/>
</sequence>
</complexType>
</element>
<element name="getTNRsRspns">
<complexType>
<sequence>
<element name="tnR" type="spppb:TNRType"
minOccurs="0"
maxOccurs="unbounded"/>
<element name="basicResult"
type="spppb:BasicRspnsType"/>
</sequence>
</complexType>
</element>
<element name="getSvcMenuRspns">
<complexType>
<sequence>
<element name="svcMenu"
type="spppb:SvcMenuType"/>
<element name="basicResult"
type="spppb:BasicRspnsType"/>
</sequence>
</complexType>
</element>
<element name="cmnRspns">
<complexType>
<sequence>
<element name="rspns"
type="spppb:BasicRspnsType"
nillable="false"/>
Mule, et al. Expires January 14, 2010 [Page 38]
Internet-Draft draft-mule-drinks-proto July 2009
</sequence>
</complexType>
</element>
<element name="spppRequest">
<complexType>
<sequence>
<any/>
</sequence>
</complexType>
</element>
<element name="spppResponse">
<complexType>
<sequence>
<any/>
</sequence>
</complexType>
</element>
</schema>
Mule, et al. Expires January 14, 2010 [Page 39]
Internet-Draft draft-mule-drinks-proto July 2009
12. Specification Extensibility
The protocol defined in this specification is extensible. This
section explains how to extend the protocol and what procedures are
necessary to follow in order to ensure proper extensions.
//TODO in a future revision: add more details as the draft gets more
stable.
Mule, et al. Expires January 14, 2010 [Page 40]
Internet-Draft draft-mule-drinks-proto July 2009
13. Acknowledgments
This document is a result of various discussions held in the DRINKS
working group and within the DRINKS protocol design team, which is
comprised of the following individuals, in alphabetical order:
Deborah A Guyton (Telcordia), Sumanth Channabasappa (CableLabs),
Jean-Francois Mule (CableLabs), Kenneth Cartwright (TNSI), Manjul
Maharishi (TNSI), Spencer Dawkins (Huawei Technologies (USA)), and
the co-chairs Richard Shockey and Alexander Mayrhofer (enum.at GmbH).
The authors of this document thank the following individuals for
their advice, reviews and comments during the development of this
protocol: Lisa Dusseault, "YOUR NAME HERE" -- send comments to drinks
list.
Mule, et al. Expires January 14, 2010 [Page 41]
Internet-Draft draft-mule-drinks-proto July 2009
14. References
14.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2277] Alvestrand, H., "IETF Policy on Character Sets and
Languages", BCP 18, RFC 2277, January 1998.
[RFC2781] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO
10646", RFC 2781, February 2000.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004.
14.2. Informative References
[I-D.drinks-usecases-requirements-00]
Channabasappa, S., "DRINKS Use cases and Protocol
Requirements", draft-ietf-drinks-usecases-requirements-00
(work in progress), March 2009.
[RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
April 2001.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[RFC3761] Faltstrom, P. and M. Mealling, "The E.164 to Uniform
Resource Identifiers (URI) Dynamic Delegation Discovery
System (DDDS) Application (ENUM)", RFC 3761, April 2004.
[RFC4725] Mayrhofer, A. and B. Hoeneisen, "ENUM Validation
Architecture", RFC 4725, November 2006.
[RFC5486] Malas, D. and D. Meyer, "Session Peering for Multimedia
Interconnect (SPEERMINT) Terminology", RFC 5486,
March 2009.
Mule, et al. Expires January 14, 2010 [Page 42]
Internet-Draft draft-mule-drinks-proto July 2009
Authors' Addresses
Jean-Francois Mule
CableLabs
858 Coal Creek Circle
Louisville, CO 80027
USA
Email: jfm@cablelabs.com
Kenneth Cartwright
TNS
1939 Roland Clarke Place
Reston, VA 20191
USA
Email: kcartwright@tnsi.com
Debbie Guyton
Telcordia Technologies
1 Telcordia Drive/RRC 1E222
Piscataway, NJ 08854
USA
Email: dguyton@telcordia.com
Alexander Mayrhofer
enum.at GmbH
Karlsplatz 1/9
Wien, A-1010
Austria
Email: alexander.mayrhofer@enum.at
Mule, et al. Expires January 14, 2010 [Page 43]
| PAFTECH AB 2003-2026 | 2026-04-24 10:57:57 |