One document matched: draft-mule-drinks-proto-00.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 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-00" 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, data that may then be used by various network elements for session peering. This document focuses on the Session Peering Provisioning Protocol used by clients to provision registries. The document provides a set of guiding principles for the design of this protocol like extensibility and independent transport definitions, a basic data model that meets some of the requirements discussed in DRINKS and an early XML Schema Document.
</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>
</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 and one based on the RESTful Wed Services approach.
</t>
<t>
This document is organized as follows:
<list style="symbols" hangIndent='5'>
<t>
<xref target="protocoldefinition"/> and <xref target="Request and Reply Model"/> describe the SPPP protocol's functional entities, its layering approach, the extensible data model, and the request-reply model
</t>
<t>
<xref target="transportreq"/> defines some requirements to be met for transport protocols suitable for SPPP,
</t>
<t>
<xref target="protocolcommands"/> defines the protocol commands for this version of SPPP, and how to extend them,
</t>
<t>
<xref target="xmlconsiderations"/> defines XML considerations that XML parsers must meet to conform to this specification,
</t>
</list>
</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"/> (e.g., SIP), <xref target="RFC5486"/> (e.g., LUF, LRF), the DRINKS Use Case and Requirements document <xref target="I-D.drinks-usecases-requirements-00"/> and the ENUM Validation Architecture <xref target="RFC4725"/>.
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"/>). It is presently left out of scope of this document.
<vspace blankLines='1' />
</t>
<t hangText="Registry Client: ">
An SPPP 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='0' />
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='0' />
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">
<t> //TODO </t>
</section>
<section anchor="layering" title="Layering">
<t> //TODO </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 | | |
| types | |Organization: |
| | |orgName*, |
+------+------+ |sourceIdentLabels,|
+------------>|peerPrefs, |
|extension |
All objects are | |
associated with 2 | |
Organizations to +------------------+
identify the ^
registrant and |A Route Group is
the registrar |associated with
|zero or more +----------------+
|Organizations |NS: |
| | nsName*, |
+-----------------------+ | ipAddrs, |
|Route Group: | | extension |
| registrantOrgName*, +------->| |
| registrarOrgName, | | |
| rteGrpName*, | +----------------+
| isInService, |
| resRecs, | +----------------+
| sourceOrgs, | |NAPTR: |
| sourceIdentLabels, | | order, |
| activationDate, +------->| pref, |
| deletionDate, | | flags, |
| extension | | svcs, |
| | | regx, |
| | | repl, |
+----------+------------+ | extension |
^ | |
| +----------------+
| ^
+---------+------------+ |
|Destination | |
|Group: | |
| registrantOrgName*, | |
| registrarOrgName, | |
| destGroupName*, | |
+--->| routeGrpNames*, |<----+ |
| | activationDate, | | |
| | deletionDate, | | |
| | extension | | |
| | | | |
| | | | |
| +----------------------+ | |
| |
| A TNRange is A Public |
| associated Identify is |
| with only 1 associated |
| Destination with zero or |
| Group. 1 Destination Group. |
| | |
+----------------------+ +-------------+---------+ |
|TNRange: | |Public | |
| registrantOrgName*, | |Identifier: | |
| registrarOrgName, | | registrantOrgName*, | |
| tnRangeStart*, | | registrarOrgName, | |
| tnRangeEnd*, | | publicIdentifier*, | |
| destGroupName*, | | destGroupName*, | |
| activationDate, | | resRecs, +-----+
| deletionDate, | | isRn, |
| 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='0'/>
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='0'/>
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):
A collection of objects that can be used to determine a SIP route (for example the NAPTR record, or by using the domain name of a NAPTR record field, or an NS record).
</t>
<t> source Identity Labels attribute (sourceIdentLabels):
A character string that identifies the source of a resolution lookup and can be used for source-based routing.
</t>
<t> resRecs attribute (resRecs):
A collection of NS or NAPTR resource records.
</t>
<t> 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.
</t>
<t> 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.
</t>
<t> Organization (orgName): a registrant or registrar organization.
</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 parameters are specific to certain objects while others are common to several objects.
</t>
<section anchor="commonparamsExt" title="Extension Attributes">
<t> //TODO: define the data model extensibility and the use of extension parameters.
</t>
</section>
<section anchor="commonparamsOrg" title="Common Organization Attributes">
<t> //TODO: define the roles of organizations, describe registrantOrgName, registrarOrgName parameters and provide details on how they are populated, what organization type can change a record, etc.
</t>
</section>
<section anchor="commonparamsDates" title="Common Attributes for Activation and Deletion Dates">
<t> //TODO: define the activationDate, deletionDate parameters and provide one or two examples, etc.
</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.
</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>TODO: 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 it ok to defer other asynchronous transport properties?</t>
<t>If it is required that responses arrive in the order of the
requests, it 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 for a Server to
authenticate/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 as well as ensure completeness
of the data. Therefore, a DRINKS protocol MUST NOT use an unreliable
lower-layer transport protocol.
</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>
DRINKS covers a range of use cases - from cases where
provisioning a single public identifier is expected to create very small
request and response sizes to cases where millions of data records are
submitted / retrieved in one transaction. Therefore, a transport
protocol suitable for SPPP MUST support a great variety of request and response sizes.
</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 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.
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: 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-1.0
</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>
This section will be provided in draft-01 which is intended to be published before July 13, 2009.
</t>
</section>
<section anchor="protocolcommands" title="Protocol Commands">
<t>
This section will be provided in draft-01 which is intended to be published before July 13, 2009.
</t>
</section>
<section anchor="securityconsiderations" title="Security Considerations">
<t>
The transport protocol section contains some security properties that the transport protocol must provide so that the data exchanged using SPPP can be confidential and exchanged between authenticated endpoints.
</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 extension namespace:
<vspace blankLines='0'/>
urn:ietf:params:xml:ns:sppp-1.0
<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 extension XML schema:
<vspace blankLines='0'/>
URI: urn:ietf:params:xml:ns:sppp:base: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="unsignedLong"/>
</simpleType>
<simpleType name="MinorVerType">
<restriction base="unsignedLong"/>
</simpleType>
<complexType name="BasicObjType">
<sequence>
<element name="rantId" type="spppb:OrgIdType"/>
<element name="rarId" type="spppb:OrgIdType"/>
<element name="activDate" type="dateTime"
minOccurs="0"/>
<element name="delDate" type="dateTime" minOccurs="0"/>
<element name="ext" type="spppb:ExtAnyType"
minOccurs="0"/>
</sequence>
</complexType>
<complexType name="BasicRspnsType">
<sequence>
<element name="resCode" type="int"/>
<element name="resMsg" type="string"/>
<element name="ext" type="spppb:ExtAnyType"
minOccurs="0"/>
</sequence>
</complexType>
<complexType name="BasicRqstType">
<sequence>
<element name="clientId" type="spppb:OrgIdType"/>
<element name="transId" type="spppb:TransIdType"/>
<element name="minorVer" type="spppb:MinorVerType"/>
<element name="ext" type="spppb:ExtAnyType"
minOccurs="0"/>
</sequence>
</complexType>
<complexType name="BasicQueryType">
<sequence>
<element name="clientId" type="spppb:OrgIdType"/>
<element name="minorVer" type="spppb:MinorVerType"/>
<element name="ext" type="spppb:ExtAnyType"
minOccurs="0"/>
</sequence>
</complexType>
<complexType name="IPAddrType">
<sequence>
<element name="addr" type="string"/>
<element name="type" type="spppb:IPType"/>
<element name="ext" type="spppb:ExtAnyType"
minOccurs="0"/>
</sequence>
</complexType>
<simpleType name="IPType">
<restriction base="token">
<enumeration value="IPv4"/>
<enumeration value="IPv6"/>
</restriction>
</simpleType>
<complexType name="SourceIdentType">
<sequence>
<element name="sourceIdentLabel" type="string"/>
<element name="sourceIdentScheme">
type="spppb:SourceIdentSchemeType"/>
<element name="ext" type="spppb:ExtAnyType"
minOccurs="0"/>
</sequence>
</complexType>
<simpleType name="SourceIdentSchemeType">
<restriction base="token">
<enumeration value="URI"/>
<enumeration value="IP"/>
<enumeration value="rootDomain"/>
</restriction>
</simpleType>
<complexType name="BatchUpdateType">
<sequence>
<element name="op" type="spppb:BatchOpType"
maxOccurs="unbounded"/>
</sequence>
</complexType>
<complexType name="BatchOpType">
<sequence>
<element name="rteGrpDel" type="string"
minOccurs="0" maxOccurs="unbounded"/>
<element name="rteGrpAdd" type="spppb:RteGrpType"
minOccurs="0" maxOccurs="unbounded"/>
<element name="destGrpDel" type="string" minOccurs="0>
" maxOccurs="unbounded"/>
<element name="destGrpAdd" type="spppb:DestGroupType"
minOccurs="0" maxOccurs="unbounded"/>
<element name="piDel" type="string" minOccurs="0">
maxOccurs="unbounded"/>
<element name="piAdd" type="spppb:PubIdType"
minOccurs="0" maxOccurs="unbounded"/>
<element name="tnRDel" type="string" minOccurs="0">
maxOccurs="unbounded"/>
<element name="tnRAdd" type="spppb:TNRType"
minOccurs="0" maxOccurs="unbounded"/>
</sequence>
</complexType>
<complexType name="SvcMenuType">
<sequence>
<element name="serverStatus"
type="spppb:ServerStatusType"/>
<element name="majMinVersion" type="string"
maxOccurs="unbounded"/>
<element name="objURI" type="anyURI"
maxOccurs="unbounded"/>
<element name="extURI" type="anyURI"
minOccurs="0" maxOccurs="unbounded"/>
</sequence>
</complexType>
<simpleType name="ServerStatusType">
<restriction base="token">
<enumeration value="inService"/>
<enumeration value="outOfService"/>
</restriction>
</simpleType>
<complexType name="ExtAnyType">
<sequence>
<any namespace="##other" maxOccurs="unbounded"/>
</sequence>
</complexType>
<annotation>
<documentation>
--- Wrapped Rqst Message Definitions ---
</documentation>
</annotation>
<element name="addRteGrpsRqst">
<complexType>
<sequence>
<element name="basicRqst" type="spppb:BasicRqstType"/>
<element name="rteGrp" type="spppb:RteGrpType">
maxOccurs="unbounded"/>
</sequence>
</complexType>
</element>
<element name="delRteGrpsRqst">
<complexType>
<sequence>
<element name="basicRqst" type="spppb:BasicRqstType"/>
<element name="name" type="string" maxOccurs="unbounded"/>
</sequence>
</complexType>
</element>
<element name="getRteGrpsRqst">
<complexType>
<sequence>
<element name="basicRqst" type="spppb:BasicQueryType"/>
<element name="name" type="string" maxOccurs="unbounded"/>
</sequence>
</complexType>
</element>
<element name="addDestGroupsRqst">
<complexType>
<sequence>
<element name="basicRqst" type="spppb:BasicRqstType"/>
<element name="destGroup" type="spppb:DestGroupType">
maxOccurs="unbounded"/>
</sequence>
</complexType>
</element>
<element name="delDestGroupsRqst">
<complexType>
<sequence>
<element name="basicRqst" type="spppb:BasicRqstType"/>
<element name="name" type="string" maxOccurs="unbounded"/>
</sequence>
</complexType>
</element>
<element name="getDestGroupsRqst">
<complexType>
<sequence>
<element name="basicRqst" type="spppb:BasicQueryType"/>
<element name="name" type="string" maxOccurs="unbounded"/>
</sequence>
</complexType>
</element>
<element name="addPubIdsRqst">
<complexType>
<sequence>
<element name="basicRqst" type="spppb:BasicRqstType"/>
<element name="pi" type="spppb:PubIdType" >
maxOccurs="unbounded"/>
</sequence>
</complexType>
</element>
<element name="delPubIdsRqst">
<complexType>
<sequence>
<element name="basicRqst" >
type="spppb:BasicRqstType"/>
<element name="name" type="string">
maxOccurs="unbounded"/>
</sequence>
</complexType>
</element>
<element name="getPubIdsRqst">
<complexType>
<sequence>
<element name="basicRqst" type="spppb:BasicQueryType"/>
<element name="name" type="string">
maxOccurs="unbounded"/>
</sequence>
</complexType>
</element>
<element name="addTNRsRqst">
<complexType>
<sequence>
<element name="basicRqst" type="spppb:BasicRqstType"/>
<element name="tnR" type="spppb:TNRType">
maxOccurs="unbounded"/>
</sequence>
</complexType>
</element>
<element name="delTNRsRqst">
<complexType>
<sequence>
<element name="basicRqst" type="spppb:BasicRqstType"/>
<element name="name" type="string">
maxOccurs="unbounded"/>
</sequence>
</complexType>
</element>
<element name="getTNRsRqst">
<complexType>
<sequence>
<element name="basicRqst" type="spppb:BasicQueryType"/>
<element name="name" type="string" maxOccurs="unbounded"/>
</sequence>
</complexType>
</element>
<element name="addNAPTRsRqst">
<complexType>
<sequence>
<element name="basicRqst" type="spppb:BasicRqstType"/>
<element name="naptr" type="spppb:NAPTRType">
maxOccurs="unbounded"/>
</sequence>
</complexType>
</element>
<element name="delNAPTRsRqst">
<complexType>
<sequence>
<element name="basicRqst" type="spppb:BasicRqstType"/>
<element name="name" type="string">
maxOccurs="unbounded"/>
</sequence>
</complexType>
</element>
<element name="getNAPTRsRqst">
<complexType>
<sequence>
<element name="basicRqst" type="spppb:BasicQueryType"/>
<element name="name" type="string" >
maxOccurs="unbounded"/>
</sequence>
</complexType>
</element>
<element name="addNSsRqst">
<complexType>
<sequence>
<element name="basicRqst" type="spppb:BasicRqstType"/>
<element name="naptr" type="spppb:NSType">
maxOccurs="unbounded"/>
</sequence>
</complexType>
</element>
<element name="delNSsRqst">
<complexType>
<sequence>
<element name="basicRqst" type="spppb:BasicRqstType"/>
<element name="name" type="string" maxOccurs="unbounded"/>
</sequence>
</complexType>
</element>
<element name="getNSsRqst">
<complexType>
<sequence>
<element name="basicRqst" type="spppb:BasicQueryType"/>
<element name="name" type="string" maxOccurs="unbounded"/>
</sequence>
</complexType>
</element>
<element name="batchUpdateRqst">
<complexType>
<sequence>
<element name="basicRqst" type="spppb:BasicRqstType"/>
<element name="batchUpdate" type="spppb:BatchUpdateType"/>
</sequence>
</complexType>
</element>
<element name="getSvcMenuRqst">
<complexType>
<sequence>
<element name="basicRqst" type="spppb:BasicQueryType"/>
</sequence>
</complexType>
</element>
<annotation>
<documentation>
--- Wrapped Rspns Message Definitions ---
</documentation>
</annotation>
<element name="getRteGrpsRspns">
<complexType>
<sequence>
<element name="rteGrp" type="spppb:RteGrpType">
minOccurs="0" maxOccurs="unbounded"/>
<element name="basicResult" type="spppb:BasicRspnsType"/>
</sequence>
</complexType>
</element>
<element name="getDestGroupsRspns">
<complexType>
<sequence>
<element name="destGroup" type="spppb:DestGroupType">
minOccurs="0" maxOccurs="unbounded"/>
<element name="basicResult" type="spppb:BasicRspnsType"/>
</sequence>
</complexType>
</element>
<element name="getPubIdsRspns">
<complexType>
<sequence>
<element name="pi" type="spppb:PubIdType">
minOccurs="0" maxOccurs="unbounded"/>
<element name="basicResult" type="spppb:BasicRspnsType"/>
</sequence>
</complexType>
</element>
<element name="getTNRsRspns">
<complexType>
<sequence>
<element name="tnR" type="spppb:TNRType">
minOccurs="0" maxOccurs="unbounded"/>
<element name="basicResult" type="spppb:BasicRspnsType"/>
</sequence>
</complexType>
</element>
<element name="getNAPTRsRspns">
<complexType>
<sequence>
<element name="naptr" type="spppb:NAPTRType">
minOccurs="0" maxOccurs="unbounded"/>
<element name="basicResult" type="spppb:BasicRspnsType"/>
</sequence>
</complexType>
</element>
<element name="getNSsRspns">
<complexType>
<sequence>
<element name="ns" type="spppb:NSType">
minOccurs="0" maxOccurs="unbounded"/>
<element name="basicResult" type="spppb:BasicRspnsType"/>
</sequence>
</complexType>
</element>
<element name="getSvcMenuRspns">
<complexType>
<sequence>
<element name="svcMenu" type="spppb:SvcMenuType"/>
<element name="basicResult" type="spppb:BasicRspnsType"/>
</sequence>
</complexType>
</element>
<element name="cmnRspns">
<complexType>
<sequence>
<element name="rspns" type="spppb:BasicRspnsType">
nillable="false"/>
</sequence>
</complexType>
</element>
<element name="spppRequest">
<complexType>
<sequence>
<any/>
</sequence>
</complexType>
</element>
<element name="spppResponse">
<complexType>
<sequence>
<any/>
</sequence>
</complexType>
</element>
</schema>
]]>
</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: 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, 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 advise, 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">
&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 16:09:19 |