One document matched: draft-mule-drinks-proto-01.xml
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2277 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.2277.xml">
<!ENTITY rfc2119 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc2781 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.2781.xml">
<!ENTITY rfc2821 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.2821.xml">
<!ENTITY rfc3261 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.3261.xml">
<!ENTITY rfc3263 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.3263.xml">
<!ENTITY rfc3629 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.3629.xml">
<!ENTITY rfc3688 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.3688.xml">
<!ENTITY rfc3761 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.3761.xml">
<!ENTITY rfc4725 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.4725.xml">
<!ENTITY rfc5486 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.5486.xml">
]>
<rfc category="std" docName="draft-mule-drinks-proto-01" ipr="trust200902">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<front>
<title abbrev="draft-mule-drinks-proto">
Session Peering Provisioning Protocol
</title>
<author initials='J-F.M.' surname="Mule" fullname='Jean-Francois Mule'>
<organization>CableLabs </organization>
<address>
<postal>
<street>858 Coal Creek Circle</street>
<city>Louisville</city> <region>CO</region>
<code>80027</code>
<country>USA</country>
</postal>
<email>jfm@cablelabs.com</email>
</address>
</author>
<author initials='K.C.' surname="Cartwright" fullname='Kenneth Cartwright'>
<organization>TNS</organization>
<address>
<postal>
<street>1939 Roland Clarke Place</street>
<city>Reston</city> <region>VA</region>
<code>20191</code>
<country>USA</country>
</postal>
<email>kcartwright@tnsi.com</email>
</address>
</author>
<author initials='D.G.' surname="Guyton" fullname='Debbie Guyton'>
<organization>Telcordia Technologies</organization>
<address>
<postal>
<street>1 Telcordia Drive/RRC 1E222</street>
<city>Piscataway</city> <region>NJ</region>
<code>08854</code>
<country>USA</country>
</postal>
<email>dguyton@telcordia.com</email>
</address>
</author>
<author initials='A.M.' surname="Mayrhofer" fullname='Alexander Mayrhofer'>
<organization>enum.at GmbH</organization>
<address>
<postal>
<street>Karlsplatz 1/9</street>
<city>Wien</city> <region> </region>
<code>A-1010</code>
<country>Austria</country>
</postal>
<email>alexander.mayrhofer@enum.at</email>
</address>
</author>
<date month="July" year="2009"/>
<area>Real-time Applications and Infrastructure Area</area>
<workgroup>DRINKS</workgroup>
<abstract>
<t>
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.
</t>
</abstract>
</front>
<middle>
<!-- Note: this is how you can put a note in the draft for yourself or for the co-authors to check on -->
<section anchor="introduction" title="Introduction">
<t>
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 <xref target="I-D.drinks-usecases-requirements-00"/>.
</t>
<t>
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 <xref target="RFC5486"/> for more details.
<vspace blankLines='1'/>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
This document is organized as follows:
<list style="symbols" hangIndent='5'>
<t>
<xref target="protocoldefinition"/> provides an overview of the SPPP protocol, including the layering approach, functional entities and data model;
</t>
<t>
<xref target="transportreq"/> defines requirements for SPPP transport protocols;
</t>
<t>
<xref target="xmlconsiderations"/> defines XML considerations that XML parsers must meet to conform to this specification.
</t>
<t>
<xref target="Request and Reply Model"/> describes the protocol request-reply model;
</t>
<t>
<xref target="protocolcommands"/> defines the protocol commands for this version of SPPP, and how to extend them;
</t>
</list>
</t>
<t>
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.
</t>
</section>
<section anchor="Terminology" title="Terminology">
<t>
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 <xref target="RFC2119"/>.
</t>
<t>
This document reuses terms from <xref target="RFC3261"/>, <xref target="RFC5486"/>, the DRINKS Use Case and Requirements document <xref target="I-D.drinks-usecases-requirements-00"/> and the ENUM Validation Architecture <xref target="RFC4725"/>.
</t>
<t>
In addition, this document specifies the following additional terms.
<vspace blankLines='1'/>
<list style="hanging">
<t hangText="SPPP: ">
Session Peering Provisioning Protocol, the protocol used to provision data into a Registry (see arrow labeled "1." in Figure 1 of <xref target="I-D.drinks-usecases-requirements-00"/>). It is the primary scope of this document.
<vspace blankLines='1' />
</t>
<t hangText="SPDP: ">
Session Peering Distribution Protocol, the protocol used to distribute data to Local Data Repository (see arrow labeled "2." in Figure 1 of <xref target="I-D.drinks-usecases-requirements-00"/>).
<vspace blankLines='1' />
</t>
<t hangText="Client: ">
An application that supports an SPPP Client; it is sometimes referred to as a "Registry Client".
<vspace blankLines='1' />
</t>
<t hangText="Registry: ">
The Registry operates a master database of Session Establishment Data for one or more Registrants.
<vspace blankLines='1' />
A Registry acts as an SPPP Server.
<vspace blankLines='1' />
</t>
<t hangText="Registrant: ">
In this document, we extend the definition of a Registrant based on <xref target="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 <xref target="I-D.drinks-usecases-requirements-00"/>, a Registrant is pictured as a SIP Service Provider in Figure 2.
<vspace blankLines='1' />
A Registrant is identified by its name in the data model.
<vspace blankLines='1' />
</t>
<t hangText="Registrar: ">
In this document, we also extend the definition of a Registrar from <xref target="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.
<vspace blankLines='1' />
A Registrar is identified by its name in the data model.
</t>
</list>
</t>
</section>
<section anchor="protocoldefinition" title="Protocol Definition">
<t>
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.
</t>
<section anchor="protocoloverview" title="Protocol Overview and Layering">
<t>
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.
</t>
<figure align="center" anchor="SPPP_layering">
<artwork align="center">
<![CDATA[
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 | | |
+-------------+ +-----------------------------+
]]>
</artwork>
<postamble>
SPPP Layering
</postamble>
</figure>
<t>
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.
</t>
<t>
<list style="numbers">
<t>
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.
</t>
<t>
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.
</t>
<t>
The message layer provides a simple, envelope-independent and transport-independent, SPPP wrapper for SPPP request and response messages.
</t>
<t>
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.
</t>
<t>
The data object layer defines the base set of SPPP data objects that can be included in update operations or returned in operation responses.
</t>
</list>
</t>
</section>
<section anchor="datamodel" title="Data Model">
<t>
The data model illustrated and described in <xref target="SPPP_datamodel"/> 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.
</t>
<t>
The logical structure presented below is consistent with the terminology and requirements defined in <xref target="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).
</t>
<figure align="center" anchor="SPPP_datamodel">
<preamble>
</preamble>
<artwork align="center"><![CDATA[
+-------------+ +------------------+
| all object | |Organization: |
| 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 |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 | |
| registrantOrgName*, | |Identifier: | |
| registrarOrgName, | | registrantOrgName*, | |
| tnRangeStart*, | | registrarOrgName, | |
| tnRangeEnd*, | | publicIdentifier*, | |
| destGroupName*, | | destGroupName*, | |
| activationDate, | | resRecs, +-----+
| deletionDate, | | isRn, |
| extension | | activationDate, |
| | | deletionDate, |
| | | extension |
+----------------------+ +-----------------------+
]]></artwork>
<postamble>
First Data Model for SPPP for WG Review
</postamble>
</figure>
<t>
Note that the attributes whose names end with the character * are mandatory attributes.
</t>
<t>
The objects and attributes that comprise the data model can be described as follows (objects listed from the bottom up):
<list style="symbols">
<t> Public Identifier (publicIdentifier):
<vspace blankLines='0'/>
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.
<vspace blankLines='1'/>
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.
<vspace blankLines='1'/>
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.
</t>
<t> Telephone Number Range (TNRange, tnRangeStart .. tnRangeEnd):
<vspace blankLines='0'/>
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.
</t>
<t> Destination Group (destGroupName):
<vspace blankLines='0'/>
A collection of zero or more Public Identifiers and Telephone Number ranges (TNRanges) that are related to one or more Route Group relationships.
</t>
<t> Route Group (rteGrpName):
<vspace blankLines='0'/>
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).
<vspace blankLines='0'/>
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.
</t>
<t> Source Identity Labels attribute (sourceIdentLabels):
<vspace blankLines='0'/>
A character string that identifies the source of a resolution lookup and can be used for source-based routing.
</t>
<t> resRecs attribute (resRecs):
<vspace blankLines='0'/>
A collection of NS or NAPTR resource records.
</t>
<t> NS (nsName):
<vspace blankLines='0'/>
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.
<vspace blankLines='0'/>
An NS object has a name (nsName) and a set of DNS name server IP addresses.
</t>
<t> NAPTR:
<vspace blankLines='0'/>
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.
<vspace blankLines='0'/>
An NAPTR object has all the fields of a NAPTR record as object attributes.
</t>
<t>
Organization (orgName):
<vspace blankLines='0'/>
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).
<vspace blankLines='0'/>
All objects are associated with two organizations to identify the registrant and the registrar.
</t>
</list>
</t>
</section>
<section anchor="commonparams" title="Common Attributes">
<t>
This section defines common object attributes. The protocol exchanges and operations in SPPP take various parameters. Some of these are common to several objects.
</t>
<section anchor="commonparamsExt" title="Extension Attributes">
<t> //TODO in a future revision: define the data model extensibility and the use of extension parameters (extension).
</t>
</section>
<section anchor="commonparamsOrg" title="Common Organization Attributes">
<t> 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.
</t>
<t>//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.
</t>
</section>
<section anchor="commonparamsDates" title="Common Attributes for Activation and Deletion Dates">
<t> 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.
</t>
<t>An object's deletion date (deletionDate) is the date at which an object is deleted from the data repository. </t>
</section>
</section>
<section anchor="openisssues" title="Known Issues and Current Limitations of the Data Model">
<t>
The data model described in <xref target="SPPP_datamodel"/> is a preliminary version that does not address the following needs and requirements:
<list style="symbols">
<t>
Some use cases and requirements contained in <xref target="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.
</t>
<t>
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.
</t>
<t>
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.
</t>
</list>
<vspace blankLines='0'/>
It is expected that future revisions of this document will address some if not all of the limitations or known issues documented above.
</t>
</section>
</section>
<section anchor='transportreq' title='Transport Protocol Requirements'>
<t>
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.
</t>
<t>
Two different groups of use cases are specified in <xref target="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).
<vspace blankLines='1'/>
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.
<vspace blankLines='1'/>
As a result, a transport protocol for SPPP must be very
flexible and accommodate various sizes of data set sizes.
</t>
<t>
For the reasons outlined above, it is conceivable that provisioning and distributing may use different transport protocols. This document focuses on the provisioning protocol.
</t>
<t>A few topics remain open for discussion:
<list style='symbols'>
<t>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.</t>
<t>Pipelining of requests is required at the SPPP protocol layer. It may have impacts at the transport level that need to be outlined.</t>
<t>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?
</t>
<t>If it is required that responses arrive in the order of the
requests, this must be specified clearly.</t>
</list>
</t>
<section anchor='transpconnreq' title='Connection Oriented'>
<t>
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.
</t>
<t>
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).
</t>
</section>
<section anchor='requestresponse' title='Request & Response Model'>
<t>
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.
<vspace blankLines='1' />
Multiple subsequent request-response exchanges MAY be performed over a single connection.
</t>
<t>
Therefore, a transport protocol for SPPP MUST follow the request-response model by allowing a response to be sent to the request initiator.</t>
</section>
<section anchor='connectionlength' title='Connection Lifetime'>
<t>
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.
</t>
<t>
Other use cases involve either provisioning a huge set
of data, or a constant stream of small updates, which would require
long-lived connections.
</t>
<t>
Therefore, a protocol suitable for SPPP SHOULD support short lived as well
as long lived connections.
</t>
</section>
<section anchor='authentication' title='Authentication'>
<t>
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.
</t>
<t>
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.
</t>
<t>
However, SPPP transport SHOULD also allow for
unauthenticated connections.</t>
</section>
<section anchor='confidentiality' title='Confidentiality & Integrity'>
<t>
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.
</t>
<t>
Additionally, a DRINKS protocol MUST NOT use an unreliable lower-layer transport protocol that does not provide confidentiality and integrity protection.
</t>
</section>
<section anchor='timing' title='Near Real Time'>
<t>
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.
</t>
</section>
<section anchor='respsizes' title='Request & Response Sizes'>
<t>
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.
</t>
<t>
A transport protocol MAY allow splitting large chunks of data into several smaller chunks.
</t>
</section>
<section anchor='reqorder' title='Request and Response Correlation'>
<t>
A transport protocol suitable for SPPP MUST allow responses to be correlated with requests.
</t>
</section>
<section anchor='ack' title='Request Acknowledgement'>
<t>
Data transported in the SPPP protocol is likely crucial for the operation of the communication network that is being provisioned.
<vspace blankLines='1'/>
Failed transactions can lead to situations where a subset of public identifiers (or even SSPs) might not be reachable, or situations where the provisioning state of the network is inconsistent.
</t>
<t>
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.
</t>
</section>
<section anchor="mandatorytransport" title="Mandatory
Transport">
<t>
//TODO in a future revision: This section will define a mandatory transport
protocol to be compliant with this RFC.
</t>
</section>
</section> <!-- end of transport req section -->
<section anchor="xmlconsiderations" title="XML Considerations">
<t>
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.
<vspace blankLines='1'/>
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.
<vspace blankLines='1'/>
This section discusses a small number of XML-related considerations pertaining to SPPP.
</t>
<section anchor="namespaces" title="Namespaces">
<t>
All SPPP protocol elements are defined in the following namespace: <vspace blankLines='0'/>
urn:ietf:params:xml:ns:sppp:base:1
</t>
<t>
Namespace and schema definitions are used to identify both the base protocol schema and the schemas for managed objects.
</t>
</section>
<section anchor="versioning" title="Versioning">
<t>
All XML instances SHOULD begin with an <![CDATA[ <?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.
<vspace blankLines='1'/>
Conformant XML parsers recognize both UTF-8 (defined in <xref target="RFC3629"/>) and UTF-16 (defined in <xref target="RFC2781"/>); per <xref target="RFC2277"/> UTF-8 is the RECOMMENDED character encoding for use with SPPP.
</t>
<t>
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.
</t>
<t>
Example XML declarations:
<vspace blankLines='1'/>
<![CDATA[ <?xml?> version="1.0" encoding="UTF-8" standalone="no"?>]]>
</t>
</section>
</section>
<section anchor="Request and Reply Model" title="Request and Reply Model">
<t>
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 <![CDATA[<spppRequest> ]]>element while an SPPP reply is wrapped within an <![CDATA[<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.
</t>
<section anchor="request" title="Request">
<t>
An SPPP request object, common to any transport and envelope technology, is contained within the generic <![CDATA[<spppRequest>]]> element.
</t>
<t>
<figure title="">
<artwork align="left">
<![CDATA[
<element name="spppRequest">
<complexType>
<sequence>
<any/>
</sequence>
</complexType>
</element>
]]>
</artwork>
</figure>
</t>
<t>
Within any <![CDATA[<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 <![CDATA[<spppRequest>]]> is defined as follows:
</t>
<t>
<figure title="">
<artwork align="left">
<![CDATA[
<element name="addRteGrpsRqst">
<complexType>
<sequence>
<element name="basicRqst"
type="spppb:BasicRqstType"/>
<element name="rteGrp"
type="spppb:RteGrpType"
maxOccurs="unbounded"/>
</sequence>
</complexType>
</element>
]]>
</artwork>
</figure>
</t>
<t>
All update requests contain a BasicRqstType object. This object is defined as follows:
</t>
<t>
<figure title="">
<artwork align="left">
<![CDATA[
<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>
]]>
</artwork>
</figure>
</t>
<t>
<figure title="">
<artwork align="left">
<![CDATA[
<simpleType name="TransIdType">
<restriction base="string"/>
</simpleType>
]]>
</artwork>
</figure>
</t>
<t>
<figure title="">
<artwork align="left">
<![CDATA[
<simpleType name="MinorVerType">
<restriction base="unsignedLong"/>
</simpleType>
]]>
</artwork>
</figure>
</t>
<t>
The data elements within the BasicRqstType object are primarily “house keeping” data elements. They are described as follows:
<list style="symbols" hangIndent='5'>
<t>
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.
</t>
<t>
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.
</t>
<t>
ext: This is the standard extension element for this object. Refer to the Extensibility section of this document for more details.
</t>
</list>
</t>
</section>
<section anchor="reply" title="Reply">
<t>
An SPPP reply object, common to any transport and envelope technology, is contained within the generic <![CDATA[<spppReply>]]> element.
</t>
<t>
<figure title="">
<artwork align="left">
<![CDATA[
<element name="spppReply">
<complexType>
<sequence>
<any/>
</sequence>
</complexType>
</element>
]]>
</artwork>
</figure>
</t>
<t>
Within any <![CDATA[<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:
</t>
<t>
<figure title="">
<artwork align="left">
<![CDATA[
<element name="cmnRspns">
<complexType>
<sequence>
<element name="rspns" type="spppb:BasicRspnsType"/>
</sequence>
</complexType>
</element>
]]>
</artwork>
</figure>
</t>
<t>
<figure title="">
<artwork align="left">
<![CDATA[
<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>
]]>
</artwork>
</figure>
</t>
<t>
The data elements within the BasicRspnseType object are described as follows:
<list style="symbols" hangIndent='5'>
<t>
clientTransId: The echoed back client transaction ID that explicitly identifies this request for tracking purposes. This value is not guaranteed to be unique.
</t>
<t>
serverTransId: The server transaction ID that identifies this request for tracking purposes. This value is guaranteed to be unique.
</t>
<t>
resCode: The response code that explicitly identifies the result of the request. See the Response Code section for further details.
</t>
<t>
resMsg: The human readable response message that accompanies the response code. See the Response Code section for further details.
</t>
<t>
ext: This is the standard extension element for this object. Refer to the Extensibility section for more details.
</t>
</list>
</t>
</section>
</section>
<section anchor="resultcodes" title="Response Codes and Messages">
<t>
This section contains an initial listing of response codes and their corresponding human readable text.
</t>
<t>
The response code numbering scheme generally adheres to the theory formalized in section 4.2.1 of <xref target="RFC2821"/>:
<list style="symbols" hangIndent='5'>
<t>
The first digit of the response code can only be 1 or 2: 1 = a positive result, 2 = a negative result.
</t>
<t>
The second digit of the response code indicates the category: 0 = Protocol Syntax, 1 = Implementation Specific Business Rule, 2 = Security, 3 = Server System.
</t>
<t>
The third and fourth digits of the response code indicate the individual message event within the category defines by the first two digits.
</t>
</list>
</t>
<texttable anchor='Table1' title="Response Codes Numbering Scheme and Messages">
<ttcol align='left' width='10%'>Result Code</ttcol>
<ttcol align='left' width='90%'>Text</ttcol>
<c> 1000 </c>
<c> Request Succeeded.</c>
<c> 2001 </c>
<c> Request syntax invalid.</c>
<c> 2002 </c>
<c> Request too large.</c>
<c> 2003 </c>
<c> Version not supported.</c>
<c> 2103 </c>
<c> Command invalid.</c>
<c> 2104 </c>
<c> Attribute value invalid: [attribute name]:[attribute value]:[objectType-objectId].</c>
<c> 2105 </c>
<c> Object does not exist: [attribute name] : [objectType-objectId].</c>
<c> 2106 </c>
<c> Object status or ownership does not allow for request: [request name]:[ attributeName]:[objectType-objectId].</c>
<c> 2301 </c>
<c> System temporarily unavailable.</c>
<c> 2302 </c>
<c> Unexpected internal system or server error.</c>
</texttable>
<t>
Some response messages are "parameterized" with one or more of the following parameters: "attribute name", "attribute value", "objectType-objectId", and "operation name".
</t>
<t>
The use of these parameters MUST adhere to the following rules:
<list style="symbols" hangIndent='5'>
<t hangText="">
All parameters within a response message are mandatory and MUST be present. Parameters within a response message MUST NOT be left empty.
</t>
<t hangText="">
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.
</t>
<t hangText="">
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".
</t>
<t hangText="">
The value for "attribute value" MUST be the value of the data
element to which the preceding "attribute name" refers.
</t>
<t hangText="">
Result code 2104 SHOULD be used whenever an element value does
not adhere to data validation rules.
</t>
<t hangText="">
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.
</t>
</list>
</t>
</section>
<section anchor="protocolcommands" title="Protocol Commands">
<t>
This section provides a preliminary list of SPPP protocol commands.
<vspace blankLines='0'/>
At this early stage of the protocol development, the commands are only listed with a brief description.
</t>
<t>
An example of how a complete command description might look is contained in section <xref target='commanddetail'/>. It is expected that as the protocol commands get more stable, full descriptions will be provided in future revisions.
</t>
<section anchor='commandlist' title='List of Protocol Commands'>
<t>
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.
</t>
<t>
For an actual business process to be performed, several commandsare being typically combined.
<list style='hanging'>
<t hangText='add Route Group (addRteGrpsRqst):'>
A Route Group" object is created or updated with the attributes given in the command.
</t>
<t hangText='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.
</t>
<t hangText='get Route Group (getRteGrpsRqst):'>
Returns Attributes of a given Route Group object.
</t>
<t hangText='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.
</t>
<t hangText='add, delete and get Public Identifier (addPubIdsRqst, delPubIdsRqst, getPubIdsRqst)'>
</t>
<t hangText='add, delete and get TNRange (addTNRsRqst, delTNRsRqst, getTNRsRqst)'>
</t>
<t hangText='Other commands'>
For this version and to get a list of the additional commands, please refer to the XSD in <xref target="formalspecification"/>. Reviewers of this document are invited to provide feedback on the first list of proposed commands.
<vspace blankLines='1'/>
//TODO in a future revision: add more details as the draft gets more stable.
</t>
</list>
</t>
</section>
<section anchor='commanddetail' title='Example Command Description'>
<t>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.
</t>
<section anchor='Delete a Destination Group command'
title='deleteDestinationGroup'>
<t hangText='Command Name:'>delDestGroupsRqst
</t>
<t hangText='Description:'>This command requests the deletion an existing Destination Group object.
</t>
<t hangText='Implementation Level:'>Support for this command is
REQUIRED in Servers, and RECOMMENDED in Clients.
</t>
<t hangText='Command Attributes:'>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.
</t>
<t hangText='Prerequisites:'>For the command to succeed, the
following
prerequisites must be met:
<list style='symbols'>
<t>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.
</t>
<t>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.
</t>
<t>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.
</t>
</list>
</t>
<t hangText='Command actions:'>Once the prerequisites are
fulfilled,
the Registry performs the following actions:
<list style='symbols'>
<t>The "deletionDate" attribute of the Destination Group is
set to the current date.
</t>
<t>The Destination Group object is removed.
</t>
<t>Depending on local server policy, a notify message
is sent to the Registrant (identified
by the "registrantOrgName" attribute)
</t>
</list>
</t>
<t hangText='Possible Response Codes:'>The command may return the
following response codes: TBD.
</t>
<t hangText='Extensibility:'>This command is not extensible.
</t>
</section>
</section>
</section>
<section anchor="securityconsiderations" title="Security Considerations">
<t>
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.
</t>
<t>
More details will be provided in a future revision of this document.
</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>
This document uses URNs to describe XML namespaces and XML schemas conforming to a registry mechanism described in <xref target="RFC3688"/>.
</t>
<t>
Two URI assignments are requested.
<vspace blankLines='1'/>
Registration request for the SPPP XML namespace:
<vspace blankLines='0'/>
urn:ietf:params:xml:ns:sppp:base:1
<vspace blankLines='0'/>
Registrant Contact: IESG
<vspace blankLines='0'/>
XML: None. Namespace URIs do not represent an XML specification.
</t>
<t>
Registration request for the XML schema:
<vspace blankLines='0'/>
URI: urn:ietf:params:xml:schema:sppp:1
<vspace blankLines='0'/>
Registrant Contact: IESG
<vspace blankLines='0'/>
XML: See the "Formal Specification" section of this document (<xref target="formalspecification"/>).
</t>
</section>
<section anchor="formalspecification" title="Formal Specification">
<t>
This section provides the draft XML Schema Definition for the SPPP protocol. Please read <xref target="openisssues"/> for known issues.
</t>
<t>
<figure title="">
<artwork align="left">
<![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<schema xmlns:spppb="urn:ietf:params:xml:ns:sppp:base:1"
xmlns="http://www.w3.org/2001/XMLSchema"
targetNamespace="urn:ietf:params:xml:ns:sppp:base:1"
elementFormDefault="qualified" xml:lang="EN">
<annotation>
<documentation>
------------------ Object Type Definitions --------------
</documentation>
</annotation>
<complexType name="RteGrpType">
<sequence>
<element name="base" type="spppb:BasicObjType"/>
<element name="rteGrpName" type="string"/>
<element name="ns" type="spppb:NSType" minOccurs="0"
maxOccurs="unbounded"/>
<element name="naptr" type="spppb:NAPTRType"
minOccurs="0" maxOccurs="unbounded"/>
<element name="peeringOrg" type="spppb:OrgIdType"
minOccurs="0" maxOccurs="unbounded"/>
<element name="sourceIdent" type="spppb:SourceIdentType"
minOccurs="0" maxOccurs="unbounded"/>
<element name="isInSvc" type="boolean"/>
</sequence>
</complexType>
<complexType name="DestGroupType">
<sequence>
<element name="base" type="spppb:BasicObjType"/>
<element name="dgName" type="string"/>
<element name="rteGrpName" type="string" minOccurs="0"
maxOccurs="unbounded"/>
</sequence>
</complexType>
<complexType name="PubIdType">
<sequence>
<element name="base" type="spppb:BasicObjType"/>
<element name="pubId" type="string"/>
<element name="isRn" type="boolean"/>
<element name="dgName" type="string" minOccurs="0"/>
<element name="naptr" type="spppb:NAPTRType" minOccurs="0"
maxOccurs="unbounded"/>
</sequence>
</complexType>
<complexType name="TNRType">
<sequence>
<element name="base" type="spppb:BasicObjType"/>
<element name="tnRStrt" type="string"/>
<element name="tnREnd" type="string"/>
<element name="dgName" type="string"/>
</sequence>
</complexType>
<complexType name="NAPTRType">
<sequence>
<element name="order" type="unsignedShort"/>
<element name="pref" type="unsignedShort"/>
<element name="flags" type="string" minOccurs="0"/>
<element name="svcs" type="string"/>
<element name="regx" type="string" minOccurs="0"/>
<element name="repl" type="string" minOccurs="0"/>
<element name="ext" type="spppb:ExtAnyType" minOccurs="0"/>
</sequence>
</complexType>
<complexType name="NSType">
<sequence>
<element name="name" type="string"/>
<element name="ipAddr" type="spppb:IPAddrType" minOccurs="0"
maxOccurs="unbounded"/>
<element name="ext" type="spppb:ExtAnyType" minOccurs="0"/>
</sequence>
</complexType>
<simpleType name="OrgIdType">
<restriction base="string"/>
</simpleType>
<simpleType name="TransIdType">
<restriction base="string"/>
</simpleType>
<simpleType name="MinorVerType">
<restriction base="unsignedLong"/>
</simpleType>
<complexType name="BasicObjType">
<sequence>
<element name="rantId" type="spppb:OrgIdType"/>
<element name="rarId" type="spppb:OrgIdType"/>
<element name="activDate" type="dateTime" minOccurs="0"/>
<element name="delDate" type="dateTime" minOccurs="0"/>
<element name="ext" type="spppb:ExtAnyType" minOccurs="0"/>
</sequence>
</complexType>
<complexType name="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>
</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>
<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"/>
</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"/>
<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"/>
</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">
<complexType>
<sequence>
<any/>
</sequence>
</complexType>
</element>
</schema>
]]>
</artwork>
</figure>
</t>
</section>
<section anchor="specificationextensibility" title="Specification Extensibility">
<t>
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.
</t>
<t>
//TODO in a future revision: add more details as the draft gets more stable.
</t>
</section>
<section title="Acknowledgments">
<t>
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).
</t>
<t>
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.
</t>
</section>
</middle>
<back>
<references title="Normative References">
&rfc2119;
&rfc2277;
&rfc3629;
&rfc2781;
&rfc3688;
</references>
<references title="Informative References">
&rfc2821;
&rfc3261;
&rfc3761;
&rfc4725;
&rfc5486;
<reference anchor='I-D.drinks-usecases-requirements-00'>
<front>
<title>DRINKS Use cases and Protocol Requirements</title>
<author initials='S.C.' surname="Channabasappa" fullname='Sumanth Channabasappa'>
<organization>CableLabs</organization>
<address>
<postal>
<street>858 Coal Creek Circle</street>
<city>Louisville</city> <region>CO</region>
<code>80027</code>
<country>USA</country>
</postal>
<email>sumanth@cablelabs.com</email>
</address>
</author>
<date month='March' year='2009' />
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-drinks-usecases-requirements-00"/>
<format type='HTML' target='http://tools.ietf.org/html/draft-ietf-drinks-usecases-requirements' />
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 10:55:38 |