draft-ietf-drinks-spp-protocol-over-soap-00.txt   draft-ietf-drinks-spp-protocol-over-soap-01.txt 
DRINKS K. Cartwright DRINKS K. Cartwright
Internet-Draft V. Bhatia Internet-Draft V. Bhatia
Intended status: Standards Track TNS Intended status: Standards Track TNS
Expires: August 2, 2012 January 30, 2012 Expires: September 13, 2012 March 12, 2012
Session Peering Provisioning (SPP) Protocol over SOAP Session Peering Provisioning (SPP) Protocol over SOAP
draft-ietf-drinks-spp-protocol-over-soap-00 draft-ietf-drinks-spp-protocol-over-soap-01
Abstract Abstract
The Session Peering Provisioning Framework (SPPF) is an XML framework The Session Peering Provisioning Framework (SPPF) is an XML framework
that exists to enable the provisioning of session establishment data that exists to enable the provisioning of session establishment data
into Session Data Registries or SIP Service Provider data stores. into Session Data Registries or SIP Service Provider data stores.
Sending XML data structures over Simple Object Access Protocol (SOAP) Sending XML data structures over Simple Object Access Protocol (SOAP)
and HTTP(s) is a widely used, de-facto standard for messaging between and HTTP(s) is a widely used, de-facto standard for messaging between
elements of provisioning systems. Therefore the combination of SOAP elements of provisioning systems. Therefore the combination of SOAP
and HTTP(s) as a transport protocol for SPPF is a natural fit. The and HTTP(s) as a transport protocol for SPPF is a natural fit. The
skipping to change at page 1, line 41 skipping to change at page 1, line 41
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 2, 2012. This Internet-Draft will expire on September 13, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 17 skipping to change at page 2, line 17
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. SOAP Features and Protocol Layering . . . . . . . . . . . . . 6 3. SOAP Features and Protocol Layering . . . . . . . . . . . . . 6
4. HTTP(s) Features and SPPF . . . . . . . . . . . . . . . . . . 9 4. HTTP(s) Features and SPP Protocol over SOAP . . . . . . . . . 9
5. Authentication and Session Management . . . . . . . . . . . . 10 5. Authentication and Session Management . . . . . . . . . . . . 10
6. SPP Protocol SOAP Data Structures . . . . . . . . . . . . . . 11 6. SPP Protocol SOAP Data Structures . . . . . . . . . . . . . . 11
6.1. Concrete Object Key Types . . . . . . . . . . . . . . . . 11 6.1. Concrete Object Key Types . . . . . . . . . . . . . . . . 11
6.1.1. Generic Object Key . . . . . . . . . . . . . . . . . . 11 6.1.1. Generic Object Key . . . . . . . . . . . . . . . . . . 11
6.1.2. Public Identity Object Key . . . . . . . . . . . . . . 12 6.1.2. Public Identity Object Key . . . . . . . . . . . . . . 12
6.1.3. Route Group Offer Key . . . . . . . . . . . . . . . . 13 6.1.3. Route Group Offer Key . . . . . . . . . . . . . . . . 13
6.2. Operation Request and Response Structures . . . . . . . . 13 6.2. Operation Request and Response Structures . . . . . . . . 14
6.2.1. Add Operation Structure . . . . . . . . . . . . . . . 14 6.2.1. Add Operation Structure . . . . . . . . . . . . . . . 14
6.2.2. Delete Operation Structure . . . . . . . . . . . . . . 17 6.2.2. Delete Operation Structure . . . . . . . . . . . . . . 17
6.2.3. Accept Operation Structure . . . . . . . . . . . . . . 20 6.2.3. Accept Operation Structure . . . . . . . . . . . . . . 20
6.2.4. Reject Operation Structure . . . . . . . . . . . . . . 23 6.2.4. Reject Operation Structure . . . . . . . . . . . . . . 24
6.2.5. Batch Operation Structure . . . . . . . . . . . . . . 26 6.2.5. Batch Operation Structure . . . . . . . . . . . . . . 27
6.2.6. Get Operation Structure . . . . . . . . . . . . . . . 29 6.2.6. Get Operation Structure . . . . . . . . . . . . . . . 30
6.2.7. Get Route Group Offers Operation Structure . . . . . . 31 6.2.7. Get Route Group Offers Operation Structure . . . . . . 32
6.2.8. Generic Query Response . . . . . . . . . . . . . . . . 32 6.2.8. Generic Query Response . . . . . . . . . . . . . . . . 33
6.2.9. Get Server Details Operation Structure . . . . . . . . 33 6.2.9. Get Server Details Operation Structure . . . . . . . . 34
6.3. Response Codes and Messages . . . . . . . . . . . . . . . 35 6.3. Response Codes and Messages . . . . . . . . . . . . . . . 36
7. Protocol Operations . . . . . . . . . . . . . . . . . . . . . 37 7. Protocol Operations . . . . . . . . . . . . . . . . . . . . . 39
8. SPPF SOAP WSDL Definition . . . . . . . . . . . . . . . . . . 38 8. SPP Protocol over SOAP WSDL Definition . . . . . . . . . . . . 40
9. SPP Protocol over SOAP Examples . . . . . . . . . . . . . . . 49 9. SPP Protocol over SOAP Examples . . . . . . . . . . . . . . . 52
9.1. Add Destination Group . . . . . . . . . . . . . . . . . . 49 9.1. Add Destination Group . . . . . . . . . . . . . . . . . . 52
9.2. Add Route Records . . . . . . . . . . . . . . . . . . . . 51 9.2. Add Route Records . . . . . . . . . . . . . . . . . . . . 54
9.3. Add Route Records -- URIType . . . . . . . . . . . . . . . 52 9.3. Add Route Records -- URIRteRecType . . . . . . . . . . . . 55
9.4. Add Route Group . . . . . . . . . . . . . . . . . . . . . 53 9.4. Add Route Group . . . . . . . . . . . . . . . . . . . . . 56
9.5. Add Public Identity -- Successful COR claim . . . . . . . 55 9.5. Add Public Identity -- Successful COR claim . . . . . . . 58
9.6. Add LRN . . . . . . . . . . . . . . . . . . . . . . . . . 57 9.6. Add LRN . . . . . . . . . . . . . . . . . . . . . . . . . 60
9.7. Add TN Range . . . . . . . . . . . . . . . . . . . . . . . 58 9.7. Add TN Range . . . . . . . . . . . . . . . . . . . . . . . 61
9.8. Add TN Prefix . . . . . . . . . . . . . . . . . . . . . . 59 9.8. Add TN Prefix . . . . . . . . . . . . . . . . . . . . . . 62
9.9. Enable Peering -- Route Group Offer . . . . . . . . . . . 60 9.9. Enable Peering -- Route Group Offer . . . . . . . . . . . 63
9.10. Enable Peering -- Route Group Offer Accept . . . . . . . . 62 9.10. Enable Peering -- Route Group Offer Accept . . . . . . . . 65
9.11. Add Egress Route . . . . . . . . . . . . . . . . . . . . . 63 9.11. Add Egress Route . . . . . . . . . . . . . . . . . . . . . 66
9.12. Remove Peering -- Route Group Offer Reject . . . . . . . . 65 9.12. Remove Peering -- Route Group Offer Reject . . . . . . . . 68
9.13. Get Destination Group . . . . . . . . . . . . . . . . . . 66 9.13. Get Destination Group . . . . . . . . . . . . . . . . . . 69
9.14. Get Public Identity . . . . . . . . . . . . . . . . . . . 68 9.14. Get Public Identity . . . . . . . . . . . . . . . . . . . 71
9.15. Get Route Group Request . . . . . . . . . . . . . . . . . 69 9.15. Get Route Group Request . . . . . . . . . . . . . . . . . 72
9.16. Get Route Group Offers Request . . . . . . . . . . . . . . 71 9.16. Get Route Group Offers Request . . . . . . . . . . . . . . 74
9.17. Get Egress Route . . . . . . . . . . . . . . . . . . . . . 73 9.17. Get Egress Route . . . . . . . . . . . . . . . . . . . . . 76
9.18. Delete Destination Group . . . . . . . . . . . . . . . . . 74 9.18. Delete Destination Group . . . . . . . . . . . . . . . . . 77
9.19. Delete Public Identity . . . . . . . . . . . . . . . . . . 75 9.19. Delete Public Identity . . . . . . . . . . . . . . . . . . 78
9.20. Delete Route Group Request . . . . . . . . . . . . . . . . 77 9.20. Delete Route Group Request . . . . . . . . . . . . . . . . 80
9.21. Delete Route Group Offers Request . . . . . . . . . . . . 78 9.21. Delete Route Group Offers Request . . . . . . . . . . . . 81
9.22. Delete Egress Route . . . . . . . . . . . . . . . . . . . 79 9.22. Delete Egress Route . . . . . . . . . . . . . . . . . . . 82
9.23. Batch Request . . . . . . . . . . . . . . . . . . . . . . 80 9.23. Batch Request . . . . . . . . . . . . . . . . . . . . . . 83
10. Security Considerations . . . . . . . . . . . . . . . . . . . 83 10. Security Considerations . . . . . . . . . . . . . . . . . . . 86
10.1. Integrity, Privacy, and Authentication . . . . . . . . . . 83 10.1. Integrity, Privacy, and Authentication . . . . . . . . . . 86
10.2. Vulnerabilities . . . . . . . . . . . . . . . . . . . . . 83 10.2. Vulnerabilities . . . . . . . . . . . . . . . . . . . . . 86
10.3. Deployment Environment Specifics . . . . . . . . . . . . . 83 10.3. Deployment Environment Specifics . . . . . . . . . . . . . 87
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 84 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 88
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 85 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 89
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 86 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 90
13.1. Normative References . . . . . . . . . . . . . . . . . . . 86 13.1. Normative References . . . . . . . . . . . . . . . . . . . 90
13.2. Informative References . . . . . . . . . . . . . . . . . . 86 13.2. Informative References . . . . . . . . . . . . . . . . . . 90
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 91
1. Introduction 1. Introduction
SPPF, defined in [I-D.draft-ietf-drinks-spp-framework], is best SPPF, defined in [I-D.draft-ietf-drinks-spp-framework], is best
supported by a transport and messaging infrastructure that is supported by a transport and messaging infrastructure that is
connection oriented, request-response oriented, easily secured, connection oriented, request-response oriented, easily secured,
supports propagation through firewalls in a standard fashion, and supports propagation through firewalls in a standard fashion, and
that is easily integrated into back-office systems. This is due to that is easily integrated into back-office systems. This is due to
the fact that the client side of SPPF is likely to be integrated with the fact that the client side of SPPF is likely to be integrated with
organizations' operational support systems that facilitate organizations' operational support systems that facilitate
skipping to change at page 9, line 5 skipping to change at page 9, line 5
features that are above the transport technology layer but below features that are above the transport technology layer but below
the application messaging layer. Technologies such as HTTP and the application messaging layer. Technologies such as HTTP and
SOAP are examples of messaging envelope technologies. This SOAP are examples of messaging envelope technologies. This
document specifies the required envelope technology. document specifies the required envelope technology.
3. Layers 3,4,5,6: The operation and message layers provides an 3. Layers 3,4,5,6: The operation and message layers provides an
envelope-independent and transport-independent wrapper for the envelope-independent and transport-independent wrapper for the
SPPF data model objects that are being acted on (created, SPPF data model objects that are being acted on (created,
modified, queried). modified, queried).
4. HTTP(s) Features and SPPF 4. HTTP(s) Features and SPP Protocol over SOAP
SOAP is not tied to HTTP(s), however, for reasons described in the 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 introduction, HTTP(s) is a good choice as the transport mechanism for
the SPP Protocol SOAP messages. HTTP 1.1 includes the "persistent the SPP Protocol SOAP messages. HTTP 1.1 includes the "persistent
connection" feature, which allows multiple HTTP request/response connection" feature, which allows multiple HTTP request/response
pairs to be transported across a single HTTP connection. This is an pairs to be transported across a single HTTP connection. This is an
important performance optimization feature, particularly when the important performance optimization feature, particularly when the
connections is an HTTPS connection where the relatively time connections is an HTTPS connection where the relatively time
consuming SSL handshake has occurred. Persistent connections SHOULD consuming SSL handshake has occurred. Persistent connections SHOULD
be used for the SPPF HTTP connections. be used for the SPPF HTTP connections.
skipping to change at page 11, line 22 skipping to change at page 11, line 22
description of all the operations that MUST be supported. description of all the operations that MUST be supported.
The following sections describe the definition all the XML data The following sections describe the definition all the XML data
structures. structures.
6.1. Concrete Object Key Types 6.1. Concrete Object Key Types
Certain operations in SPPF require an object key that uniquely Certain operations in SPPF require an object key that uniquely
identifies the object(s) on which a given operation needs to be identifies the object(s) on which a given operation needs to be
performed. SPPF defines the XML structure of the any such object key performed. SPPF defines the XML structure of the any such object key
in an abstact manner and delegates the concrete represenation to any in an abstact manner and delegates the concrete representation to any
conforming transport protocol. The following sub-sections define the conforming transport protocol. The following sub-sections define the
various types of concrete object key types used in various operations various types of concrete object key types used in various operations
in SPP Protocol over SOAP: in SPP Protocol over SOAP:
6.1.1. Generic Object Key 6.1.1. Generic Object Key
Most objects in SPP Protocol over SOAP are unqiuely identified by the Most objects in SPP Protocol over SOAP are uniquely identified by the
attributes in the concrete ObjKeyType. The XML representation of attributes in the generic object key (Refer "Generic Object Key Type"
ObjKeyType is as below: section of the framework document for details). The concrete XML
representation of ObjKeyType is as below:
<complexType name="ObjKeyType"> <complexType name="ObjKeyType">
<complexContent> <complexContent>
<extension base="sppfb:ObjKeyType"> <extension base="sppfb:ObjKeyType">
<sequence> <sequence>
<element name="rant" type="sppfb:OrgIdType"/> <element name="rant" type="sppfb:OrgIdType"/>
<element name="name" type="sppfb:ObjNameType"/> <element name="name" type="sppfb:ObjNameType"/>
<element name="type" type="sppfb:ObjKeyTypeEnum"/> <element name="type" type="sppfs:ObjKeyTypeEnum"/>
</sequence> </sequence>
</extension> </extension>
</complexContent> </complexContent>
</complexType> </complexType>
The ObjKeyType has the data elements as described below: The ObjKeyType has the data elements as described below:
o rant: The identifier of the registrant organization that owns o rant: The identifier of the registrant organization that owns
the object. the object.
o name: The character string that contains the name of the object. o name: The character string that contains the name of the object.
o type: The enumeration vaue that represents the type of SPPF o type: The enumeration value that represents the type of SPPF
object. object. For example, both a Destination Group and a Route Group
can have the same name "TestObj" and be associated with same
Registrant Id "iana-en:222". Hence, to uniquely identify the
object that represents a Destination Group with the name
"TestObj", the type "DestGrp" must be specified when using this
concrete ObjKeyType structure to identify the Destination Group
"TestObj".
The object types in SPP Protocol over SOAP that MUST adhere to the
above definition of generic object key are defined as an enumeration
in the XML data structure. The structure of the the enumeration is
as follows:
<simpleType name="ObjKeyTypeEnum">
<restriction base="token">
<enumeration value="RteGrp"/>
<enumeration value="DestGrp"/>
<enumeration value="RteRec"/>
<enumeration value="EgrRte"/>
</restriction>
</simpleType>
6.1.2. Public Identity Object Key 6.1.2. Public Identity Object Key
Public Identity type objects can further be of various sub-types like Public Identity type objects can further be of various sub-types like
a TN, RN, TN Prefix, or a TN Range and cannot be cleanly identified a TN, RN, TN Prefix, URI, or a TN Range and cannot be cleanly
with the attributes in the generic ObjKeyType. The definition of identified with the attributes in the generic ObjKeyType. The
PubIdKeyType is as below: definition of PubIdKeyType is as below:
<complexType name="PubIdKeyType"> <complexType name="PubIdKeyType">
<complexContent> <complexContent>
<extension base="sppfb:PubIdKeyType"> <extension base="sppfb:PubIdKeyType">
<sequence> <sequence>
<element name="rant" type="sppfb:OrgIdType"/> <element name="rant" type="sppfb:OrgIdType"/>
<element name="dgName" type="sppfb:ObjNameType" minOccurs="0"/> <element name="dgName" type="sppfb:ObjNameType" minOccurs="0"/>
<choice> <choice>
<element name="number" <element name="number"
type="sppfb:NumberType"/> type="sppfb:NumberType"/>
<element name="range" <element name="range"
type="sppfb:NumberRangeType"/> type="sppfb:NumberRangeType"/>
<element name="uri"
type="anyURI"/>
</choice> </choice>
</sequence> </sequence>
</extension> </extension>
</complexContent> </complexContent>
</complexType> </complexType>
The PubIdKeyType has the data elements as described below: The PubIdKeyType has the data elements as described below:
o rant: The identifier of the registrant organization that owns o rant: The identifier of the registrant organization that owns
the object. the object.
o dgName: The name of the Destination Group that a Public o dgName: The name of the Destination Group that a Public
Identifier is member of. Note that this is an optional Identifier is member of. Note that this is an optional
attribute of the key as Public Identifiers may or may not be attribute of the key as Public Identifiers may or may not be
provisioned as members of a Destination Group. provisioned as members of a Destination Group.
o number: An element of type NumberType (refer framework document) o number: An element of type NumberType (refer framework document)
that contains the value and type of a the number . that contains the value and type of a number .
o range: An element of type NumberRangeType (refer framework o range: An element of type NumberRangeType (refer framework
document) that contains a rage of numbers. document) that contains a range of numbers.
It is MUST that only one of the "number" and "range" elements appears o uri: A value that represents a Public Identifier.
in a PubIdKeyType instance.
It is MUST that only one of the "number", "range", and "uri" elements
appears in a PubIdKeyType instance.
6.1.3. Route Group Offer Key 6.1.3. Route Group Offer Key
In addition to the attributes in the generic ObjKeyType, a Route In addition to the attributes in the generic ObjKeyType, a Route
Group Offer object is uniquely identified by the organization ID of Group Offer object is uniquely identified by the organization ID of
the organization to whom an Route Group has been offered. The the organization to whom an Route Group has been offered. The
definition of RteGrpOfferKeyType is as below: definition of RteGrpOfferKeyType is as below:
<complexType name="RteGrpOfferKeyType"> <complexType name="RteGrpOfferKeyType">
<complexContent> <complexContent>
skipping to change at page 14, line 13 skipping to change at page 14, line 41
sections describe the XML data structures that are used for each of sections describe the XML data structures that are used for each of
those types of operations for a SPP Protocol over SOAP those types of operations for a SPP Protocol over SOAP
implementation. implementation.
6.2.1. Add Operation Structure 6.2.1. Add Operation Structure
In order to add (or modify) an object in the registry, an authorized In order to add (or modify) an object in the registry, an authorized
entity can send the spppAddRequest to the registry. entity can send the spppAddRequest to the registry.
An SPP Protocol over SOAP Add request is wrapped within the An SPP Protocol over SOAP Add request is wrapped within the
<spppAddRequest> element while an SPPF Add response is wrapped within <spppAddRequest> element while an SPP Protocol over SOAP Add response
an <spppAddResponse> element. The following sub-sections describe is wrapped within an <spppAddResponse> element. The following sub-
the spppAddRequest and spppAddResponse elements. Refer the "SPPF sections describe the spppAddRequest and spppAddResponse elements.
SOAP Examples" section of this document for an example of Add Refer the "SPP Protocol over SOAP Examples" section of this document
operation on each type of SPPF object. for an example of Add operation on each type of SPPF object.
6.2.1.1. Add Request 6.2.1.1. Add Request
An SPP Protocol over SOAP Add request definition is contained within An SPP Protocol over SOAP Add request definition is contained within
the generic <spppAddRequest> element. the generic <spppAddRequest> element.
<element name="spppAddRequest"> <element name="spppAddRequest">
<complexType> <complexType>
<sequence> <sequence>
<element name="clientTransId" <element name="clientTransId"
type="sppfb:TransIdType" minOccurs="0"/> type="sppfb:TransIdType" minOccurs="0"/>
<element name="minorVer" <element name="minorVer"
type="sppfb:MinorVerType" minOccurs="0"/> type="sppfb:MinorVerType" minOccurs="0"/>
<element name="obj" type="sppfb:BasicObjType" <element name="obj" type="sppfb:BasicObjType"
maxOccurs="unbounded"/> maxOccurs="unbounded"/>
</sequence> </sequence>
</complexType> </complexType>
</element> </element>
<simpleType name="TransIdType">
<restriction base="string"/>
</simpleType>
<simpleType name="MinorVerType">
<restriction base="unsignedLong"/>
</simpleType>
The data elements within the <spppAddRequest> element are described The data elements within the <spppAddRequest> element are described
as follows: as follows:
o clientTransId: Zero or one client-generated transaction ID that, o clientTransId: Zero or one client-generated transaction ID that,
within the context of the SPPF client, identifies this request. within the context of the SPPF client, identifies this request.
This value can be used at the discretion of the SPPF client to This value can be used at the discretion of the SPPF client to
track, log or correlate requests and their responses. SPPF track, log or correlate requests and their responses. SPPF
server MUST echo back this value to the client in the server MUST echo back this value to the client in the
corresponding response to the incoming request. SPPF server corresponding response to the incoming request. SPPF server
will not check this value for uniqueness. will not check this value for uniqueness.
skipping to change at page 16, line 12 skipping to change at page 16, line 27
for all types of SPPF objects that are provisioned by the SPPF for all types of SPPF objects that are provisioned by the SPPF
client. client.
<element name="spppAddResponse"> <element name="spppAddResponse">
<complexType> <complexType>
<sequence> <sequence>
<element name="clientTransId" type="sppfb:TransIdType" <element name="clientTransId" type="sppfb:TransIdType"
minOccurs="0"/> minOccurs="0"/>
<element name="serverTransId" type="sppfb:TransIdType"/> <element name="serverTransId" type="sppfb:TransIdType"/>
<element name="overallResult" type="sppfb:ResultCodeType"/> <element name="overallResult" type="sppfb:ResultCodeType"/>
<element name="dtlResult" type="sppfs:ObjResultCodeType" <element name="detailResult" type="sppfs:ObjResultCodeType"
minOccurs="0" maxOccurs="unbounded"/> minOccurs="0" maxOccurs="unbounded"/>
</sequence> </sequence>
</complexType> </complexType>
</element> </element>
<complexType name="ResultCodeType"> <complexType name="ResultCodeType">
<sequence> <sequence>
<element name="code" type="int"/> <element name="code" type="int"/>
<element name="msg" type="string"/> <element name="msg" type="string"/>
</sequence> </sequence>
skipping to change at page 16, line 40 skipping to change at page 17, line 10
</sequence> </sequence>
</extension> </extension>
</complexContent> </complexContent>
</complexType> </complexType>
An <spppAddResponse> contains the elements necessary for the SPPF An <spppAddResponse> contains the elements necessary for the SPPF
client to precisely determine the overall result of the request, and client to precisely determine the overall result of the request, and
if an error occurred, it provides information about the specific if an error occurred, it provides information about the specific
object(s) that caused the error. object(s) that caused the error.
The data elements within the SPPF Add response are described as The data elements within the SPP Protocol over SOAP Add response are
follows: described as follows:
o clientTransId: Zero or one client transaction ID. This value is o clientTransId: Zero or one client transaction ID. This value is
simply an echo of the client transaction ID that SPPF client simply an echo of the client transaction ID that SPPF client
passed into the SPPF update request. When included in the passed into the SPPF update request. When included in the
request, the SPPF server MUST return it in the corresponding request, the SPPF server MUST return it in the corresponding
response message. response message.
o serverTransId: Exactly one server transaction ID that identifies o serverTransId: Exactly one server transaction ID that identifies
this request for tracking purposes. This value MUST be unique this request for tracking purposes. This value MUST be unique
for a given SPPF server. for a given SPPF server.
o overallResult: Exactly one response code and message pair that o overallResult: Exactly one response code and message pair that
explicitly identifies the result of the request. See the explicitly identifies the result of the request. See the
Response Code section for further details. Response Code section for further details.
o dtlResult: An optional response code, response message, and o detailResult: An optional response code, response message, and
BasicObjType (as defined in the framework document) triplet. BasicObjType (as defined in the framework document) triplet.
This element will be present only if an object level error has This element will be present only if an object level error has
occurred. It indicates the error condition and the exact occurred. It indicates the error condition and the exact
request object that contributed to the error. The response code request object that contributed to the error. The response code
will reflect the exact error. See the Response Code section for will reflect the exact error. See the Response Code section for
further details. further details.
6.2.2. Delete Operation Structure 6.2.2. Delete Operation Structure
In order to remove an object from the registry, an authorized entity In order to remove an object from the registry, an authorized entity
can send the spppDelRequest into the registry. An SPP Protocol over can send the spppDelRequest into the registry. An SPP Protocol over
SOAP Del request is wrapped within the <spppDelRequest> element while SOAP Delete request is wrapped within the <spppDelRequest> element
a SPPF Del response is wrapped within the generic <spppDelResponse> while a SPP Protocol over SOAP Delete response is wrapped within the
element. The following sub-sections describe the spppDelRequest and generic <spppDelResponse> element. The following sub-sections
spppDelResponse elements. Refer the "SPPF SOAP Examples" section of describe the spppDelRequest and spppDelResponse elements. Refer the
this document for an example of Delete operation on each type of SPPF "SPP Protocol over SOAP Examples" section of this document for an
object. example of Delete operation on each type of SPPF object.
6.2.2.1. Delete Request 6.2.2.1. Delete Request
An SPP Protocol over SOAP Del request definition is contained within An SPP Protocol over SOAP Delete request definition is contained
the generic <spppDelRequest> element. within the generic <spppDelRequest> element.
<element name="spppDelRequest"> <element name="spppDelRequest">
<complexType> <complexType>
<sequence> <sequence>
<element name="clientTransId" <element name="clientTransId"
type="sppfb:TransIdType" minOccurs="0"/> type="sppfb:TransIdType" minOccurs="0"/>
<element name="minorVer" <element name="minorVer"
type="sppfb:MinorVerType" minOccurs="0"/> type="sppfb:MinorVerType" minOccurs="0"/>
<element name="objKey" type="sppfb:ObjKeyType" <element name="objKey" type="sppfb:ObjKeyType"
maxOccurs="unbounded"/> maxOccurs="unbounded"/>
skipping to change at page 19, line 5 skipping to change at page 19, line 20
KeyParamType elements that had already been processed for that KeyParamType elements that had already been processed for that
delete request. delete request.
6.2.2.2. Delete Response 6.2.2.2. Delete Response
An SPP Protocol over SOAP delete response object is contained within An SPP Protocol over SOAP delete response object is contained within
the generic <sppDeleteResponse> element. This response structure is the generic <sppDeleteResponse> element. This response structure is
used for a delete request on all types of SPPF objects that are used for a delete request on all types of SPPF objects that are
provisioned by the SPPF client. provisioned by the SPPF client.
<element name="spppDelResponse"> <element name="spppDelResponse">
<complexType> <complexType>
<sequence> <sequence>
<element name="clientTransId" type="sppfb:TransIdType" <element name="clientTransId" type="sppfb:TransIdType"
minOccurs="0"/> minOccurs="0"/>
<element name="serverTransId" type="sppfb:TransIdType"/> <element name="serverTransId" type="sppfb:TransIdType"/>
<element name="overallResult" type="sppfb:ResultCodeType"/> <element name="overallResult" type="sppfb:ResultCodeType"/>
<element name="dtlResult" type="sppfs:ObjKeyResultCodeType" <element name="detailResult" type="sppfs:ObjKeyResultCodeType"
minOccurs="0" maxOccurs="unbounded"/> minOccurs="0" maxOccurs="unbounded"/>
</sequence> </sequence>
</complexType> </complexType>
</element> </element>
<complexType name="ResultCodeType"> <complexType name="ResultCodeType">
<sequence> <sequence>
<element name="code" type="int"/> <element name="code" type="int"/>
<element name="msg" type="string"/> <element name="msg" type="string"/>
</sequence> </sequence>
</complexType> </complexType>
<complexType name="ObjKeyResultCodeType"> <complexType name="ObjKeyResultCodeType">
<complexContent> <complexContent>
<extension base="sppfs:ResultCodeType"> <extension base="sppfs:ResultCodeType">
<sequence> <sequence>
<element name="objKey" type="sppfb:ObjKeyType"/> <element name="objKey" type="sppfb:ObjKeyType"/>
</sequence> </sequence>
</extension> </extension>
</complexContent> </complexContent>
</complexType> </complexType>
An <spppDelResponse> contains the elements necessary for the SPPF An <spppDelResponse> contains the elements necessary for the SPPF
client to precisely determine the overall result of the request, and client to precisely determine the overall result of the request, and
if an error occurred, it provides information about the specific if an error occurred, it provides information about the specific
object key(s) that caused the error. object key(s) that caused the error.
The data elements within the SPPF Delete response are described as The data elements within the SPP Protocol over SOAP Delete response
follows: are described as follows:
o clientTransId: Zero or one client transaction ID. This value is o clientTransId: Zero or one client transaction ID. This value is
simply an echo of the client transaction ID that SPPF client simply an echo of the client transaction ID that SPPF client
passed into the SPPF update request. When included in the passed into the SPPF update request. When included in the
request, the SPPF server MUST return it in the corresponding request, the SPPF server MUST return it in the corresponding
response message. response message.
o serverTransId: Exactly one server transaction ID that identifies o serverTransId: Exactly one server transaction ID that identifies
this request for tracking purposes. This value MUST be unique this request for tracking purposes. This value MUST be unique
for a given SPPF server. for a given SPPF server.
o overallResult: Exactly one response code and message pair that o overallResult: Exactly one response code and message pair that
explicitly identifies the result of the request. See the explicitly identifies the result of the request. See the
Response Code section for further details. Response Code section for further details.
o dtlResult: An optional response code, response message, and o detailResult: An optional response code, response message, and
ObjKeyType (as defined in the framework document) triplet. This ObjKeyType (as defined in the framework document) triplet. This
element will be present only if an specific object key level element will be present only if an specific object key level
error has occurred. It indicates the error condition and the error has occurred. It indicates the error condition and the
exact request object key that contributed to the error. The exact request object key that contributed to the error. The
response code will reflect the exact error. See the Response response code will reflect the exact error. See the Response
Code section for further details. Code section for further details.
6.2.3. Accept Operation Structure 6.2.3. Accept Operation Structure
In SPPF, a Route Group Offer can be accepted or rejected by, or on In SPPF, a Route Group Offer can be accepted or rejected by, or on
behalf of, the registrant to whom the Route Group has been offered behalf of, the registrant to whom the Route Group has been offered
(refer "Framework Data Model Objects" section of the framework (refer "Framework Data Model Objects" section of the framework
document for a description of the Route Group Offer object). The document for a description of the Route Group Offer object). The
Accept operation is used to accept such Route Group Offers by, or on Accept operation is used to accept such Route Group Offers by, or on
behalf of, the Registrant. The request structure for an SPPF Accept behalf of, the Registrant. The request structure for an SPP Protocol
operation is wrapped within the <spppAcceptRequest> element while an over SOAP Accept operation is wrapped within the <spppAcceptRequest>
SPPF Accept response is wrapped within the generic element while an SPP Protocol over SOAP Accept response is wrapped
<spppAcceptResponse> element. The following sub-sections describe within the generic <spppAcceptResponse> element. The following sub-
the spppAcceptRequest and spppAcceptResponse elements. Refer the sections describe the spppAcceptRequest and spppAcceptResponse
"SPPF SOAP Examples" section of this document for an example of elements. Refer the "SPP Protocol over SOAP Examples" section of
Accept operation on a Route Group Offer. this document for an example of Accept operation on a Route Group
Offer.
6.2.3.1. Accept Request Structure 6.2.3.1. Accept Request Structure
An SPP Protocol over SOAP Accept request definition is contained An SPP Protocol over SOAP Accept request definition is contained
within the generic <sppAcceptRequest> element. within the generic <sppAcceptRequest> element.
<element name="spppAcceptRequest"> <element name="spppAcceptRequest">
<complexType> <complexType>
<sequence> <sequence>
<element name="clientTransId" <element name="clientTransId"
skipping to change at page 22, line 18 skipping to change at page 23, line 12
within the generic <sppAcceptResponse> element. This response within the generic <sppAcceptResponse> element. This response
structure is used for an Accept request on a Route Group Offer. structure is used for an Accept request on a Route Group Offer.
<element name="spppAcceptResponse"> <element name="spppAcceptResponse">
<complexType> <complexType>
<sequence> <sequence>
<element name="clientTransId" type="sppfb:TransIdType" <element name="clientTransId" type="sppfb:TransIdType"
minOccurs="0"/> minOccurs="0"/>
<element name="serverTransId" type="sppfb:TransIdType"/> <element name="serverTransId" type="sppfb:TransIdType"/>
<element name="overallResult" type="sppfb:ResultCodeType"/> <element name="overallResult" type="sppfb:ResultCodeType"/>
<element name="dtlResult" <element name="detailResult"
type="sppfs:RteGrpOfferKeyResultCodeType" type="sppfs:RteGrpOfferKeyResultCodeType"
minOccurs="0" maxOccurs="unbounded"/> minOccurs="0" maxOccurs="unbounded"/>
</sequence> </sequence>
</complexType> </complexType>
</element> </element>
<complexType name="ResultCodeType"> <complexType name="ResultCodeType">
<sequence> <sequence>
<element name="code" type="int"/> <element name="code" type="int"/>
<element name="msg" type="string"/> <element name="msg" type="string"/>
skipping to change at page 22, line 47 skipping to change at page 23, line 41
</sequence> </sequence>
</extension> </extension>
</complexContent> </complexContent>
</complexType> </complexType>
An <spppAcceptResponse> contains the elements necessary for the SPPF An <spppAcceptResponse> contains the elements necessary for the SPPF
client to precisely determine the overall result of the request, and client to precisely determine the overall result of the request, and
if an error occurred, it provides information about the specific if an error occurred, it provides information about the specific
Route Group Offer key(s) that caused the error. Route Group Offer key(s) that caused the error.
The data elements within the SPPF Accept response are described as The data elements within the SPP Protocol over SOAP Accept response
follows: are described as follows:
o clientTransId: Zero or one client transaction ID. This value is o clientTransId: Zero or one client transaction ID. This value is
simply an echo of the client transaction ID that SPPF client simply an echo of the client transaction ID that SPPF client
passed into the SPPF update request. When included in the passed into the SPPF update request. When included in the
request, the SPPF server MUST return it in the corresponding request, the SPPF server MUST return it in the corresponding
response message. response message.
o serverTransId: Exactly one server transaction ID that identifies o serverTransId: Exactly one server transaction ID that identifies
this request for tracking purposes. This value MUST be unique this request for tracking purposes. This value MUST be unique
for a given SPPF server. for a given SPPF server.
o overallResult: Exactly one response code and message pair that o overallResult: Exactly one response code and message pair that
explicitly identifies the result of the request. See the explicitly identifies the result of the request. See the
Response Code section for further details. Response Code section for further details.
o dtlResult: An optional response code, response message, and o detailResult: An optional response code, response message, and
RteGrpOfferKeyType (as defined in this document) triplet. This RteGrpOfferKeyType (as defined in this document) triplet. This
element will be present only if any specific Route Group Offer element will be present only if any specific Route Group Offer
key level error has occurred. It indicates the error condition key level error has occurred. It indicates the error condition
and the exact request Route Group Offer key that contributed to and the exact request Route Group Offer key that contributed to
the error. The response code will reflect the exact error. See the error. The response code will reflect the exact error. See
the Response Code section for further details. the Response Code section for further details.
6.2.4. Reject Operation Structure 6.2.4. Reject Operation Structure
In SPPF, Route Group Offer can be accepted or rejected by, or on In SPPF, Route Group Offer can be accepted or rejected by, or on
behalf of, the registrant to whom the Route Group has been offered behalf of, the registrant to whom the Route Group has been offered
(refer "Framework Data Model Objects" section of this document for a (refer "Framework Data Model Objects" section of the framerwork
description of the Route Group Offer object). The Reject operation document for a description of the Route Group Offer object). The
is used to reject such Route Group Offers by, or on behalf of, the Reject operation is used to reject such Route Group Offers by, or on
Registrant. The request structure for an SPPF Reject operation is behalf of, the Registrant. The request structure for an SPP Protocol
wrapped within the <spppRejectRequest> element while an SPPF Reject over SOAP Reject operation is wrapped within the <spppRejectRequest>
response is wrapped within the generic <spppRejecResponse> element. element while an SPP Protocol over SOAP Reject response is wrapped
The following sub-sections describe the spppRejectRequest and within the generic <spppRejecResponse> element. The following sub-
spppRejecResponse elements. Refer the "SPPF SOAP Examples" section sections describe the spppRejectRequest and spppRejecResponse
of this document for an example of Reject operation on a Route Group elements. Refer the "SPP Protocol over SOAP Examples" section of
this document for an example of Reject operation on a Route Group
Offer. Offer.
6.2.4.1. Reject Request 6.2.4.1. Reject Request
An SPP Protocol over SOAP Reject request definition is contained An SPP Protocol over SOAP Reject request definition is contained
within the generic <spppRejectRequest> element. within the generic <spppRejectRequest> element.
<element name="spppRejectRequest"> <element name="spppRejectRequest">
<complexType> <complexType>
<sequence> <sequence>
skipping to change at page 25, line 23 skipping to change at page 26, line 23
within the generic <sppRejectResponse> element. This response within the generic <sppRejectResponse> element. This response
structure is used for an Reject request on a Route Group Offer. structure is used for an Reject request on a Route Group Offer.
<element name="spppRejectResponse"> <element name="spppRejectResponse">
<complexType> <complexType>
<sequence> <sequence>
<element name="clientTransId" type="sppfb:TransIdType" <element name="clientTransId" type="sppfb:TransIdType"
minOccurs="0"/> minOccurs="0"/>
<element name="serverTransId" type="sppfb:TransIdType"/> <element name="serverTransId" type="sppfb:TransIdType"/>
<element name="overallResult" type="sppfb:ResultCodeType"/> <element name="overallResult" type="sppfb:ResultCodeType"/>
<element name="dtlResult" <element name="detailResult"
type="sppfs:RteGrpOfferKeyResultCodeType" type="sppfs:RteGrpOfferKeyResultCodeType"
minOccurs="0" maxOccurs="unbounded"/> minOccurs="0" maxOccurs="unbounded"/>
</sequence> </sequence>
</complexType> </complexType>
</element> </element>
<complexType name="ResultCodeType"> <complexType name="ResultCodeType">
<sequence> <sequence>
<element name="code" type="int"/> <element name="code" type="int"/>
<element name="msg" type="string"/> <element name="msg" type="string"/>
skipping to change at page 26, line 8 skipping to change at page 27, line 8
</sequence> </sequence>
</extension> </extension>
</complexContent> </complexContent>
</complexType> </complexType>
An <spppRejectResponse> contains the elements necessary for the SPPF An <spppRejectResponse> contains the elements necessary for the SPPF
client to precisely determine the overall result of the request, and client to precisely determine the overall result of the request, and
if an error occurred, it provides information about the specific if an error occurred, it provides information about the specific
Route Group Offer key(s) that caused the error. Route Group Offer key(s) that caused the error.
The data elements within the SPPF Reject response are described as The data elements within the SPP Protocol over SOAP Reject response
follows: are described as follows:
o clientTransId: Zero or one client transaction ID. This value is o clientTransId: Zero or one client transaction ID. This value is
simply an echo of the client transaction ID that SPPF client simply an echo of the client transaction ID that SPPF client
passed into the SPPF update request. When included in the passed into the SPPF update request. When included in the
request, the SPPF server MUST return it in the corresponding request, the SPPF server MUST return it in the corresponding
response message. response message.
o serverTransId: Exactly one server transaction ID that identifies o serverTransId: Exactly one server transaction ID that identifies
this request for tracking purposes. This value MUST be unique this request for tracking purposes. This value MUST be unique
for a given SPPF server. for a given SPPF server.
o overallResult: Exactly one response code and message pair that o overallResult: Exactly one response code and message pair that
explicitly identifies the result of the request. See the explicitly identifies the result of the request. See the
Response Code section for further details. Response Code section for further details.
o dtlResult: An optional response code, response message, and o detailResult: An optional response code, response message, and
RteGrpOfferKeyType (as defined in this document) triplet. This RteGrpOfferKeyType (as defined in this document) triplet. This
element will be present only if any specific Route Group Offer element will be present only if any specific Route Group Offer
key level error has occurred. It indicates the error condition key level error has occurred. It indicates the error condition
and the exact request Route Group Offer key that contributed to and the exact request Route Group Offer key that contributed to
the error. The response code will reflect the exact error. See the error. The response code will reflect the exact error. See
the Response Code section for further details. the Response Code section for further details.
6.2.5. Batch Operation Structure 6.2.5. Batch Operation Structure
An SPP Protocol over SOAP Batch request XML structure allows the SPPF An SPP Protocol over SOAP Batch request XML structure allows the SPPF
client to send any of of Add, Del, Accept or Reject operations client to send any of of Add, Del, Accept or Reject operations
together in one single request. This gives an SPPF Client the together in one single request. This gives an SPPF Client the
flexibility to use one single request structure to perform more than flexibility to use one single request structure to perform more than
operations (verbs). The batch request structure is wrapped within operations (verbs). The batch request structure is wrapped within
the <spppBatchRequest> element while a SPPF Batch response is wrapped the <spppBatchRequest> element while a SPPF Batch response is wrapped
within the <spppBatchResponse> element. This following sub-sections within the <spppBatchResponse> element. This following sub-sections
describe the spppBatchRequest and spppBatchResponse elements. Refer describe the spppBatchRequest and spppBatchResponse elements. Refer
the "SPPF SOAP Examples" section of this document for an example of a the "SPP Protocol over SOAP Examples" section of this document for an
batch operation. example of a batch operation.
6.2.5.1. Batch Request Structure 6.2.5.1. Batch Request Structure
An SPP Protocol over SOAP Batch request definition is contained An SPP Protocol over SOAP Batch request definition is contained
within the generic <spppBatchRequest> element. within the generic <spppBatchRequest> element.
<element name="spppBatchRequest"> <element name="spppBatchRequest">
<complexType> <complexType>
<sequence> <sequence>
<element name="clientTransId" <element name="clientTransId"
skipping to change at page 29, line 11 skipping to change at page 30, line 11
</sequence> </sequence>
</complexType> </complexType>
</element> </element>
An <spppBatchResponse> contains the elements necessary for an SPPF An <spppBatchResponse> contains the elements necessary for an SPPF
client to precisely determine the overall result of various client to precisely determine the overall result of various
operations in the request, and if an error occurred, it provides operations in the request, and if an error occurred, it provides
information about the specific objects or keys in the request that information about the specific objects or keys in the request that
caused the error. caused the error.
The data elements within the SPPF Batch response are described as The data elements within the SPP Protocol over SOAP Batch response
follows: are described as follows:
o clientTransId: Zero or one client transaction ID. This value is o clientTransId: Zero or one client transaction ID. This value is
simply an echo of the client transaction ID that SPPF client simply an echo of the client transaction ID that SPPF client
passed into the SPPF update request. When included in the passed into the SPPF update request. When included in the
request, the SPPF server MUST return it in the corresponding request, the SPPF server MUST return it in the corresponding
response message. response message.
o serverTransId: Exactly one server transaction ID that identifies o serverTransId: Exactly one server transaction ID that identifies
this request for tracking purposes. This value MUST be unique this request for tracking purposes. This value MUST be unique
for a given SPPF server. for a given SPPF server.
skipping to change at page 29, line 52 skipping to change at page 30, line 52
RteGrpOfferKeyResultCodeType where each element identifies the RteGrpOfferKeyResultCodeType where each element identifies the
result code, result message and the specific Route Group Offer result code, result message and the specific Route Group Offer
key that the result relates to. key that the result relates to.
6.2.6. Get Operation Structure 6.2.6. Get Operation Structure
In order to query the details of an object from the Registry, an In order to query the details of an object from the Registry, an
authorized entity can send the spppGetRequest to the registry with a authorized entity can send the spppGetRequest to the registry with a
GetRqstType XML data structure containing one or more object keys GetRqstType XML data structure containing one or more object keys
that uniquely identify the object whose details are being queried. that uniquely identify the object whose details are being queried.
The request strcuture for an SPPF Get operation is contained within The request strcuture for an SPP Protocol over SOAP Get operation is
the generic <spppGetRequest> element while an SPPF Get response is contained within the generic <spppGetRequest> element while an SPP
wrapped within the generic <spppGetResponse> element. The following Protocol over SOAP Get response is wrapped within the generic
sub-sections describe the spppGetRequest and spppGetResponse element. <spppGetResponse> element. The following sub-sections describe the
Refer the examples section for an example of Get operation on each spppGetRequest and spppGetResponse element. Refer the examples
type of SPPF object section for an example of SPP Protocol over SOAP Get operation on
each type of SPPF object
6.2.6.1. Get Request 6.2.6.1. Get Request
<element name="spppGetRequest"> <element name="spppGetRequest">
<complexType> <complexType>
<sequence> <sequence>
<element name="minorVer" <element name="minorVer"
type="sppfb:MinorVerType" minOccurs="0"/> type="sppfb:MinorVerType" minOccurs="0"/>
<element name="objKey" <element name="objKey"
type="sppfb:ObjKeyType" type="sppfb:ObjKeyType"
skipping to change at page 31, line 14 skipping to change at page 32, line 14
6.2.6.2. Get Response 6.2.6.2. Get Response
The spppGetResponse element is described later in section titled The spppGetResponse element is described later in section titled
"Generic Query Response". "Generic Query Response".
6.2.7. Get Route Group Offers Operation Structure 6.2.7. Get Route Group Offers Operation Structure
In addition to the ability to query the details of one or more Route In addition to the ability to query the details of one or more Route
Group offers using an a Route Group Offer key in the spppGetRequest, Group offers using an a Route Group Offer key in the spppGetRequest,
this operation also provides an additonal, more flexible, structure this operation also provides an additional, more flexible, structure
to query for Route Group Offer objects. This additional structure is to query for Route Group Offer objects. This additional structure is
contained within the <getRteGrpOffersRequest> element while the contained within the <getRteGrpOffersRequest> element while the
response is wrapped within the generic <spppGetResponse> element. response is wrapped within the generic <spppGetResponse> element.
The following sub-sections describe the getRteGrpOffersRequest and The following sub-sections describe the getRteGrpOffersRequest and
spppGetResponse elements. spppGetResponse elements.
6.2.7.1. Get Route Group Offers Request 6.2.7.1. Get Route Group Offers Request
Using the details passed into this structure, the server will attempt Using the details passed into this structure, the server will attempt
to find Route Group Offer objects that satisfy all the criteria to find Route Group Offer objects that satisfy all the criteria
skipping to change at page 33, line 21 skipping to change at page 34, line 21
type="sppfb:BasicObjType" type="sppfb:BasicObjType"
minOccurs="0" maxOccurs="unbounded"/> minOccurs="0" maxOccurs="unbounded"/>
</sequence> </sequence>
</complexType> </complexType>
</element> </element>
An <spppGetResponse> contains the elements necessary for the SPPF An <spppGetResponse> contains the elements necessary for the SPPF
client to precisely determine the overall result of the query, and client to precisely determine the overall result of the query, and
details of any SPPF objects that matched the criteria in the request. details of any SPPF objects that matched the criteria in the request.
The data elements within the SPPF query response are described as The data elements within the SPP Protocol over SOAP query response
follows: are described as follows:
o overallResult: Exactly one response code and message pair that o overallResult: Exactly one response code and message pair that
explicitly identifies the result of the request. See the explicitly identifies the result of the request. See the
Response Code section for further details. Response Code section for further details.
o resultObj: The set of zero or more objects that matched the o resultObj: The set of zero or more objects that matched the
query criteria. If no objects matched the query criteria then query criteria. If no objects matched the query criteria then
the result object(s) MUST be empty and the overallResult value the result object(s) MUST be empty and the overallResult value
MUST indicate success (if no matches are found for the query MUST indicate success (if no matches are found for the query
criteria, the response is considered a success). criteria, the response is considered a success).
skipping to change at page 34, line 17 skipping to change at page 35, line 17
<element name="minorVer" <element name="minorVer"
type="sppfb:MinorVerType" minOccurs="0"/> type="sppfb:MinorVerType" minOccurs="0"/>
</sequence> </sequence>
</complexType> </complexType>
</element> </element>
The data elements within the <spppServerStatusRequest> element are The data elements within the <spppServerStatusRequest> element are
described as follows: described as follows:
o minorVer: Zero or one minor version identifier, indicating the o minorVer: Zero or one minor version identifier, indicating the
minor version of the SPPF API that the client is attempting to minor version of the SPP Protocol over SOAP API that the client
use. This is used in conjunction with the major version is attempting to use. This is used in conjunction with the
identifier in the XML namespace to identify the version of SPPF major version identifier in the XML namespace to identify the
that the client is using. If the element is not present, the version of SPP Protocol over SOAP that the client is using. If
server assumes that the client is using the latest minor version the element is not present, the server assumes that the client
is using the latest minor version of SPP Protocol over SOAP
supported by the SPPF server for the given major version. The supported by the SPPF server for the given major version. The
versions supported by a given SPPF server can be retrieved by versions of SPP Protocol over SOAP supported by a given SPPF
the client using this same spppServerStatusRequest without server can be retrieved by the client using this same
passing in the minorVer element. spppServerStatusRequest without passing in the minorVer element.
6.2.9.2. Get Server Details Response 6.2.9.2. Get Server Details Response
An SPP Protocol over SOAP server details response structure is An SPP Protocol over SOAP server details response structure is
contained within the generic <spppServerStatusResponse> element. contained within the generic <spppServerStatusResponse> element.
<element name="spppServerStatusResponse"> <element name="spppServerStatusResponse">
<complexType> <complexType>
<sequence> <sequence>
<element name="overallResult" type="sppfs:ResultCodeType"/> <element name="overallResult" type="sppfs:ResultCodeType"/>
skipping to change at page 35, line 7 skipping to change at page 36, line 7
The data elements within the <spppServerStatusResponse> element are The data elements within the <spppServerStatusResponse> element are
described as follows: described as follows:
o overallResult: Exactly one response code and message pair that o overallResult: Exactly one response code and message pair that
explicitly identifies the result of the request. See the explicitly identifies the result of the request. See the
Response Code section for further details. Response Code section for further details.
o svcMenu: Exactly one element of type SvcMenuType which in turn o svcMenu: Exactly one element of type SvcMenuType which in turn
contains the elements to return the server status and major/ contains the elements to return the server status and major/
minor version of the SPPF supported by the SPPF server (refer minor version of the SPP Protocol over SOAP supported by the
framework document for definition of SvcMenuType) . SPPF server (refer framework document for definition of
SvcMenuType) .
6.3. Response Codes and Messages 6.3. Response Codes and Messages
This section contains the listing of response codes and their This section contains the listing of response codes and their
corresponding human-readable text. These response codes are in corresponding human-readable text. These response codes are in
conformance with the response types defined in the section "Response conformance with the response types defined in the section "Response
Message Types" of the framework document. Message Types" of the framework document.
The response code numbering scheme generally adheres to the theory The response code numbering scheme generally adheres to the theory
formalized in section 4.2.1 of [RFC5321]: formalized in section 4.2.1 of [RFC5321]:
skipping to change at page 35, line 34 skipping to change at page 36, line 35
= Protocol Syntax, 1 = Implementation Specific Business Rule, 2 = Protocol Syntax, 1 = Implementation Specific Business Rule, 2
= Security, 3 = Server System. = Security, 3 = Server System.
o The third and fourth digits of the response code indicate the o The third and fourth digits of the response code indicate the
individual message event within the category defines by the individual message event within the category defines by the
first two digits. first two digits.
The response codes are also categorized as to whether they are The response codes are also categorized as to whether they are
overall response codes that may only be returned in the overall response codes that may only be returned in the
"overallResult" data element in SPPF responses, or object level "overallResult" data element in SPPF responses, or object level
response codes that may only be returned in the "dtlResult" element response codes that may only be returned in the "detailResult"
of the SPPF responses. element of the SPPF responses.
+--------+--------------------------+-------------------------------+ +--------+--------------------------+-------------------------------+
| Result | Result Message | Overall or Object Level | | Result | Result Message | Overall or Object Level |
| Code | | | | Code | | |
+--------+--------------------------+-------------------------------+ +--------+--------------------------+-------------------------------+
| 1000 | Request Succeeded. | Overall Response Code | | 1000 | Request Succeeded. | Overall Response Code |
| | | | | | | |
| 2001 | Request syntax invalid. | Overall Response Code | | 2000 | Request syntax invalid. | Overall Response Code |
| | | | | | | |
| 2002 | Request too large. | Overall Response Code | | 2001 | Request too large. | Overall Response Code |
| | MaxSupported:[Maximum | |
| | requests supported] | |
| | | | | | | |
| 2003 | Version not supported. | Overall Response Code | | 2002 | Version not supported. | Overall Response Code |
| | | | | | | |
| 2103 | Command invalid. | Overall Response Code | | 2100 | Command invalid. | Overall Response Code |
| | | | | | | |
| 2301 | System temporarily | Overall Response Code | | 2300 | System temporarily | Overall Response Code |
| | unavailable. | | | | unavailable. | |
| | | | | | | |
| 2302 | Unexpected internal | Overall Response Code | | 2301 | Unexpected internal | Overall Response Code |
| | system or server error. | | | | system or server error. | |
| | | | | | | |
| 2104 | Attribute value invalid. | Object Level Response Code | | 2101 | Attribute value invalid. | Object Level Response Code |
| | | | | | | |
| | AttrName:[AttributeName] | | | | AttrName:[AttributeName] | |
| | AttrVal:[AttributeValue] | | | | AttrVal:[AttributeValue] | |
| | | | | | | |
| 2105 | Object does not exist. | Object Level Response Code | | 2102 | Object does not exist. | Object Level Response Code |
| | AttrName:[AttributeName] | | | | AttrName:[AttributeName] | |
| | AttrVal:[AttributeValue] | | | | AttrVal:[AttributeValue] | |
| | | | | | | |
| 2106 | Object status or | Object Level Response Code | | 2103 | Object status or | Object Level Response Code |
| | ownership does not allow | | | | ownership does not allow | |
| | for operation. | | | | for operation. | |
| | AttrName:[AttributeName] | | | | AttrName:[AttributeName] | |
| | AttrVal:[AttributeValue] | | | | AttrVal:[AttributeValue] | |
+--------+--------------------------+-------------------------------+ +--------+--------------------------+-------------------------------+
Table 1: Response Codes Numbering Scheme and Messages Table 1: Response Codes Numbering Scheme and Messages
Response message for response code 2001 is "parameterized" with the
following parameter: "[Maximum requests supported]". When the
request is too large, this parameter MUST be used to indicate the
maximum number of requests supported by the server in a single
protocol operation.
Each of the object level response messages are "parameterized" with Each of the object level response messages are "parameterized" with
the following parameters: "AttributeName" and "AttributeValue". the following parameters: "AttributeName" and "AttributeValue".
For example, if an SPPF client sends a request to delete a
Destination Group with a name "TestDG", and it does not already
exist, then the error message returned should be: "Attribute value
invalid. AttrName:dgName AttrVal:TestDG".
The use of these parameters MUST adhere to the rules defined in The use of these parameters MUST adhere to the rules defined in
"Response Message Types" section of the framework document. "Response Message Types" section of the framework document.
7. Protocol Operations 7. Protocol Operations
Refer the "Framework Operations" section of the framework document Refer the "Framework Operations" section of the framework document
for a description of all SPPF operations, and any necessary semantics for a description of all SPPF operations, and any necessary semantics
that MUST be adhered to in order to conform with the SPPF that MUST be adhered to in order to conform with the SPPF
specification. specification.
8. SPPF SOAP WSDL Definition 8. SPP Protocol over SOAP WSDL Definition
The SPPF WSDL and data types are defined below. The WSDL design The SPP Protocol over SOAP WSDL and data types are defined below.
approach is commonly referred to as _Generic WSDL_. It is generic in The WSDL design approach is commonly referred to as _Generic WSDL_.
the sense that there is not a specific WSDL operation defined for It is generic in the sense that there is not a specific WSDL
each object type that is supported by the SPPF protocol. There is a operation defined for each object type that is supported by the SPPF
single WSDL structure for each type of SPPF operation. Each such protocol. There is a single WSDL structure for each type of SPPF
WSDL structure contains exactly one input structure and one output operation. Each such WSDL structure contains exactly one input
structure that wraps any data elements that are part of the incoming structure and one output structure that wraps any data elements that
request and the outgoing response respectively. The spppSOAPBinding are part of the incoming request and the outgoing response
in the WSDL defines the binding style as _document_ and the encoding respectively. The spppSOAPBinding in the WSDL defines the binding
as _literal_. It is this combination of _wrapped_ input and output style as _document_ and the encoding as _literal_. It is this
data structures, _document_ binding style, and _literal_ encoding combination of _wrapped_ input and output data structures, _document_
that characterize the Document Literal Wrapped style of WSDL binding style, and _literal_ encoding that characterize the Document
specifications. Literal Wrapped style of WSDL specifications.
Note: The following WSDL has been formatted (e.g., tabs, spaces) to Note: The following WSDL has been formatted (e.g., tabs, spaces) to
meet I-D requirements. meet I-D requirements.
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<wsdl:definitions xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" <wsdl:definitions xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:sppfb="urn:ietf:params:xml:ns:sppf:base:1" xmlns:sppfb="urn:ietf:params:xml:ns:sppf:base:1"
xmlns:sppfs="urn:ietf:params:xml:ns:sppf:soap:1" xmlns:sppfs="urn:ietf:params:xml:ns:sppf:soap:1"
targetNamespace="urn:ietf:params:xml:ns:sppf:soap:1"> targetNamespace="urn:ietf:params:xml:ns:sppf:soap:1">
<wsdl:types> <wsdl:types>
<xsd:schema xmlns="http://www.w3.org/2001/XMLSchema" <xsd:schema xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:sppfs="urn:ietf:params:xml:ns:sppf:soap:1" xmlns:sppfs="urn:ietf:params:xml:ns:sppf:soap:1"
targetNamespace="urn:ietf:params:xml:ns:sppf:soap:1"> targetNamespace="urn:ietf:params:xml:ns:sppf:soap:1">
<annotation> <annotation>
<documentation> <documentation>
---- Import base schema ---- ---- Import base schema ----
</documentation> </documentation>
</annotation> </annotation>
<import namespace="urn:ietf:params:xml:ns:sppf:base:1" <import namespace="urn:ietf:params:xml:ns:sppf:base:1"
schemaLocation="sppfbase.xsd"/> schemaLocation="sppfbase.xsd"/>
<annotation> <annotation>
<documentation> <documentation>
---- Key type(s) extended ---- Key type(s) extended
from base schema. ---- from base schema. ----
</documentation> </documentation>
</annotation> </annotation>
<complexType name="ObjKeyType"> <complexType name="ObjKeyType">
<complexContent> <complexContent>
<extension base="sppfb:ObjKeyType"> <extension base="sppfb:ObjKeyType">
<sequence> <sequence>
<element name="rant" type="sppfb:OrgIdType"/> <element name="rant" type="sppfb:OrgIdType"/>
<element name="name" type="sppfb:ObjNameType"/> <element name="name" type="sppfb:ObjNameType"/>
<element name="type" type="sppfb:ObjKeyTypeEnum"/> <element name="type" type="sppfs:ObjKeyTypeEnum"/>
</sequence> </sequence>
</extension> </extension>
</complexContent> </complexContent>
</complexType> </complexType>
<simpleType name="ObjKeyTypeEnum">
<restriction base="token">
<enumeration value="RteGrp"/>
<enumeration value="DestGrp"/>
<enumeration value="RteRec"/>
<enumeration value="EgrRte"/>
</restriction>
</simpleType>
<complexType name="RteGrpOfferKeyType"> <complexType name="RteGrpOfferKeyType">
<complexContent> <complexContent>
<extension base="sppfb:RteGrpOfferKeyType"> <extension base="sppfb:RteGrpOfferKeyType">
<sequence> <sequence>
<element name="rteGrpKey" <element name="rteGrpKey"
type="sppfs:ObjKeyType"/> type="sppfs:ObjKeyType"/>
<element name="offeredTo" <element name="offeredTo"
type="sppfb:OrgIdType"/> type="sppfb:OrgIdType"/>
</sequence> </sequence>
</extension> </extension>
skipping to change at page 39, line 42 skipping to change at page 42, line 4
<choice> <choice>
<element name="number" <element name="number"
type="sppfb:NumberType"/> type="sppfb:NumberType"/>
<element name="range" <element name="range"
type="sppfb:NumberRangeType"/> type="sppfb:NumberRangeType"/>
</choice> </choice>
</sequence> </sequence>
</extension> </extension>
</complexContent> </complexContent>
</complexType> </complexType>
<annotation> <annotation>
<documentation> <documentation>
---- Generic Request and ---- Generic Request and
Response Definitions ---- Response Definitions ----
</documentation> </documentation>
</annotation> </annotation>
<element name="spppAddRequest"> <element name="spppAddRequest">
<complexType> <complexType>
<sequence> <sequence>
<element name="clientTransId" <element name="clientTransId"
type="sppfb:TransIdType" minOccurs="0"/> type="sppfb:TransIdType" minOccurs="0"/>
<element name="minorVer" <element name="minorVer"
type="sppfb:MinorVerType" minOccurs="0"/> type="sppfb:MinorVerType" minOccurs="0"/>
<element name="obj" type="sppfb:BasicObjType" <element name="obj" type="sppfb:BasicObjType"
maxOccurs="unbounded"/> maxOccurs="unbounded"/>
skipping to change at page 42, line 19 skipping to change at page 44, line 28
</element> </element>
<element name="spppAddResponse"> <element name="spppAddResponse">
<complexType> <complexType>
<sequence> <sequence>
<element name="clientTransId" <element name="clientTransId"
type="sppfb:TransIdType" minOccurs="0"/> type="sppfb:TransIdType" minOccurs="0"/>
<element name="serverTransId" <element name="serverTransId"
type="sppfb:TransIdType"/> type="sppfb:TransIdType"/>
<element name="overallResult" <element name="overallResult"
type="sppfs:ResultCodeType"/> type="sppfs:ResultCodeType"/>
<element name="dtlResult" <element name="detailResult"
type="sppfs:ObjResultCodeType" type="sppfs:ObjResultCodeType"
minOccurs="0" maxOccurs="unbounded"/> minOccurs="0" maxOccurs="unbounded"/>
</sequence> </sequence>
</complexType> </complexType>
</element> </element>
<element name="spppDelResponse"> <element name="spppDelResponse">
<complexType> <complexType>
<sequence> <sequence>
<element name="clientTransId" <element name="clientTransId"
type="sppfb:TransIdType" minOccurs="0"/> type="sppfb:TransIdType" minOccurs="0"/>
<element name="serverTransId" <element name="serverTransId"
type="sppfb:TransIdType"/> type="sppfb:TransIdType"/>
<element name="overallResult" <element name="overallResult"
type="sppfs:ResultCodeType"/> type="sppfs:ResultCodeType"/>
<element name="dtlResult" <element name="detailResult"
type="sppfs:ObjKeyResultCodeType" type="sppfs:ObjKeyResultCodeType"
minOccurs="0" maxOccurs="unbounded"/> minOccurs="0" maxOccurs="unbounded"/>
</sequence> </sequence>
</complexType> </complexType>
</element> </element>
<element name="spppAcceptResponse"> <element name="spppAcceptResponse">
<complexType> <complexType>
<sequence> <sequence>
<element name="clientTransId" <element name="clientTransId"
type="sppfb:TransIdType" minOccurs="0"/> type="sppfb:TransIdType" minOccurs="0"/>
<element name="serverTransId" <element name="serverTransId"
type="sppfb:TransIdType"/> type="sppfb:TransIdType"/>
<element name="overallResult" <element name="overallResult"
type="sppfs:ResultCodeType"/> type="sppfs:ResultCodeType"/>
<element name="dtlResult" <element name="detailResult"
type="sppfs:RteGrpOfferKeyResultCodeType" type="sppfs:RteGrpOfferKeyResultCodeType"
minOccurs="0" maxOccurs="unbounded"/> minOccurs="0" maxOccurs="unbounded"/>
</sequence> </sequence>
</complexType> </complexType>
</element> </element>
<element name="spppRejectResponse"> <element name="spppRejectResponse">
<complexType> <complexType>
<sequence> <sequence>
<element name="clientTransId" <element name="clientTransId"
type="sppfb:TransIdType" minOccurs="0"/> type="sppfb:TransIdType" minOccurs="0"/>
<element name="serverTransId" <element name="serverTransId"
type="sppfb:TransIdType"/> type="sppfb:TransIdType"/>
<element name="overallResult" <element name="overallResult"
type="sppfs:ResultCodeType"/> type="sppfs:ResultCodeType"/>
<element name="dtlResult" <element name="detailResult"
type="sppfs:RteGrpOfferKeyResultCodeType" type="sppfs:RteGrpOfferKeyResultCodeType"
minOccurs="0" maxOccurs="unbounded"/> minOccurs="0" maxOccurs="unbounded"/>
</sequence> </sequence>
</complexType> </complexType>
</element> </element>
<element name="spppBatchResponse"> <element name="spppBatchResponse">
<complexType> <complexType>
<sequence> <sequence>
<element name="clientTransId" <element name="clientTransId"
type="sppfb:TransIdType" minOccurs="0"/> type="sppfb:TransIdType" minOccurs="0"/>
skipping to change at page 44, line 20 skipping to change at page 46, line 29
<sequence> <sequence>
<element name="overallResult" <element name="overallResult"
type="sppfs:ResultCodeType"/> type="sppfs:ResultCodeType"/>
<element name="svcMenu" <element name="svcMenu"
type="sppfb:SvcMenuType"/> type="sppfb:SvcMenuType"/>
</sequence> </sequence>
</complexType> </complexType>
</element> </element>
<annotation> <annotation>
<documentation> <documentation>
---- Operation Result Type ---- Operation Result Type
Definitions ---- Definitions ----
</documentation> </documentation>
</annotation> </annotation>
<complexType name="ResultCodeType"> <complexType name="ResultCodeType">
<sequence> <sequence>
<element name="code" type="int"/> <element name="code" type="sppfs:ResultCodeValType"/>
<element name="msg" type="token"/> <element name="msg" type="sppfs:MsgType"/>
</sequence> </sequence>
</complexType> </complexType>
<simpleType name="ResultCodeValType">
<restriction base="unsignedShort">
<enumeration value="1000"/>
<enumeration value="2000"/>
<enumeration value="2001"/>
<enumeration value="2002"/>
<enumeration value="2100"/>
<enumeration value="2101"/>
<enumeration value="2102"/>
<enumeration value="2103"/>
<enumeration value="2300"/>
<enumeration value="2301"/>
</restriction>
</simpleType>
<simpleType name="MsgType">
<restriction base="token">
<minLength value="3"/>
<maxLength value="255"/>
</restriction>
</simpleType>
<complexType name="ObjResultCodeType"> <complexType name="ObjResultCodeType">
<complexContent> <complexContent>
<extension base="sppfs:ResultCodeType"> <extension base="sppfs:ResultCodeType">
<sequence> <sequence>
<element name="obj" type="sppfb:BasicObjType"/> <element name="obj" type="sppfb:BasicObjType"/>
</sequence> </sequence>
</extension> </extension>
</complexContent> </complexContent>
</complexType> </complexType>
<complexType name="ObjKeyResultCodeType"> <complexType name="ObjKeyResultCodeType">
skipping to change at page 51, line 25 skipping to change at page 54, line 25
<soapenv:Header/> <soapenv:Header/>
<soapenv:Body> <soapenv:Body>
<urn:spppAddRequest> <urn:spppAddRequest>
<!--Optional:--> <!--Optional:-->
<clientTransId>txn_1479</clientTransId> <clientTransId>txn_1479</clientTransId>
<!--1 or more repetitions:--> <!--1 or more repetitions:-->
<obj xsi:type="urn1:NAPTRType"> <obj xsi:type="urn1:NAPTRType">
<urn1:rant>iana-en:222</urn1:rant> <urn1:rant>iana-en:222</urn1:rant>
<urn1:rar>iana-en:223</urn1:rar> <urn1:rar>iana-en:223</urn1:rar>
<urn1:rrName>RTE_SSP2_SBE2</urn1:rrName> <urn1:rrName>RTE_SSP2_SBE2</urn1:rrName>
<urn1:isInSvc>true</urn1:isInSvc>
<urn1:order>10</urn1:order> <urn1:order>10</urn1:order>
<urn1:flags>u</urn1:flags> <urn1:flags>u</urn1:flags>
<urn1:svcs>E2U+sip</urn1:svcs> <urn1:svcs>E2U+sip</urn1:svcs>
<urn1:regx> <urn1:regx>
<urn1:ere>^(.*)$</urn1:ere> <urn1:ere>^(.*)$</urn1:ere>
<urn1:repl>sip:\1@sbe2.ssp2.example.com</urn1:repl> <urn1:repl>sip:\1@sbe2.ssp2.example.com</urn1:repl>
</urn1:regx> </urn1:regx>
</obj> </obj>
</urn:spppAddRequest> </urn:spppAddRequest>
</soapenv:Body> </soapenv:Body>
skipping to change at page 52, line 22 skipping to change at page 55, line 22
<clientTransId>txn_1479</clientTransId> <clientTransId>txn_1479</clientTransId>
<serverTransId>tx_12345</serverTransId> <serverTransId>tx_12345</serverTransId>
<overallResult> <overallResult>
<code>1000</code> <code>1000</code>
<msg>Request Succeeded.</msg> <msg>Request Succeeded.</msg>
</overallResult> </overallResult>
</ns3:spppAddResponse> </ns3:spppAddResponse>
</S:Body> </S:Body>
</S:Envelope> </S:Envelope>
9.3. Add Route Records -- URIType 9.3. Add Route Records -- URIRteRecType
SSP2 adds another ingress routes in the registry and makes use of SSP2 adds another ingress routes in the registry and makes use of
URIType URIRteRecType
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope <soapenv:Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:urn="urn:ietf:params:xml:ns:sppf:soap:1" xmlns:urn="urn:ietf:params:xml:ns:sppf:soap:1"
xmlns:urn1="urn:ietf:params:xml:ns:sppf:base:1" xmlns:urn1="urn:ietf:params:xml:ns:sppf:base:1"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Header/> <soapenv:Header/>
<soapenv:Body> <soapenv:Body>
<urn:spppAddRequest> <urn:spppAddRequest>
<clientTransId>txn_1479</clientTransId> <clientTransId>txn_1479</clientTransId>
<!--1 or more repetitions:--> <!--1 or more repetitions:-->
<obj xsi:type="urn1:URIType"> <obj xsi:type="urn1:URIRteRecType">
<urn1:rant>iana-en:222</urn1:rant> <urn1:rant>iana-en:222</urn1:rant>
<urn1:rar>iana-en:223</urn1:rar> <urn1:rar>iana-en:223</urn1:rar>
<urn1:rrName>RTE_SSP2_SBE4</urn1:rrName> <urn1:rrName>RTE_SSP2_SBE4</urn1:rrName>
<urn1:isInSvc>true</urn1:isInSvc>
<urn1:ere>^(.*)$</urn1:ere> <urn1:ere>^(.*)$</urn1:ere>
<urn1:uri>sip:\1;npdi@sbe4.ssp2.example.com</urn1:uri> <urn1:uri>sip:\1;npdi@sbe4.ssp2.example.com</urn1:uri>
</obj> </obj>
</urn:spppAddRequest> </urn:spppAddRequest>
</soapenv:Body> </soapenv:Body>
</soapenv:Envelope> </soapenv:Envelope>
The registry returns a success response. The registry returns a success response.
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/"> <S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
skipping to change at page 53, line 24 skipping to change at page 56, line 24
<overallResult> <overallResult>
<code>1000</code> <code>1000</code>
<msg>Request Succeeded.</msg> <msg>Request Succeeded.</msg>
</overallResult> </overallResult>
</ns3:spppAddResponse> </ns3:spppAddResponse>
</S:Body> </S:Body>
</S:Envelope> </S:Envelope>
9.4. Add Route Group 9.4. Add Route Group
SSP2 creates the grouping of the ingress routes and choses higher SSP2 creates the grouping of the ingress routes and chooses higher
precedence for RTE_SSP2_SBE2 by setting a lower number for the precedence for RTE_SSP2_SBE2 by setting a lower number for the
"priority" attribute, a protocol agnostic precedence indicator. "priority" attribute, a protocol agnostic precedence indicator.
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope <soapenv:Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:urn="urn:ietf:params:xml:ns:sppf:soap:1" xmlns:urn="urn:ietf:params:xml:ns:sppf:soap:1"
xmlns:urn1="urn:ietf:params:xml:ns:sppf:base:1" xmlns:urn1="urn:ietf:params:xml:ns:sppf:base:1"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Header/> <soapenv:Header/>
skipping to change at page 56, line 26 skipping to change at page 59, line 26
<S:Body> <S:Body>
<ns3:spppAddResponse <ns3:spppAddResponse
xmlns:ns2="urn:ietf:params:xml:ns:sppf:base:1" xmlns:ns2="urn:ietf:params:xml:ns:sppf:base:1"
xmlns:ns3="urn:ietf:params:xml:ns:sppf:soap:1"> xmlns:ns3="urn:ietf:params:xml:ns:sppf:soap:1">
<clientTransId>txn_1479</clientTransId> <clientTransId>txn_1479</clientTransId>
<serverTransId>tx_12345</serverTransId> <serverTransId>tx_12345</serverTransId>
<overallResult> <overallResult>
<code>1000</code> <code>1000</code>
<msg>Request Succeeded.</msg> <msg>Request Succeeded.</msg>
</overallResult> </overallResult>
<dtlResult> <detailResult>
<code>1000</code> <code>1000</code>
<msg>Request Succeeded.</msg> <msg>Request Succeeded.</msg>
<obj xsi:type="ns2:TNType"> <obj xsi:type="ns2:TNType">
<ns2:rant>iana-en:222</ns2:rant> <ns2:rant>iana-en:222</ns2:rant>
<ns2:rar>iana-en:223</ns2:rar> <ns2:rar>iana-en:223</ns2:rar>
<ns2:cDate>2010-05-30T09:30:10Z</ns2:cDate> <ns2:cDate>2010-05-30T09:30:10Z</ns2:cDate>
<ns2:dgName>DEST_GRP_SSP2_1</ns2:dgName> <ns2:dgName>DEST_GRP_SSP2_1</ns2:dgName>
<ns2:tn>+12025556666</ns2:tn> <ns2:tn>+12025556666</ns2:tn>
<ns2:corInfo> <ns2:corInfo>
<ns2:corClaim>true</ns2:corClaim> <ns2:corClaim>true</ns2:corClaim>
<ns2:cor>true</ns2:cor> <ns2:cor>true</ns2:cor>
<ns2:corDate>2010-05-30T09:30:11Z</ns2:corDate> <ns2:corDate>2010-05-30T09:30:11Z</ns2:corDate>
</ns2:corInfo> </ns2:corInfo>
</obj> </obj>
</dtlResult> </detailResult>
</ns3:spppAddResponse> </ns3:spppAddResponse>
</S:Body> </S:Body>
</S:Envelope> </S:Envelope>
9.6. Add LRN 9.6. Add LRN
If another entity that SSP2 shares the routes with has access to If another entity that SSP2 shares the routes with has access to
Number Portability data, it may choose to perform route lookups by Number Portability data, it may choose to perform route lookups by
routing number. Therefore, SSP2 associates a routing number to a routing number. Therefore, SSP2 associates a routing number to a
destination group in order to facilitate ingress route discovery. destination group in order to facilitate ingress route discovery.
skipping to change at page 75, line 44 skipping to change at page 78, line 44
<overallResult> <overallResult>
<code>1000</code> <code>1000</code>
<msg>Request Succeeded.</msg> <msg>Request Succeeded.</msg>
</overallResult> </overallResult>
</ns3:spppDelResponse> </ns3:spppDelResponse>
</S:Body> </S:Body>
</S:Envelope> </S:Envelope>
9.19. Delete Public Identity 9.19. Delete Public Identity
SSP2 choses to de-activate the TN and remove it from the registry. SSP2 chooses to de-activate the TN and remove it from the registry.
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope <soapenv:Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:urn="urn:ietf:params:xml:ns:sppf:soap:1" xmlns:urn="urn:ietf:params:xml:ns:sppf:soap:1"
xmlns:urn1="urn:ietf:params:xml:ns:sppf:base:1" xmlns:urn1="urn:ietf:params:xml:ns:sppf:base:1"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Header/> <soapenv:Header/>
<soapenv:Body> <soapenv:Body>
<urn:spppDelRequest> <urn:spppDelRequest>
skipping to change at page 83, line 7 skipping to change at page 86, line 7
<overallResult> <overallResult>
<code>1000</code> <code>1000</code>
<msg>Request Succeeded.</msg> <msg>Request Succeeded.</msg>
</overallResult> </overallResult>
</ns3:spppBatchResponse> </ns3:spppBatchResponse>
</S:Body> </S:Body>
</S:Envelope> </S:Envelope>
10. Security Considerations 10. Security Considerations
SPPF is used to query and update session peering data and addresses, SPP Protocol over SOAP is used to query and update session peering
so the ability to access this protocol should be limited to users and data and addresses, so the ability to access this protocol should be
systems that are authorized to query and update this data. Because limited to users and systems that are authorized to query and update
this data is sent in both directions, it may not be sufficient for this data. Because this data is sent in both directions, it may not
just the client or user to be authenticated with the server. The be sufficient for just the client or user to be authenticated with
identity of the server should also be authenticated by the client, the server. The identity of the server should also be authenticated
which is often accomplished using the TLS certificate exchange and by the client, which is often accomplished using the TLS certificate
validation described in [RFC2818]. SPPF data may include sensitive exchange and validation described in [RFC2818]. SPP Protocol over
information, routing data, lists of resolvable addresses, etc. So SOAP messages may include sensitive information, routing data, lists
when used in a production setting and across non-secure networks, of resolvable addresses, etc. So when used in a production setting
SPPF should only be used over communications channels that provide and across non-secure networks, SPP Protocol over SOAP should only be
strong encryption for data privacy. used over communications channels that provide strong encryption for
data privacy.
10.1. Integrity, Privacy, and Authentication 10.1. Integrity, Privacy, and Authentication
The SPPF SOAP binding relies on an underlying secure transport for The SPP Protocol over SOAP binding relies on an underlying secure
integrity and privacy. Such transports are expected to include TLS/ transport for integrity and privacy. Such transports are expected to
HTTPS. In addition to the application level authentication imposed include TLS/HTTPS. In addition to the application level
by an SPPF server, there are a number of options for authentication authentication imposed by an SPPF server, there are a number of
within the transport layer and the messaging envelope. These include options for authentication within the transport layer and the
TLS client certificates, HTTP Digest Access Authentication, and messaging envelope. These include TLS client certificates, HTTP
digital signatures within SOAP headers. Digest Access Authentication, and digital signatures within SOAP
headers.
At a miniumum, all conforming SPP Protocol over SOAP implementations At a minimum, all conforming SPP Protocol over SOAP implementations
MUST support HTTPS. MUST support HTTPS.
10.2. Vulnerabilities 10.2. Vulnerabilities
The above protocols may have various vulnerabilities, and these may The above protocols may have various vulnerabilities, and these may
be inherited by SPP Protocol over SOAP. And SPPF itself may have be inherited by SPP Protocol over SOAP. SPP Protocol over SOAP
vulnerabilities because an authorization model is not explicitly itself may have vulnerabilities because an authorization model is not
specified in the current specification. explicitly specified in the current specification.
It is important that SPPF implementations implement an authorization Sections 5 and 10.1 describe requirements for HTTPS support using
model that considers the source of each SPPF query or update request TLS. Non-anonymous TLS servers can optionally request a certificate
and determines whether it is reasonable to authorize that source to from a TLS client; that option is not a requirement for this
perform that specific query or update. protocol. This presents a denial of service risk in which
unauthenticated clients can consume server CPU resources by creating
TLS sessions. The risk is increased if the server supports client-
initiated renegotiation. This risk can be mitigated by disabling
client-initiated renegotiation on the server and by ensuring that
other means (such as firewall access control lists) are used to
restrict unauthenticated client access to servers.
In conjunction with the above, it is important that SPP Protocol over
SOAP implementations implement an authorization model that considers
the source of each query or update request and determines whether it
is reasonable to authorize that source to perform that specific query
or update.
10.3. Deployment Environment Specifics 10.3. Deployment Environment Specifics
Some deployments of SPP Protocol over SOAP could choose to use Some deployments of SPP Protocol over SOAP could choose to use
transports without encryption. This presents vulnerabilities but transports without encryption. This presents vulnerabilities but
could be selected for deployments involving closed networks or could be selected for deployments involving closed networks or
debugging scenarios. However, the vulnerabilities of such a debugging scenarios. However, the vulnerabilities of such a
deployment could be a lack of integrity and privacy of the data deployment could be a lack of integrity and privacy of the data
transported over SPPF messages in this type of deployment. transported in this type of deployment.
11. IANA Considerations 11. IANA Considerations
This document uses URNs to describe XML namespaces and XML schemas This document uses URNs to describe XML namespaces and XML schemas
conforming to a registry mechanism described in [RFC3688]. conforming to a registry mechanism described in [RFC3688].
URN assignments are requested: urn:ietf:params:xml:ns:sppf:soap URN assignments requested are: urn:ietf:params:xml:ns:sppf:soap:1
12. Acknowledgements 12. Acknowledgements
This document is a result of various discussions held by the DRINKS This document is a result of various discussions held by the DRINKS
design team, which is comprised of the following individuals, in design team, which is comprised of the following individuals, in
alphabetical order: Alexander Mayrhofer, David Schwartz, Deborah A alphabetical order: Alexander Mayrhofer, David Schwartz, Deborah A
Guyton, Jean-Francois Mule Kenneth Cartwright, Lisa Dusseault, Manjul Guyton, Jean-Francois Mule Kenneth Cartwright, Lisa Dusseault, Manjul
Maharishi, Mickael Marrache, Otmar Lendl, Peter Saint-Andre, Richard Maharishi, Mickael Marrache, Otmar Lendl, Peter Saint-Andre, Richard
Shockey, Samuel Melloul, Sumanth Channabasappa, Syed Ali, and Vikas Shockey, Samuel Melloul, Scott Hollenbeck, Sumanth Channabasappa,
Bhatia . Syed Ali, and Vikas Bhatia .
13. References 13. References
13.1. Normative References 13.1. Normative References
[I-D.draft-ietf-drinks-spp-framework] [I-D.draft-ietf-drinks-spp-framework]
Mule, J-F., Cartwright, K., Ali, S., Mayrhofer, A., and V. Mule, J-F., Cartwright, K., Ali, S., Mayrhofer, A., and V.
Bhatia, "Session Peering Provisioning Framework", Bhatia, "Session Peering Provisioning Framework",
draft-ietf-drinks-spp-framework-00 (work in progress), draft-ietf-drinks-spp-framework-01 (work in progress),
January 2012. March 2012.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
Leach, P., Luotonen, A., and L. Stewart, "HTTP Leach, P., Luotonen, A., and L. Stewart, "HTTP
 End of changes. 92 change blocks. 
252 lines changed or deleted 334 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/