One document matched: draft-ietf-drinks-sppp-over-soap-06.xml
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc3688 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.3688.xml">
<!ENTITY rfc5486 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.5486.xml">
<!ENTITY rfc5246 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.5246.xml">
<!ENTITY rfc2617 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.2617.xml">
<!ENTITY rfc2616 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.2616.xml">
<!ENTITY rfc2818 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.2818.xml">
<!ENTITY rfc5321 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.5321.xml">
]>
<rfc category="std" docName="draft-ietf-drinks-sppp-over-soap-06" 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-ietf-drinks-sppp-over-soap">SPPP Over SOAP and HTTP</title>
<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>
<date year="2011" month="October"/>
<area>Real-time Applications and Infrastructure Area</area>
<workgroup>DRINKS</workgroup>
<abstract>
<t>The Session Peering Provisioning Protocol (SPPP) is an XML protocol
that exists to enable the provisioning of session establishment data into
Session Data Registries or SIP Service Provider data stores. Sending XML
data structures over Simple Object Access Protocol (SOAP) and HTTP(s) is
a widely used, de-facto standard for messaging between elements of
provisioning systems. Therefore the combination of SOAP and HTTP(s) as
a transport for SPPP is a natural fit. The obvious benefits include
leveraging existing industry expertise, leveraging existing standards,
and a higher probability that existing provisioning systems can be more
easily integrated with this protocol. This document describes the
specification for transporting SPPP XML structures over SOAP and HTTP(s).
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>SPPP, defined in <xref target="I-D.draft-ietf-drinks-spprov"/>,
is best supported by a transport and messaging infrastructure
that is connection oriented, request-response oriented, easily secured,
supports propagation through firewalls in a standard fashion, and that
is easily integrated into back-office systems. This is due to the fact that
the client side of SPPP is likely to be integrated with organizations'
operational support systems that facilitate transactional provisioning of user
addresses and their associated session establishment data. While the server
side of SPPP is likely to reside in a separate organization's network, resulting
the SPPP provisioning transactions traversing the Internet as
they are propagated from the SPPP client to the SPPP server. Given the
current state of industry practice and technologies,
SOAP and HTTP(s) are well suited for this type of environment. This document
describes the specification for transporting SPPP XML structures over
SOAP and HTTP(s).</t>
<t>The specification in this document for transporting SPPP XML structures
over SOAP and HTTP(s) is primarily comprised of five subjects: (1) a
description of any applicable SOAP features, (2) any applicable HTTP
features, (3) security considerations, and perhaps most importantly,
(5) the Web Services Description Language (WSDL) definition for SPPP over
SOAP.</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>
</section>
<section anchor="SOAPFeatures" title="SOAP Features and Protocol Layering">
<t>The list of SOAP features that are explicitly used and required for SPPP are limited. Most SOAP features are not necessary for SPPP. SPPP primarily uses SOAP simply as a standard message envelope technology. The SOAP message envelope is comprised of the SOAP header and body. As described in the SOAP specifications, the SOAP header can contain optional, application specific, information about the message. The SOAP body contains the SPPP message itself, whose structure is defined by the combination of one of the WSDL operations defined in this document and the SPPP XML data structures defined in the SPPP protocol document. SPPP does not rely on any data elements in the SOAP header. All relevant data elements are defined in the SPPP XML schema described in <xref target="I-D.draft-ietf-drinks-spprov"/> and the SPPP WSDL specification described in this document.</t>
<t>WSDL is a widely standardized and adopted technology for defining the top-level structures of the messages that are transported within the body of a SOAP message. The WSDL definition for the SPPP SOAP messages is defined later in this document, which imports by reference the XML data types contained in the SPPP schema. The IANA registry where the SPPP schema resides is described in The IETF XML Registry <xref target="RFC3688"/>.</t>
<t>There are multiple structural styles that SOAP WSDL allows. But the best practice for this type of application is what is sometimes referred to as the Document Literal Wrapped style of designing SOAP WSDL. This style is generally regarded as an optimal approach that enhances maintainability, comprehension, portability, and, to a certain extent, performance. It is characterized by setting the soapAction binding style as _document_, the soapAction encoding style as _literal_, and then defining the SOAP messages to simply contain a single data element that _wraps_ that is a data structure containing all the required input or output data elements. The figure below illustrates this high level technical structure as conceptual layers 3 through 6.</t>
<figure anchor="TechnicalStructureofSPPP"
title="Layering and Technical Structure of the SPPP SOAP Messages">
<artwork align="left"><![CDATA[
+-------------+
(1) | Transport |Example:
| Protocol | TCP, TLS, BEEP, etc.
+-------------+
|
V
+-------------+
(2) | Message |Example:
| Envelope | HTTP, SOAP, None, etc.
+-------------+
|
V
+--------------+
+------| SOAP |-----+
| (3) | Operation | |
Contains | +--------------+ | Contains
| Example: |
V submitUpdateRqst V
+--------------+ +-------------+
|SOAP Request | |SOAP Response|
Example:| Message | (4) | Message | Example:
spppUpdate | (Operation | | (Operation |spppUpdate
RequestMsg | Input) | | Output) | ResponseMsg
+--------------+ +-------------+
| |
Contains | | Contains
| |
V V
+---------------+ +---------------+
Example:| Wrapped | (5) | Wrapped | Example:
spppUpdate |Request Object | |Response Object| spppUpdate
Request +---------------+ +---------------+ Response
| |
Contains | | Contains
| |
V V
+----------+ +-----------+
Example: | SPPP | | SPPP |
AddRteGrp |XML Types | (6) | XML Types |
RqstType +----------+ +-----------+
]]></artwork>
</figure>
<t>The SOAP operations supported by SPPP are normatively defined later in this
document. Each SOAP operation defines a request/input message and a
response/output message. Each such request and response message then
contains a single object that wraps the SPPP XML data types that comprise
the inputs and the outputs, respectively, of the SOAP operation.</t>
<t>SOAP faults are not used by the SPPP SOAP mapping. All SPPP success
and error responses are specified within the SPPP protocol specification
<xref target="I-D.draft-ietf-drinks-spprov"/>. However, if a SOAP fault were
to occur, perhaps due to failures in the SOAP message handling layer of a SOAP
library, the client application should capture and handle the fault. Specifics
on how to handle such SOAP faults, if they should occur, will be specific to
the chosen SOAP implementation. </t>
<t>SOAP 1.2 <xref target="SOAPREF"/> or higher and WSDL 1.1 <xref target="WSDLREF"/> or higher SHOULD be used.</t>
<t> SPPP is a 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. Concerns regarding encryption,
non-repudiation, and authentication are beyond the scope of
this document. For more details, please refer to the
Transport Protocol Requirements section. </t>
<t> As illustrated in the previous diagram, SPPP can be viewed as
a set of layers that collectively
define the structure of an SPPP request and response. Layers
1 and 2 represent the transport, envelope, and authentication
technologies. This
document defines layers 3, 4, and 5 below. </t>
<t>
<list style="numbers">
<t> Layer 1: The transport protocol layer represents the 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. But this document specifies the required
mechanism.</t>
<t> Layer 2: The message envelope layer is optional, but can
provide features that are above the transport technology
layer but below the application messaging layer.
Technologies such as HTTP and SOAP are examples of
messaging envelope technologies. This document specifies the required
envelope technology.</t>
<t> Layers 3,4,5,6: The operation and message layers provides an
envelope-independent and transport-independent
wrapper for the SPPP data model objects that are being acted on (created,
modified, queried). </t>
</list>
</t>
</section>
<section anchor="HTTPFeatures" title="HTTP(s) Features and SPPP">
<t>SOAP is not tied to HTTP(s), however, for reasons described in the
introduction, HTTP(s) is a good choice as the transport mechanism for
the SPPP SOAP messages. HTTP 1.1 includes the "persistent connection"
feature, which allows multiple HTTP request/response pairs to be transported
across a single HTTP connection. This is an important performance
optimization feature, particularly when the connections is an HTTPS
connection where the relatively time consuming SSL handshake has occurred.
Persistent connections SHOULD be used for the SPPP HTTP connections.</t>
<t>HTTP 1.1 <xref target="RFC2616"/> or higher SHOULD be used.</t>
</section>
<section anchor="AuthenticationSessionManagement" title="Authentication and Session Management">
<t>To achieve integrity and privacy, conforming SPPP SOAP Clients and Servers MUST support SOAP over HTTP over TLS <xref target="RFC5246"/> as the secure transport mechanism. This combination of HTTP and TLS is referred to as HTTPS. And to accomplish authentication, conforming SOAP SPPP Clients and Servers MUST use HTTP Digest Authentication as defined in <xref target="RFC2617"/>. As a result, the communication session is established through the initial HTTP connection setup, the digest authentication, and the TLS handshake. When the HTTP connection is broken down, the communication session ends.</t>
</section>
<section anchor="basicdatastructures" title="Base Protocol Data Structures">
<t>SPPP uses a common model and a common set of
data structures for most of the supported operations.
This section describes these common operation data structures.</t>
<section anchor="requestandresponse" title="Request and Response Structures">
<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. There are two generalized types of operations that an SPPP
client can submit to an SPPP server, updates and queries. The following
two sub-sections describe the generalized data structures that are
used for each of these two types of operations. </t>
<section anchor="updates" title="Update Request and Response Structures">
<t>An SPPP update request is wrapped within the
<![CDATA[<spppUpdateRequest> ]]> element while an SPPP update response is
wrapped within an <![CDATA[<spppUpdateResponse>]]> element.
The following two sub-sections describe these two elements.</t>
<section anchor="updaterequest" title="Update Request">
<t> An SPPP update request object is contained within the generic
<![CDATA[<spppUpdateRequest>]]> element. </t>
<t>
<figure title="">
<artwork align="left">
<![CDATA[
<element name="spppUpdateRequest">
<complexType>
<sequence>
<element name="clientTransId" type="spppb:TransIdType"
minOccurs="0"/>
<element name="minorVer" type="spppb:MinorVerType"
minOccurs="0"/>
<element name="rqst" type="spppb:BasicUpdateRqstType"
maxOccurs="unbounded"/>
</sequence>
</complexType>
</element>
<simpleType name="TransIdType">
<restriction base="string"/>
</simpleType>
<simpleType name="MinorVerType">
<restriction base="unsignedLong"/>
</simpleType>
]]>
</artwork>
</figure>
</t>
<t> The data elements within the <![CDATA[<spppUpdateRequest>]]>
element are described as follows:
<list style="symbols" hangIndent="5">
<t> clientTransId: Zero or one client-generated transaction ID
that, within the context of the SPPP client, identifies this
request. This value can be used at the discretion of the SPPP
client to track, log or correlate requests and their responses. SPPP server MUST echo back this value to the client in the corresponding response to the incoming request.
SPPP server will not check this value for uniqueness. </t>
<t> minorVer: Zero or one minor version identifier, indicating 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 to identify the version of SPPP that the client
is using. If the element is not present, the server assumes that
the client is using the latest minor version supported by the SPPP
server for the given major version. The versions supported by a
given SPPP server can be retrieved by the client using the
SPPP server menu operation described later in the document.</t>
<t> rqst: One or more BasicUpdateRqstType objects. These are the actions
that the client is requesting the SPPP server perform. They are processed
by the SPPP server in the order in which they are included in the request.
And with respect to handling error conditions, it is a matter of policy
whether the objects are processed in a "stop and rollback" fashion or
in a "stop and commit" fashion. In the "stop and rollback" scenario,
the SPPP server would stop processing BasicUpdateRqstType object instances in the
request at the first error and roll back any BasicUpdateRqstType object instances
that had already been processed for that update request.
In the "stop and commit" scenario the SPPP server would stop
processing BasicUpdateRqstType object instances in the request at the
first error but commit any BasicUpdateRqstType object instances
that had already been processed for that update request.
</t>
</list>
</t>
<t> All update request objects extend the base type BasicUpdateRqstType. This
base type is defined as follows: </t>
<t>
<figure title="">
<artwork align="left">
<![CDATA[
<complexType name="BasicUpdateRqstType" abstract="true">
<sequence>
<element name="ext" type="spppb:ExtAnyType" minOccurs="0"/>
</sequence>
</complexType>
]]>
</artwork>
</figure>
</t>
<t> The BasicUpdateRqstType object primarily acts as an abstract base type,
and its only data element is described as follows:
<list style="symbols" hangIndent="5">
<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="updateresponse" title="Update Response">
<t> An SPPP update response object is contained within the generic
<![CDATA[<spppUpdateResponse>]]> element. </t>
<t>
<figure title="">
<artwork align="left">
<![CDATA[
<element name="spppUpdateResponse">
<complexType>
<sequence>
<element name="overallResult" type="spppb:ResultCodeType"/>
<element name="rqstObjResult" type="spppb:RqstObjResultCodeType"
minOccurs="0" maxOccurs="unbounded"/>
<element name="clientTransId" type="spppb:TransIdType"
minOccurs="0"/>
<element name="serverTransId" type="spppb:TransIdType"/>
</sequence>
</complexType>
</element>
<complexType name="ResultCodeType">
<sequence>
<element name="code" type="int"/>
<element name="msg" type="string"/>
</sequence>
</complexType>
<complexType name="RqstObjResultCodeType">
<complexContent>
<extension base="spppb:ResultCodeType">
<sequence>
<element name="rqstObj" type="spppb:BasicUpdateRqstType"/>
</sequence>
</extension>
</complexContent>
</complexType>
]]>
</artwork>
</figure>
</t>
<t> An <![CDATA[<spppUpdateResponse>]]> contains the
elements necessary for the SPPP client to precisely determine the
overall result of the request, and if an error occurred, it provides
information about the specific object, data element, or condition
caused the error. </t>
<t> The data elements within the SPPP update response are
described as follows: <list style="symbols" hangIndent="5">
<t> clientTransId: Zero or one client transaction ID. This
value is simply an echo of the client transaction ID that
SPPP client passed into the SPPP update request. When included
in the request, the SPPP server MUST return it in the corresponding
response message.</t>
<t> serverTransId: Exactly one server transaction ID that
identifies this request for tracking purposes. This
value MUST be unique for a given SPPP server. </t>
<t> overallResult: Exactly one response code and message pair that
explicitly identifies the result of the request. See the
Response Code section for further details. </t>
<t> rqstObjResult: An optional response code, response message,
and BasicRqstObject triplet. This element will be present only if an object level error has occurred. It indicates the error condition and the exact request object that contributed to the error. The response code will reflect the exact error. 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="queries" title="Query Request and Response Structures">
<t>At times, on behalf of the registrant, the registrar may need to have access to SPPP objects that were previously provisioned in the registry. A few examples include logging, auditing, and pre-provisioning dependency checking. This query mechanism is limited to aid provisioning scenarios and should not be confused with query protocols provided as part of the resolution system (e.g. ENUM and SIP).</t>
<t>An SPPP query request is wrapped within the
<![CDATA[<spppQueryRequest> ]]> element while an SPPP query response is
wrapped within an <![CDATA[<spppQueryResponse>]]> element.
The following two sub-sections describe these two element structures.</t>
<section anchor="queryrequest" title="Query Request">
<t> An SPPP query request object is contained within the generic
<![CDATA[<spppQueryRequest>]]> element. </t>
<t>
<figure title="">
<artwork align="left">
<![CDATA[
<element name="spppQueryRequest">
<complexType>
<sequence>
<element name="minorVer" type="spppb:MinorVerType"
minOccurs="0"/>
<element name="rqst" type="spppb:BasicQueryRqstType"/>
</sequence>
</complexType>
</element>
]]>
</artwork>
</figure>
</t>
<t> The data elements within the <![CDATA[<spppQueryRequest>]]>
element are described as follows:
<list style="symbols" hangIndent="5">
<t> minorVer: Zero or one minor version identifier, indicating 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 to identify the version of SPPP that the client
is using. If the element is not present, the server assumes that
the client is using the latest minor version supported by the SPPP
server for the given major version. The versions supported by a
given SPPP server can be retrieved by the client using the
SPPP server menu operation described later in the document.</t>
<t> rqst: One BasicQueryRqstType objects. This is the query
that the client is requesting the SPPP server perform.
</t>
</list>
</t>
<t> All query request objects extend the base type BasicQueryRqstType. This
base type is defined as follows: </t>
<t>
<figure title="">
<artwork align="left">
<![CDATA[
<complexType name="BasicQueryRqstType" abstract="true">
<sequence>
<element name="ext" type="spppb:ExtAnyType" minOccurs="0"/>
</sequence>
</complexType>
]]>
</artwork>
</figure>
</t>
<t> The BasicQueryRqstType object primarily acts as an abstract base type,
and its only data element is described as follows:
<list style="symbols" hangIndent="5">
<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="queryresponse" title="Query Response">
<t> An SPPP query response object is contained within the generic
<![CDATA[<spppQueryResponse>]]> element. </t>
<t>
<figure title="">
<artwork align="left">
<![CDATA[
<element name="spppQueryResponse">
<complexType>
<sequence>
<element name="overallResult" type="spppb:ResultCodeType"/>
<element name="resultSet" type="spppb:BasicObjType"
minOccurs="0" maxOccurs=" unbounded"/>
</sequence>
</complexType>
</element>
]]>
</artwork>
</figure>
</t>
<t> An <![CDATA[<spppQueryResponse>]]> contains the
elements necessary for the SPPP client to precisely determine the
overall result of the query, and if an error occurred, exactly
what condition caused the error. </t>
<t> The data elements within the SPPP query response are
described as follows: <list style="symbols" hangIndent="5">
<t> overallResult: Exactly one response code and message pair that
explicitly identifies the result of the request. See the
Response Code section for further details. </t>
<t> resultSet: The set of zero or more objects that matched the
query criteria. If no objects matched the query criteria then this
result set MUST be empty and the overallResult value MUST indicate
success (if no matches are found for the query criteria, the
response is considered a success).</t>
</list>
</t>
</section>
</section>
</section>
<section anchor="resultcodes" title="Response Codes and Messages">
<t> This section contains the 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="RFC5321"/>:
<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>
<t> The response codes are also categorized as to whether they are
overall response codes that may only be returned in the "overallResult"
data element in SPPP responses, of object level response codes that
may only be returned in the "rqstObjResult" element of the SPPP
responses.</t>
<texttable anchor="Table1"
title="Response Codes Numbering Scheme and Messages">
<ttcol align="left" width="10%">Result Code</ttcol>
<ttcol align="left" width="30%">Result Message</ttcol>
<ttcol align="left" width="60%">Overall or Object Level</ttcol>
<c> 1000 </c>
<c> Request Succeeded.</c>
<c> Overall Response Code</c>
<c> 2001 </c>
<c> Request syntax invalid.</c>
<c> Overall Response Code</c>
<c> 2002 </c>
<c> Request too large.</c>
<c> Overall Response Code</c>
<c> 2003 </c>
<c> Version not supported.</c>
<c> Overall Response Code</c>
<c> 2103 </c>
<c> Command invalid.</c>
<c> Overall Response Code</c>
<c> 2301 </c>
<c> System temporarily unavailable.</c>
<c> Overall Response Code</c>
<c> 2302 </c>
<c> Unexpected internal system or server error.</c>
<c> Overall Response Code</c>
<c> 2104 </c>
<c> Attribute value invalid. AttrName:[AttributeName] AttrVal:[AttributeValue]</c>
<c> Object Level Response Code</c>
<c> 2105 </c>
<c> Object does not exist. AttrName:[AttributeName] AttrVal:[AttributeValue]</c>
<c> Object Level Response Code</c>
<c> 2106 </c>
<c> Object status or ownership does not allow for operation. AttrName:[AttributeName]
AttrVal:[AttributeValue]</c>
<c> Object Level Response Code</c>
</texttable>
<t> Each of the object level response messages are "parameterized" with the
following parameters: "AttributeName" and "AttributeValue". </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. </t>
<t hangText=""> Any value provided for the "AttributeName"
parameter MUST be an exact XSD element name of the protocol
data element that the response message is referring to.
For example, valid values for "attribute name" are
"dgName", "rgName", "rteRec", etc. </t>
<t hangText=""> The value for "AttributeValue" MUST be the
value of the data element to which the preceding
"AttributeName" 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
by an update operation 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>
<section anchor="protocolcommands" title="Protocol Operations">
<t> This section provides a description of the specification of each required
operation (verb) for each SPPP data model object (the noun).
The specification of the data structures for the data model objects is contianed in the
protocol specification.</t>
<section anchor="adddestgrp" title="Add Destination Group Operation">
<t> The AddDestGrpRqstType operation creates or overwrites a Destination
Group object. If a Destination Group with the given
name and registrant ID (which together comprise the unique key for a
Destination Group) does not exist, then the server MUST
create the Destination Group. If a Destination Group with the given name
and registrant ID does exist, then the server MUST replace the
current properties of the Destination Group with the properties
passed into the AddDestGrpsRqstType operation. The XSD
declarations of the operation request object are as follows: </t>
<t>
<figure title="">
<artwork align="left">
<![CDATA[
<complexType name="AddDestGrpRqstType">
<complexContent>
<extension base="spppb:BasicUpdateRqstType">
<sequence>
<element name="destGrp" type="spppb:DestGrpType"/>
</sequence>
</extension>
</complexContent>
</complexType>
]]>
</artwork>
</figure>
</t>
<t> The element passed into the spppUpdateRequest element for this
operation is an element of type AddDestGrpRqsttype, which extends
BasicUpdateRqstType and contains a DestGrpType object. </t>
<t>As with the responses to all update operations, the result
of the AddDestGrpRqstType operation is contained in the generic
spppUpdateResponse data structure described in an earlier sections
of this document. For a detailed description of the
spppUpdateResponse data structure refer to that section of the
document.</t>
</section>
<section anchor="getdestgrps" title="Get Destination Groups Operation">
<t> The getDestGrpsRqst operation allows an SPPP client to get the
properties of Destination Group objects that a registrar is authorized
to view on behalf of the registrant. The server will attempt
to find a Destination Group object that has the registrant ID and
destination group name pair contained in each ObjKeyType object
instance. If there are no matching Destination Groups found then
an empty result set will be returned.</t>
<t> The element passed into the spppQueryRequest element for this
operation is an instance of type GetDestGrpsRqstType, which
extends BasicQueryRqstType and contains zero or more ObjKeyType
objects. Any limitation on the maximum number of objects that
may be passed into or returned by this operation is a policy
decision and not limited by the protocol. The XSD declaration
of the operation is as follows: </t>
<t>
<figure title="">
<artwork align="left">
<![CDATA[
<complexType name="GetDestGrpsRqstType">
<complexContent>
<extension base="spppb:BasicQueryRqstType">
<sequence>
<element name="objKey" type="spppb:ObjKeyType"
maxOccurs="unbounded"/>
</sequence>
</extension>
</complexContent>
</complexType>
]]>
</artwork>
</figure>
</t>
<t>As described in an earlier section of this document, the result
of any spppQueryRequest operation is an spppQueryResponse element
that contains the overall response code and the query result set, if
any. Refer to that section of the document for a detailed description
of the spppQueryResponse element.</t>
</section>
<section anchor="addpubIdsOper" title="Add Public Identifier Operation">
<t> The AddPubIdRqstType operation creates or overwrites a Public Identifier
object of any of the concrete types specified in the protocol data model
specification. If a Public Identifier with the given identity (refer to the data model
specification for the definition of how Public Identifiers are uniquely
identified) does not exist, then the server MUST
create the Public Identifier. If a Public Identifier with the given identity
does exist, then the server MUST replace the
current properties of that Public Identifier with the properties
passed into the AddPubIdRqstType operation. The XSD
declarations of the operation request object are as follows: </t>
<t>
<figure title="">
<artwork align="left">
<![CDATA[
<complexType name="AddPubIdRqstType">
<complexContent>
<extension base="spppb:BasicUpdateRqstType">
<sequence>
<element name="pi" type="spppb:PubIdType"/>
</sequence>
</extension>
</complexContent>
</complexType>
]]>
</artwork>
</figure>
</t>
</section>
<section anchor="getpubIdsOper" title="Get Public Identifiers Operation">
<t> The GetPubIdsRqstType operation allows an SPPP client to get the
properties of Public Identifier objects that a registrar is authorized
to view on behalf of the registrant. The server will attempt
to find a Public Identifier object that has the properties of the
Public Identifier object passed into this operation. If there are no
matching Public Identifiers found then an empty result set will be
returned. </t>
<t> The element passed into the spppQueryRequest element for this
operation is an instance of type GetPubIdsRqstType, which
extends BasicQueryRqstType and contains one or more PubIDType
objects. Any limitation on the maximum number of objects that
may be passed into or returned by this operation is a policy
decision and not limited by the protocol. The XSD declaration
of the operation is as follows: </t>
<t>
<figure title="">
<artwork align="left">
<![CDATA[
<complexType name="GetPubIdsRqstType">
<complexContent>
<extension base="spppb:BasicQueryRqstType">
<sequence>
<element name="pi" type="spppb:PubIdType"
maxOccurs="unbounded"/>
</sequence>
</extension>
</complexContent>
</complexType>
]]>
</artwork>
</figure>
</t>
<t>As described earlier in the document, the result
of any spppQueryRequest operation is a spppQueryResponse
that contains the response code and the query result set, if
any.</t>
</section>
<section anchor="addrtegrp" title="Add Route Group Operation">
<t> The AddRteGrpRqstType operation creates or overwrites a Route
Group object. If a Route Group with the given
name and registrant ID (which together comprise the unique key
or a Route Group) does not exist, then the server MUST
create the Route Group. If a Route Group with the given name
and registrant ID does exist, then the server MUST replace the
current properties of the Route Group with the properties
passed into the AddRteGrpRqstType operation. The XSD
declarations of the AddRteGrpRqstType operation request object
are as follows: </t>
<t>
<figure title="">
<artwork align="left">
<![CDATA[
<complexType name="AddRteGrpRqstType">
<complexContent>
<extension base="spppb:BasicUpdateRqstType">
<sequence>
<element name="rteGrp" type="spppb:RteGrpType"/>
</sequence>
</extension>
</complexContent>
</complexType>
]]>
</artwork>
</figure>
</t>
<t> The element passed into the spppUpdateRequest element for this
operation is an instance of AddRteGrpRqstType, which extends
BasicUpdateRqstType and contains one RteGrpType object. </t>
</section>
<section anchor="getroutegrps" title="Get Route Groups Operation">
<t> The getRteGrpsRqst operation allows an SPPP client to get the
properties of Route Group objects that the registrar is authorized
to view on behalf of the registrant. The server will attempt
to find a Route Group object that has the registrant ID and
route group name pair contained in each ObjKeyType object
instance passed into this operation. If there are no
matching Route Groups found then an empty result set will be
returned. </t>
<t> The element passed into the spppQueryRequest element for this
operation is an instance of type GetRteGrpsRqstType, which
extends BasicUpdateRqstType and contains zero or more ObjKeyType
objects. Any limitation on the maximum number of objects that
may be passed into or returned by this operation is a policy
decision and not limited by the protocol. The XSD declaration
of the operation is as follows: </t>
<t>
<figure title="">
<artwork align="left">
<![CDATA[
<complexType name="GetRteGrpsRqstType">
<complexContent>
<extension base="spppb:BasicQueryRqstType">
<sequence>
<element name="objKey" type="spppb:ObjKeyType"
maxOccurs="unbounded"/>
</sequence>
</extension>
</complexContent>
</complexType>
]]>
</artwork>
</figure>
</t>
<t>As described in an earlier section of this document, the result
of any spppQueryRequest operation is an spppQueryResponse element
that contains the overall response code and the query result set, if
any. Refer to that section of the document for a detailed description
of the spppQueryResponse element.</t>
</section>
<section anchor="addrterec" title="Add Route Record Operation">
<t> The AddRteRecRqstType operation creates or overwrites a Route
Record object. If a Route Record with the given
name and registrant ID (which together comprise the unique key
or a Route Record) does not exist, then the server MUST
create the Route Record. If a Route Record with the given name
and registrant ID does exist, then the server MUST replace the
current properties of the Route Record with the properties
passed into the AddRteRecRqstType operation. The XSD
declarations of the AddRteRecRqstType operation request object
are as follows: </t>
<t>
<figure title="">
<artwork align="left">
<![CDATA[
<complexType name="AddRteRecRqstType">
<complexContent>
<extension base="spppb:BasicUpdateRqstType">
<sequence>
<element name="rteRec" type="spppb:RteRecType"/>
</sequence>
</extension>
</complexContent>
</complexType>
]]>
</artwork>
</figure>
</t>
<t> The element passed into the spppUpdateRequest element for this
operation is an instance of AddRteRecRqstType, which extends
BasicUpdateRqstType and contains one RteRecType object. </t>
<t>As with the responses to all update operations, the result
of the AddRteRecRqstType operation is contained in the generic
spppUpdateResponse data structure described in an earlier sections
of this document. For a detailed description of the
spppUpdateResponse data structure refer to that section of the
document.</t>
</section>
<section anchor="getrterecs" title="Get Route Records Operation">
<t> The getRteRecsRqst operation allows an SPPP client to get the
properties of Route Record objects that a registrar is authorized
to view on behalf of the registrant. The server will attempt
to find a Route Record object that has the registrant ID and
route record name pair contained in each ObjKeyType object
instance. If there are no matching Route Record found then an empty
result set will be returned. </t>
<t> The element passed into the spppQueryRequest element for this
operation is an instance of type GetRteRecsRqstType, which
extends BasicUpdateRqstType and contains zero or more ObjKeyType
objects. Any limitation on the maximum number of objects that
may be passed into or returned by this operation is a policy
decision and not limited by the protocol. The XSD declaration
of the operation is as follows: </t>
<t>
<figure title="">
<artwork align="left">
<![CDATA[
<complexType name="GetRteRecsRqstType">
<complexContent>
<extension base="spppb:BasicQueryRqstType">
<sequence>
<element name="objKey" type="spppb:ObjKeyType"
maxOccurs="unbounded"/>
</sequence>
</extension>
</complexContent>
</complexType>
]]>
</artwork>
</figure>
</t>
<t>As described in an earlier section of this document, the result
of any spppQueryRequest operation is an spppQueryResponse element
that contains the overall response code and the query result set, if
any. Refer to that section of the document for a detailed description
of the spppQueryResponse element.</t>
</section>
<section anchor="addrtegrpoffer" title="Add Route Group Offer Operation">
<t> The AddRteGrpOffersRqstType operation creates or overwrites one or
more Route Group Offer objects. If a Route Group Offer for the given Route Group
object key and the <![CDATA[<offeredTo>]]> Org ID does not exist, then the
server creates the Route Group Offer object. If a such a
Route Group Offer does exist, then the server replaces the
current object with the new object. The XSD declarations of
the operation request object are as follows: </t>
<t>
<figure title="">
<artwork align="left">
<![CDATA[
<complexType name="AddRteGrpOfferRqstType">
<complexContent>
<extension base="spppb:BasicUpdateRqstType">
<sequence>
<element name="rteGrpOffer" type="spppb:RteGrpOfferType"/>
</sequence>
</extension>
</complexContent>
</complexType>
]]>
</artwork>
</figure>
</t>
<t> The element passed into the spppUpdateRequest element for this
operation is an instance of AddRteGrpOfferRqstType, which extends
BasicUpdateRqstType and contains a RteGrpOfferType object. </t>
<t>As with the responses to all update operations, the result
of the AddRteGrpOfferRqstType operation is contained in the generic
spppUpdateResponse data structure described in an earlier sections
of this document. For a detailed description of the
spppUpdateResponse data structure refer to that section of the
document.</t>
</section>
<section anchor="accrtegrpoff" title="Accept Route Group Offer Operation">
<t> The AcceptRteGrpOffersRqstType operation is called by, or on behalf
of, the data recipient to accept a Route Group
Offer that is pending in the "offered" status for the data
recipient's organization ID. If a Route Group Offer for the
given Route Group Offer key (route name, route registrant
ID, data recipient's organization ID) exists, then the
server moves the Route Group Offer to the "accepted" status
and adds that data recipient's organization ID into the list
of peerOrgIds for that Route Group. If a such a Route Group
Offer does not exist, then the server returns the
appropriate error code, 2105. The XSD declarations for the
operation request object are as follows: </t>
<t>
<figure title="">
<artwork align="left">
<![CDATA[
<complexType name="AcceptRteGrpOfferRqstType">
<complexContent>
<extension base="spppb:BasicUpdateRqstType">
<sequence>
<element name="rteGrpOfferKey" type="spppb:RteGrpOfferKeyType"/>
</sequence>
</extension>
</complexContent>
</complexType>
]]>
</artwork>
</figure>
</t>
<t>The element passed into the spppUpdateRequest element for this
operation is an instance of AcceptRteGrpOffersRqstType, which extends
BasicUpdateRqstType and contains a RteGrpOfferKeyType object.</t>
<t>As with the responses to all update operations, the result
of the AcceptRteGrpOfferRqstType operation is contained in the generic
spppUpdateResponse data structure described in an earlier sections
of this document. For a detailed description of the
spppUpdateResponse data structure refer to that section of the
document.</t>
</section>
<section anchor="rejrtegrpoff" title="Reject Route Group Offer Operation">
<t> The RejectRteGrpOffersRqstType operation is used
for these purposes and is called by, or on behalf of, the data
recipient to accept a Route Group Offer that is
pending in the "offered" status or is in the "accepted" status for
the data recipient's organization ID. If a Route Group Offer
for the given Route Group Offer key (route name, route
registrant ID, data recipient's organization ID) exists in
either the offered or accepted status, then the server
deletes that Route Group Offer object, and, if appropriate,
removes the data recipient's organization ID from the list of
peeringOrg IDs for that Route Group. If the Route Group Offer
does not exist, then the server returns the appropriate
error code, 2105. The XSD declarations for the operation
request object are as follows: </t>
<t>
<figure title="">
<artwork align="left">
<![CDATA[
<complexType name="RejectRteGrpOfferRqstType">
<complexContent>
<extension base="spppb:BasicUpdateRqstType">
<sequence>
<element name="rteGrpOfferKey" type="spppb:RteGrpOfferKeyType"/>
</sequence>
</extension>
</complexContent>
</complexType>
]]>
</artwork>
</figure>
</t>
<t>The element passed into the spppUpdateRequest element for this
operation is an instance of RejectRteGrpOffersRqstType, which extends
BasicUpdateRqstType and contains a RteGrpOfferKeyType object.</t>
<t>As with the responses to all update operations, the result
of the RejectRteGrpOfferRqstType operation is contained in the generic
spppUpdateResponse data structure described in an earlier sections
of this document. For a detailed description of the
spppUpdateResponse data structure refer to that section of the
document.</t>
</section>
<section anchor="getrtegrpoff" title="Get Route Group Offers Operation">
<t> The getRteGrpOffersRqst operation allows an SPPP client to get
the properties of zero or more Route Group Offer objects that registrar
is authorized to view on behalf of the registrant. The server will
attempt to find Route Group Offer objects that have all the
properties specified in the criteria passed into the
operation. If there are no matching Route Group Offers found then an
empty result set will be returned. </t>
<t> The element passed into the spppQueryRequest element for this
operation is an instance of GetRteGrpOffersRqstType, which extends
BasicQueryRqstType and contains the criteria that the
returned Route Group Offer objects must match. Any limitation
on the maximum number of objects that may be
returned by this operation is a policy decision and not
limited by the protocol. The XSD declaration of the
operation is as follows: </t>
<t>
<figure title="">
<artwork align="left">
<![CDATA[
<complexType name="GetRteGrpOffersRqstType">
<complexContent>
<extension base="spppb:BasicQueryRqstType">
<sequence>
<element name="offeredBy" type="spppb:OrgIdType"
minOccurs="0" maxOccurs="unbounded"/>
<element name="offeredTo" type="spppb:OrgIdType"
minOccurs="0" maxOccurs="unbounded"/>
<element name="status" type="spppb:RteGrpOfferStatusType"
minOccurs="0"/>
<element name="rteGrpOfferKey"
type="spppb:RteGrpOfferKeyType" minOccurs="0"
maxOccurs="unbounded"/>
</sequence>
</extension>
</complexContent>
</complexType>
]]>
</artwork>
</figure>
</t>
<t>The GetRteGrpOffersRqstType object is composed of the
following elements: <list style="symbols" hangIndent="5">
<t> offeredBy: Zero or more organization IDs. Only offers
that are offered to the organization IDs
in this list should be included in the result set. The
result set is also subject to other query criteria in
the request.
</t>
<t> offeredTo: Zero or more organization IDs. Only offers
that are offered by the organization IDs
in this list should be included in the result set. The
result set is also subject to other query criteria in
the request.
</t>
<t> status: The status of the offer, offered or accepted.
Only offers in the specified status should be included
in the result set. If this element is not present then
the status of the offer should not be considered in the
query. The result set is also subject to other query
criteria in the request. </t>
<t> rteGrpOfferKey: Zero or more Route Group Offer Keys.
Only offers having one of these keys should be included
in the result set. The result set is also subject to
other query criteria in the request. </t>
</list>
</t>
<t>As described in an earlier section of this document, the result
of any spppQueryRequest operation is an spppQueryResponse element
that contains the overall response code and the query result set, if
any. Refer to that section of the document for a detailed description
of the spppQueryResponse element.</t>
</section>
<section anchor="egressRteOper" title="Add Egress Route Operation">
<t> The AddEgrRteRqstType operation creates or overwrites an Egress Route
object. If an Egress Route with the given
name and registrant ID (which together comprise the unique key
or an Egress Route) does not exist, then the server MUST
create the Route Record. If a Route Record with the given name
and registrant ID does exist, then the server MUST replace the
current properties of the Route Record with the properties
passed into the AddEgrRteRqstType operation. The XSD
declarations of the AddEgrRteRqstType operation request object
are as follows: </t>
<t>
<figure title="">
<artwork align="left">
<![CDATA[
<complexType name="AddEgrRteRqstType">
<complexContent>
<extension base="spppb:BasicUpdateRqstType">
<sequence>
<element name="egrRte" type="spppb:EgrRteType"/>
</sequence>
</extension>
</complexContent>
</complexType>
]]>
</artwork>
</figure>
</t>
<t> The element passed into the spppUpdateRequest element for this
operation is an instance of AddEgrRteRqstType, which extends
BasicUpdateRqstType and contains one EgrRteType object. </t>
<t>As with the responses to all update operations, the result
of the AddEgrRteRqstType operation is contained in the generic
spppUpdateResponse data structure described in an earlier sections
of this document. For a detailed description of the
spppUpdateResponse data structure refer to that section of the
document.</t>
</section>
<section anchor="getegrtes" title="Get Egress Routes Operation">
<t> The GetEgrRtesRqstType operation allows an SPPP client to get the
properties of Egress Route objects that a registrar is authorized
to view on behalf of the registrant. The server will attempt
to find a Egress Route object that has the registrant ID and
Egress Route name pair contained in each ObjKeyType object
instance. If there are no matching Egress Routes found then an empty
result set will be returned. </t>
<t> The element passed into the spppQueryRequest element for this
operation is an instance of type GetEgrRtesRqstType, which
extends BasicUpdateRqstType and contains zero or more ObjKeyType
objects. Any limitation on the maximum number of objects that
may be passed into or returned by this operation is a policy
decision and not limited by the protocol. The XSD declaration
of the operation is as follows: </t>
<t>
<figure title="">
<artwork align="left">
<![CDATA[
<complexType name="GetEgrRtesRqstType">
<complexContent>
<extension base="spppb:BasicQueryRqstType">
<sequence>
<element name="objKey" type="spppb:ObjKeyType"
maxOccurs="unbounded"/>
</sequence>
</extension>
</complexContent>
</complexType>
]]>
</artwork>
</figure>
</t>
<t>As described in an earlier section of this document, the result
of any spppQueryRequest operation is an spppQueryResponse element
that contains the overall response code and the query result set, if
any. Refer to that section of the document for a detailed description
of the spppQueryResponse element.</t>
</section>
<section anchor="delete_oper" title="Delete Operation">
<t>In order to remove an object from the registry, an authorized
entity can send the <spppUpdateRequest> to the registry with
a corresponding delete BasicUpdateRqstType object. Each 'Add'
operation in SPPP has a corresponding 'Del' operation, which is
used to delete the respective object type from the registry. If
the entity that issued the command is not authorized to perform
this operation an appropriate error code will be returned in
the <spppUpdateRespnonse> message. </t>
<t>As an example, DelPubIdRqstType is used to delete Public
Identifiers The DelPubIdsRqstType object definition is shown below: </t>
<t>
<figure title="">
<artwork align="left">
<![CDATA[
<complexType name="DelPubIdRqstType">
<complexContent>
<extension base="spppb:BasicUpdateRqstType">
<sequence>
<element name="pi" type="spppb:PubIdType"/>
</sequence>
</extension>
</complexContent>
</complexType>
]]>
</artwork>
</figure>
</t>
<t>When an object is deleted, any references to that object must of course also be
removed as the SPPP server implementation fulfills the deletion request.
Furthermore, the deletion of a composite object must also result in the
deletion of the objects it contains. As a result, the following rules apply to the
deletion of SPPP object types: <list style="symbols" hangIndent="5">
<t> Destination Groups: When a destination group is deleted all public identifiers
within that destination group must also be automatically deleted by the SPPP
implementation as part of fulfilling the deletion request. And any references
between that destination group and any route group must be automatically removed
by the SPPP implementation as part of fulfilling the deletion request.</t>
<t> Route Groups: When a route group is deleted any references between that route group
and any destination group must be automatically removed by the SPPP implementation as
part of fulfilling the deletion request. Similarly any references between that route group
and any route records must be removed by the SPPP implementation as part of fulfilling
the deletion request. Furthermore, route group offers relating that route group must
also be deleted as part of fulfilling the deletion request.</t>
<t> Route Records: When a route record is deleted any references between that route record
and any route group must be removed by the SPPP implementation as
part of fulfilling the deletion request.</t>
<t> Public Identifiers: When a public identifier is deleted any references between that
public identifier and its containing destination group must be removed by the SPPP
implementation as part of fulfilling the deletion request. And any route records
contained directly within that Public Identifier must be deleted by the SPPP implementation
as part of fulfilling the deletion request.</t>
</list></t>
</section>
</section>
<section anchor="SPPPWSDL" title="SPPP SOAP WSDL Definition">
<t>The SPPP WSDL and data types are defined below. The WSDL design approach is commonly referred to as _Generic WSDL_. It is generic in the sense that there is not a specific WSDL operation defined for each object type that is supported by the SPPP protocol. There is a single WSDL update operation called submitUpdateRqst, and a single WSDL query operation called submitQueryRqst. The submitUpdateRqst operation takes as input an spppUpdateRequestMsg object and returns as output an spppUpdateResponseMsg object. These objects _wrap_ the spppUpdateRequest and spppUpdateResponse objects respectively. And finally, the spppSOAPBinding in the WSDL defines the binding style as _document_ and the encoding as _literal_. It is this combination of _wrapped_ input and output data structures, _document_ binding style, and _literal_ encoding that characterize the Document Literal Wrapped style of WSDL specifications.</t>
<t>
Note: The following WSDL has been formatted (e.g., tabs, spaces) to meet I-D requirements.
</t>
<t>
<figure anchor="WSDL" title="WSDL">
<artwork align="left"><![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<wsdl:definitions
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:spppb="urn:ietf:params:xml:ns:sppp:base:1"
xmlns:sppps="urn:ietf:params:xml:ns:sppp:soap:1"
targetNamespace="urn:ietf:params:xml:ns:sppp:soap:1">
<wsdl:types>
<xsd:schema
xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:sppps="urn:ietf:params:xml:ns:sppp:soap:1"
targetNamespace="urn:ietf:params:xml:ns:sppp:soap:1">
<annotation>
<documentation>
---- Import base schema ----
</documentation>
</annotation>
<import namespace="urn:ietf:params:xml:ns:sppp:base:1"
schemaLocation="spppbase.xsd"/>
<annotation>
<documentation>
---- Key type(s) extended from base schema ----
</documentation>
</annotation>
<complexType name="ObjKeyType">
<complexContent>
<extension base="spppb:ObjKeyType">
<sequence>
<element name="rant" type="spppb:OrgIdType"/>
<element name="name" type="spppb:ObjNameType"/>
</sequence>
</extension>
</complexContent>
</complexType>
<complexType name="RteGrpOfferKeyType">
<complexContent>
<extension base="spppb:RteGrpOfferKeyType">
<sequence>
<element name="rteGrpKey"
type="sppps:ObjKeyType"/>
<element name="offeredTo"
type="spppb:OrgIdType"/>
</sequence>
</extension>
</complexContent>
</complexType>
<annotation>
<documentation>
---- Base Request Type Definitions ----
</documentation>
</annotation>
<complexType name="BasicUpdateRqstType"
abstract="true">
<sequence>
<element name="ext" type="spppb:ExtAnyType"
minOccurs="0"/>
</sequence>
</complexType>
<complexType name="BasicQueryRqstType" abstract="true">
<sequence>
<element name="ext" type="spppb:ExtAnyType"
minOccurs="0"/>
</sequence>
</complexType>
<annotation>
<documentation>
-- Request Type definition for various SPPP Objects. --
</documentation>
</annotation>
<complexType name="AddRteGrpRqstType">
<complexContent>
<extension base="sppps:BasicUpdateRqstType">
<sequence>
<element name="rteGrp" type="spppb:RteGrpType"/>
</sequence>
</extension>
</complexContent>
</complexType>
<complexType name="DelRteGrpRqstType">
<complexContent>
<extension base="sppps:BasicUpdateRqstType">
<sequence>
<element name="rteGrpKey"
type="sppps:ObjKeyType"/>
</sequence>
</extension>
</complexContent>
</complexType>
<complexType name="GetRteGrpsRqstType">
<complexContent>
<extension base="sppps:BasicQueryRqstType">
<sequence>
<element name="rteGrpKey"
type="sppps:ObjKeyType"
maxOccurs="unbounded"/>
</sequence>
</extension>
</complexContent>
</complexType>
<complexType name="AddRteRecRqstType">
<complexContent>
<extension base="sppps:BasicUpdateRqstType">
<sequence>
<element name="rteRec"
type="spppb:RteRecType"/>
</sequence>
</extension>
</complexContent>
</complexType>
<complexType name="DelRteRecRqstType">
<complexContent>
<extension base="sppps:BasicUpdateRqstType">
<sequence>
<element name="rteRecKey"
type="sppps:ObjKeyType"/>
</sequence>
</extension>
</complexContent>
</complexType>
<complexType name="GetRteRecsRqstType">
<complexContent>
<extension base="sppps:BasicQueryRqstType">
<sequence>
<element name="rteRecKey"
type="sppps:ObjKeyType"
maxOccurs="unbounded"/>
</sequence>
</extension>
</complexContent>
</complexType>
<complexType name="AddDestGrpRqstType">
<complexContent>
<extension base="sppps:BasicUpdateRqstType">
<sequence>
<element name="destGrp"
type="spppb:DestGrpType"/>
</sequence>
</extension>
</complexContent>
</complexType>
<complexType name="DelDestGrpRqstType">
<complexContent>
<extension base="sppps:BasicUpdateRqstType">
<sequence>
<element name="destGrpKey"
type="sppps:ObjKeyType"/>
</sequence>
</extension>
</complexContent>
</complexType>
<complexType name="GetDestGrpsRqstType">
<complexContent>
<extension base="sppps:BasicQueryRqstType">
<sequence>
<element name="destGrpKey"
type="sppps:ObjKeyType"
minOccurs="0" maxOccurs="unbounded"/>
</sequence>
</extension>
</complexContent>
</complexType>
<complexType name="AddPubIdRqstType">
<complexContent>
<extension base="sppps:BasicUpdateRqstType">
<sequence>
<element name="pi" type="spppb:PubIdType"/>
</sequence>
</extension>
</complexContent>
</complexType>
<complexType name="DelPubIdRqstType">
<complexContent>
<extension base="sppps:BasicUpdateRqstType">
<sequence>
<element name="pi" type="spppb:PubIdType"/>
</sequence>
</extension>
</complexContent>
</complexType>
<complexType name="GetPubIdsRqstType">
<complexContent>
<extension base="sppps:BasicQueryRqstType">
<sequence>
<element name="pi" type="spppb:PubIdType"
maxOccurs="unbounded"/>
</sequence>
</extension>
</complexContent>
</complexType>
<complexType name="AddRteGrpOfferRqstType">
<complexContent>
<extension base="sppps:BasicUpdateRqstType">
<sequence>
<element name="rteGrpOffer"
type="spppb:RteGrpOfferType"/>
</sequence>
</extension>
</complexContent>
</complexType>
<complexType name="DelRteGrpOfferRqstType">
<complexContent>
<extension base="sppps:BasicUpdateRqstType">
<sequence>
<element name="rteGrpOfferKey"
type="sppps:RteGrpOfferKeyType"/>
</sequence>
</extension>
</complexContent>
</complexType>
<complexType name="AcceptRteGrpOfferRqstType">
<complexContent>
<extension base="sppps:BasicUpdateRqstType">
<sequence>
<element name="rteGrpOfferKey"
type="sppps:RteGrpOfferKeyType"/>
</sequence>
</extension>
</complexContent>
</complexType>
<complexType name="RejectRteGrpOfferRqstType">
<complexContent>
<extension base="sppps:BasicUpdateRqstType">
<sequence>
<element name="rteGrpOfferKey"
type="sppps:RteGrpOfferKeyType"/>
</sequence>
</extension>
</complexContent>
</complexType>
<complexType name="GetRteGrpOffersRqstType">
<complexContent>
<extension base="sppps:BasicQueryRqstType">
<sequence>
<element name="offeredBy"
type="spppb:OrgIdType"
minOccurs="0" maxOccurs="unbounded"/>
<element name="offeredTo"
type="spppb:OrgIdType"
minOccurs="0" maxOccurs="unbounded"/>
<element name="status"
type="spppb:RteGrpOfferStatusType"
minOccurs="0"/>
<element name="rteGrpOfferKey"
type="sppps:RteGrpOfferKeyType"
minOccurs="0" maxOccurs="unbounded"/>
</sequence>
</extension>
</complexContent>
</complexType>
<complexType name="AddEgrRteRqstType">
<complexContent>
<extension base="sppps:BasicUpdateRqstType">
<sequence>
<element name="egrRte"
type="spppb:EgrRteType"/>
</sequence>
</extension>
</complexContent>
</complexType>
<complexType name="DelEgrRteRqstType">
<complexContent>
<extension base="sppps:BasicUpdateRqstType">
<sequence>
<element name="egrRteKey"
type="sppps:ObjKeyType"/>
</sequence>
</extension>
</complexContent>
</complexType>
<complexType name="GetEgrRtesRqstType">
<complexContent>
<extension base="sppps:BasicQueryRqstType">
<sequence>
<element name="egrRteKey"
type="sppps:ObjKeyType"
maxOccurs="unbounded"/>
</sequence>
</extension>
</complexContent>
</complexType>
<annotation>
<documentation>
--- Generic Request and Response Definitions ----
</documentation>
</annotation>
<element name="spppUpdateRequest">
<complexType>
<sequence>
<element name="clientTransId"
type="spppb:TransIdType" minOccurs="0"/>
<element name="minorVer"
type="spppb:MinorVerType"
minOccurs="0"/>
<element name="rqst"
type="sppps:BasicUpdateRqstType"
maxOccurs="unbounded"/>
</sequence>
</complexType>
</element>
<element name="spppUpdateResponse">
<complexType>
<sequence>
<element name="clientTransId"
type="spppb:TransIdType" minOccurs="0"/>
<element name="serverTransId"
type="spppb:TransIdType"/>
<element name="overallResult"
type="sppps:ResultCodeType"/>
<element name="rqstObjResult"
type="sppps:RqstObjResultCodeType" minOccurs="0"
maxOccurs="unbounded"/>
</sequence>
</complexType>
</element>
<element name="spppQueryRequest">
<complexType>
<sequence>
<element name="minorVer"
type="spppb:MinorVerType"
minOccurs="0"/>
<element name="rqst"
type="sppps:BasicQueryRqstType"/>
</sequence>
</complexType>
</element>
<element name="spppQueryResponse">
<complexType>
<sequence>
<element name="overallResult"
type="sppps:ResultCodeType"/>
<element name="resultSet"
type="spppb:BasicObjType"
minOccurs="0" maxOccurs="unbounded"/>
</sequence>
</complexType>
</element>
<element name="spppServerStatusRequest">
<complexType>
<sequence>
<element name="minorVer"
type="spppb:MinorVerType"
minOccurs="0"/>
</sequence>
</complexType>
</element>
<element name="spppServerStatusResponse">
<complexType>
<sequence>
<element name="overallResult"
type="sppps:ResultCodeType"/>
<element name="svcMenu"
type="spppb:SvcMenuType"/>
</sequence>
</complexType>
</element>
<annotation>
<documentation>
--- Operation Result Type Definitions ----
</documentation>
</annotation>
<complexType name="ResultCodeType">
<sequence>
<element name="code" type="int"/>
<element name="msg" type="token"/>
</sequence>
</complexType>
<complexType name="RqstObjResultCodeType">
<complexContent>
<extension base="sppps:ResultCodeType">
<sequence>
<element name="rqstObj"
type="sppps:BasicUpdateRqstType"/>
</sequence>
</extension>
</complexContent>
</complexType>
</xsd:schema>
</wsdl:types>
<wsdl:message name="spppUpdateRequestMsg">
<wsdl:part name="rqst"
element="sppps:spppUpdateRequest"/>
</wsdl:message>
<wsdl:message name="spppUpdateResponseMsg">
<wsdl:part name="rspns"
element="sppps:spppUpdateResponse"/>
</wsdl:message>
<wsdl:message name="spppQueryRequestMsg">
<wsdl:part name="rqst" element="sppps:spppQueryRequest"/>
</wsdl:message>
<wsdl:message name="spppQueryResponseMsg">
<wsdl:part name="rspns"
element="sppps:spppQueryResponse"/>
</wsdl:message>
<wsdl:message name="spppServerStatusRequestMsg">
<wsdl:part name="rqst"
element="sppps:spppServerStatusRequest"/>
</wsdl:message>
<wsdl:message name="spppServerStatusResponseMsg">
<wsdl:part name="rspns"
element="sppps:spppServerStatusResponse"/>
</wsdl:message>
<wsdl:portType name="spppPortType">
<wsdl:operation name="submitUpdateRqst">
<wsdl:input message="sppps:spppUpdateRequestMsg"/>
<wsdl:output
message="sppps:spppUpdateResponseMsg"/>
</wsdl:operation>
<wsdl:operation name="submitQueryRqst">
<wsdl:input message="sppps:spppQueryRequestMsg"/>
<wsdl:output message="sppps:spppQueryResponseMsg"/>
</wsdl:operation>
<wsdl:operation name="submitServerStatusRqst">
<wsdl:input
message="sppps:spppServerStatusRequestMsg"/>
<wsdl:output
message="sppps:spppServerStatusResponseMsg"/>
</wsdl:operation>
</wsdl:portType>
<wsdl:binding name="spppSoapBinding"
type="sppps:spppPortType">
<soap:binding style="document"
transport="http://schemas.xmlsoap.org/soap/http"/>
<wsdl:operation name="submitUpdateRqst">
<soap:operation soapAction="submitUpdateRqst"
style="document"/>
<wsdl:input>
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="submitQueryRqst">
<soap:operation soapAction="submitQueryRqst"
style="document"/>
<wsdl:input>
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="submitServerStatusRqst">
<soap:operation
soapAction="submitServerStatusRqst"
style="document"/>
<wsdl:input>
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
</wsdl:binding>
<wsdl:service name="spppService">
<wsdl:port name="spppPort"
binding="sppps:spppSoapBinding">
<soap:address location="REPLACE_WITH_ACTUAL_URL"/>
</wsdl:port>
</wsdl:service>
</wsdl:definitions>
]]></artwork>
</figure></t>
</section>
<section anchor="SPPPExamples" title="SPPP SOAP Examples">
<t>This section provides a few examples of SPPP SOAP messages. This section of course
relies on the XML data structures defined in the SPPP protocol specification <xref target="I-D.draft-ietf-drinks-spprov"/>. So refer to that document to understand XML object types embedded in these example messages.</t>
<t>
Note: The following examples have been formatted (e.g., tabs, spaces) to meet I-D requirements.
</t>
<t>
<figure anchor="Example1" title="Example 1 - SPPP Update Request - Add Destination Group">
<artwork align="left">
<![CDATA[
<soapenv:Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:spb="urn:ietf:params:xml:ns:sppp:base:1">
<soapenv:Header/>
<soapenv:Body>
<spb:spppUpdateRequest
xsi:schemaLocation="urn:ietf:params:xml:ns:sppp:base:1 sppp.xsd"
xmlns="urn:ietf:params:xml:ns:sppp:base:1"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<spb:clientTransId>888</spb:clientTransId>
<spb:minorVer>1</spb:minorVer>
<spb:rqst xsi:type="spb:AddDestGrpRqstType">
<spb:destGrp>
<spb:rant>registrant2</spb:rant>
<spb:dgName>DEST_GRP_SPPP_5</spb:dgName>
</spb:destGrp>
</spb:rqst>
</spb:spppUpdateRequest>
</soapenv:Body>
</soapenv:Envelope>
]]>
</artwork>
</figure>
</t>
<t>
<figure anchor="Example2" title="Example 2 - SPPP Query Request - Get Destination Group">
<artwork align="left">
<![CDATA[
<soapenv:Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:spb="urn:ietf:params:xml:ns:sppp:base:1">
<soapenv:Header/>
<soapenv:Body>
<spb:spppQueryRequest
xsi:schemaLocation="urn:ietf:params:xml:ns:sppp:base:1 sppp.xsd"
xmlns="urn:ietf:params:xml:ns:sppp:base:1"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<spb:minorVer>1</spb:minorVer>
<spb:rqst xsi:type="spb:GetDestGrpsRqstType">
<spb:objKey>
<spb:rant>registrant2</spb:rant>
<spb:name>DEST_GRP_SPPP_5</spb:name>
</spb:objKey>
</spb:rqst>
</spb:spppQueryRequest>
</soapenv:Body>
</soapenv:Envelope>
]]>
</artwork>
</figure>
</t>
<t>
<figure anchor="Example3" title="Example 2 - SPPP Query Request - Del Destination Group">
<artwork align="left">
<![CDATA[
<soapenv:Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:spb="urn:ietf:params:xml:ns:sppp:base:1">
<soapenv:Header/>
<soapenv:Body>
<spb:spppQueryRequest
xsi:schemaLocation="urn:ietf:params:xml:ns:sppp:base:1 sppp.xsd"
xmlns="urn:ietf:params:xml:ns:sppp:base:1"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<spb:clientTransId>999</spb:clientTransId>
<spb:minorVer>1</spb:minorVer>
<spb:rqst xsi:type="spb:DelDestGrpRqstType">
<spb:objKey>
<spb:rant>registrant2</spb:rant>
<spb:name>DEST_GRP_SPPP_5</spb:name>
</spb:objKey>
</spb:rqst>
</spb:spppQueryRequest>
</soapenv:Body>
</soapenv:Envelope>
]]>
</artwork>
</figure>
</t>
</section>
<section anchor="SecurityConsiderations" title="Security Considerations">
<t>SPPP is used to query and update session peering data and addresses, so
the ability to access this protocol should be limited to users and
systems that are authorized to query and update this data. Because this
data is sent in both directions, it may not be sufficient for just the client
or user to be authenticated with the server. The identity of the server
should also be authenticated by the client, which is often accomplished using
the TLS certificate exchange and validation described in <xref target="RFC2818"/>.
SPPP data may include sensitive
information, routing data, lists of resolvable addresses, etc. So when used
in a production setting and across non-secure networks, SPPP
should only be used over communications channels that provide strong
encryption for data privacy.</t>
<section anchor="IntegrityPrivacyAuthentication" title="Integrity, Privacy, and Authentication">
<t>The SPPP SOAP binding relies on an underlying secure transport for
integrity and privacy. Such transports are expected to include TLS/HTTPS.
In addition to the application level authentication imposed by an SPPP
server, there are a number of options for authentication within the transport
layer and the messaging envelope. These include TLS client certificates,
HTTP Digest Access Authentication, and digital signatures within SOAP headers. </t>
<t>At a miniumum, all conforming SPPP over SOAP implementations MUST
support HTTPS.</t>
</section>
<section anchor="Vulnerabilities" title="Vulnerabilities">
<t>The above protocols may have various vulnerabilities, and these may
be inherited by SPPP over SOAP. And SPPP itself may have vulnerabilities
because an authorization model is not explicitly specified in the current
specification.
</t>
<t>It is important that SPPP implementations implement an authorization
model that considers the source of each SPPP query or update request and
determines whether it is reasonable to authorize that source to perform that
specific query or update. </t>
</section>
<section anchor="DeploymentEnvironmentSpecifics" title="Deployment Environment Specifics">
<t>Some deployments of SPPP over SOAP could choose to use transports
without encryption. This presents vulnerabilities but could be
selected for deployments involving closed networks or debugging
scenarios. However, the vulnerabilities of such a deployment could be a
lack of integrity and privacy of the data transported over SPPP messages in
this type of deployment.</t>
</section>
</section>
<section anchor="IANAConsiderations" 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>URN assignments are requested: urn:ietf:params:xml:ns:sppp:soap</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>
This document is a result of various discussions held by the DRINKS design team, which is comprised of the following individuals, in no specific order: Syed Ali (NeuStar), Sumanth Channabasappa (Cable Labs), David Schwartz (XConnect), Jean-Francois Mule (CableLabs), Kenneth Cartwright (TNS, Inc.), Manjul Maharishi (TNS, Inc.), Alexander Mayrhofer (enum.at GmbH).
</t>
</section>
</middle>
<back>
<references title="Normative References">
&rfc2119;
&rfc3688;
&rfc5246;
&rfc2617;
&rfc2616;
<reference anchor="I-D.draft-ietf-drinks-spprov">
<front>
<title>DRINKS Use cases and Protocol Requirements</title>
<author initials="J-F.M." surname="Mule"/>
<author initials="K.C." surname="Cartwright"/>
<author initials="S.A." surname="Ali"/>
<author initials="A.M." surname="Mayrhofer"/>
<date month="June" year="2011" />
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-drinks-spprov-09"/>
<format target="http://tools.ietf.org/html/draft-ietf-drinks-spprov-09" type="HTML" />
</reference>
<reference anchor="SOAPREF">
<front>
<title>SOAP Version 1.2 Part 1: Messaging Framework</title>
<author initials="M." surname="Gudgin"/>
<author initials="M." surname="Hadley"/>
<author initials="J." surname="Moreau"/>
<author initials="H." surname="Nielsen"/>
<date month="June" year="2002" />
</front>
<seriesInfo name="W3C Recommendation" value="REC-SOAP12-part1-20030624"/>
<format target="http://www.w3.org/TR/soap12-part1/" type="HTML" />
</reference>
</references>
<references title="Informative References">
&rfc2818; &rfc5321;
<reference anchor="WSDLREF">
<front>
<title>Web Services Description Language (WSDL) 1.1</title>
<author initials="E." surname="Christensen"/>
<author initials="F." surname="Curbera"/>
<author initials="G." surname="Meredith"/>
<author initials="S." surname="Weerawarana"/>
<date month="March" year="2001" />
</front>
<seriesInfo name="W3C Note" value="NOTE-wsdl-20010315"/>
<format target="http://www.w3.org/TR/2001/NOTE-wsdl-20010315" type="HTML" />
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 11:34:17 |