draft-ietf-drinks-spp-protocol-over-soap-03.txt   draft-ietf-drinks-spp-protocol-over-soap-04.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: April 26, 2013 J-F. Mule Expires: January 13, 2014 J-F. Mule
CableLabs CableLabs
A. Mayrhofer A. Mayrhofer
enum.at GmbH enum.at GmbH
October 23, 2012 July 12, 2013
Session Peering Provisioning (SPP) Protocol over SOAP Session Peering Provisioning (SPP) Protocol over SOAP
draft-ietf-drinks-spp-protocol-over-soap-03 draft-ietf-drinks-spp-protocol-over-soap-04
Abstract Abstract
The Session Peering Provisioning Framework (SPPF) is an XML framework The Session Peering Provisioning Framework (SPPF) specifies the data
that exists to enable the provisioning of session establishment data model and the overall structure to provision session establishment
into Session Data Registries or SIP Service Provider data stores. data into Session Data Registries and SIP Service Provider data
Sending XML data structures over Simple Object Access Protocol (SOAP) stores. To utilize this framework one needs a transport protocol.
and HTTP(s) is a widely used, de-facto standard for messaging between Given that Simple Object Access Protocol (SOAP) is currently widely
elements of provisioning systems. Therefore the combination of SOAP used for messaging between elements of such provisioning systems,
and HTTP(s) as a transport protocol for SPPF is a natural fit. The this document specifies the usage of SOAP (via HTTPS) as the
obvious benefits include leveraging existing industry expertise, transport protocol for SPPF. The benefits include leveraging
leveraging existing standards, and a higher probability that existing prevalent expertise, and a higher probability that existing
provisioning systems can be more easily integrated with this provisioning systems will be able to easily migrate to using an SPPF
protocol. This document describes the specification for transporting based protocol.
SPPF XML structures over SOAP and HTTP(s).
Status of this Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 April 26, 2013. This Internet-Draft will expire on January 13, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2013 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
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 . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. SOAP Features and Protocol Layering . . . . . . . . . . . . . 6 3. SOAP Features and Protocol Layering . . . . . . . . . . . . . 4
4. HTTP(s) Features and SPP Protocol over SOAP . . . . . . . . . 9 4. HTTP(s) Features and SPP Protocol over SOAP . . . . . . . . . 6
5. Authentication, Integrity and Confidentiality . . . . . . . . 10 5. Authentication, Integrity and Confidentiality . . . . . . . . 7
6. Language Identification . . . . . . . . . . . . . . . . . . . 11 6. Language Identification . . . . . . . . . . . . . . . . . . . 7
7. SPP Protocol SOAP Data Structures . . . . . . . . . . . . . . 12 7. SPP Protocol SOAP Data Structures . . . . . . . . . . . . . . 7
7.1. Concrete Object Key Types . . . . . . . . . . . . . . . . 12 7.1. Concrete Object Key Types . . . . . . . . . . . . . . . . 7
7.1.1. Generic Object Key . . . . . . . . . . . . . . . . . . 12 7.1.1. Generic Object Key . . . . . . . . . . . . . . . . . 8
7.1.2. Public Identity Object Key . . . . . . . . . . . . . . 13 7.1.2. Public Identity Object Key . . . . . . . . . . . . . 9
7.1.3. SED Group Offer Key . . . . . . . . . . . . . . . . . 14 7.1.3. SED Group Offer Key . . . . . . . . . . . . . . . . . 10
7.2. Operation Request and Response Structures . . . . . . . . 15 7.2. Operation Request and Response Structures . . . . . . . . 11
7.2.1. Add Operation Structure . . . . . . . . . . . . . . . 15 7.2.1. Add Operation Structure . . . . . . . . . . . . . . . 11
7.2.2. Delete Operation Structure . . . . . . . . . . . . . . 18 7.2.2. Delete Operation Structure . . . . . . . . . . . . . 14
7.2.3. Accept Operation Structure . . . . . . . . . . . . . . 21 7.2.3. Accept Operation Structure . . . . . . . . . . . . . 17
7.2.4. Reject Operation Structure . . . . . . . . . . . . . . 24 7.2.4. Reject Operation Structure . . . . . . . . . . . . . 20
7.2.5. Batch Operation Structure . . . . . . . . . . . . . . 27 7.2.5. Batch Operation Structure . . . . . . . . . . . . . . 23
7.2.6. Get Operation Structure . . . . . . . . . . . . . . . 30 7.2.6. Get Operation Structure . . . . . . . . . . . . . . . 26
7.2.7. Get SED Group Offers Operation Structure . . . . . . . 32 7.2.7. Get SED Group Offers Operation Structure . . . . . . 27
7.2.8. Generic Query Response . . . . . . . . . . . . . . . . 33 7.2.8. Generic Query Response . . . . . . . . . . . . . . . 29
7.2.9. Get Server Details Operation Structure . . . . . . . . 34 7.2.9. Get Server Details Operation Structure . . . . . . . 29
7.3. Response Codes and Messages . . . . . . . . . . . . . . . 35 7.3. Response Codes and Messages . . . . . . . . . . . . . . . 31
8. Protocol Operations . . . . . . . . . . . . . . . . . . . . . 38 8. Protocol Operations . . . . . . . . . . . . . . . . . . . . . 33
9. SPP Protocol over SOAP WSDL Definition . . . . . . . . . . . . 39 9. SPP Protocol over SOAP WSDL Definition . . . . . . . . . . . 33
10. SPP Protocol over SOAP Examples . . . . . . . . . . . . . . . 51 10. SPP Protocol over SOAP Examples . . . . . . . . . . . . . . . 44
10.1. Add Destination Group . . . . . . . . . . . . . . . . . . 51 10.1. Add Destination Group . . . . . . . . . . . . . . . . . 45
10.2. Add SED Records . . . . . . . . . . . . . . . . . . . . . 53 10.2. Add SED Records . . . . . . . . . . . . . . . . . . . . 46
10.3. Add SED Records -- URIType . . . . . . . . . . . . . . . 54 10.3. Add SED Records -- URIType . . . . . . . . . . . . . . . 48
10.4. Add SED Group . . . . . . . . . . . . . . . . . . . . . . 55 10.4. Add SED Group . . . . . . . . . . . . . . . . . . . . . 49
10.5. Add Public Identity -- Successful COR claim . . . . . . . 57 10.5. Add Public Identity -- Successful COR claim . . . . . . 50
10.6. Add LRN . . . . . . . . . . . . . . . . . . . . . . . . . 59 10.6. Add LRN . . . . . . . . . . . . . . . . . . . . . . . . 51
10.7. Add TN Range . . . . . . . . . . . . . . . . . . . . . . 60 10.7. Add TN Range . . . . . . . . . . . . . . . . . . . . . . 53
10.8. Add TN Prefix . . . . . . . . . . . . . . . . . . . . . . 61 10.8. Add TN Prefix . . . . . . . . . . . . . . . . . . . . . 54
10.9. Enable Peering -- SED Group Offer . . . . . . . . . . . . 62 10.9. Enable Peering -- SED Group Offer . . . . . . . . . . . 55
10.10. Enable Peering -- SED Group Offer Accept . . . . . . . . 64 10.10. Enable Peering -- SED Group Offer Accept . . . . . . . . 56
10.11. Add Egress Route . . . . . . . . . . . . . . . . . . . . 65 10.11. Add Egress Route . . . . . . . . . . . . . . . . . . . . 57
10.12. Remove Peering -- SED Group Offer Reject . . . . . . . . 67 10.12. Remove Peering -- SED Group Offer Reject . . . . . . . . 59
10.13. Get Destination Group . . . . . . . . . . . . . . . . . . 68 10.13. Get Destination Group . . . . . . . . . . . . . . . . . 60
10.14. Get Public Identity . . . . . . . . . . . . . . . . . . . 70 10.14. Get Public Identity . . . . . . . . . . . . . . . . . . 61
10.15. Get SED Group Request . . . . . . . . . . . . . . . . . . 71 10.15. Get SED Group Request . . . . . . . . . . . . . . . . . 62
10.16. Get SED Group Offers Request . . . . . . . . . . . . . . 73 10.16. Get SED Group Offers Request . . . . . . . . . . . . . . 64
10.17. Get Egress Route . . . . . . . . . . . . . . . . . . . . 75 10.17. Get Egress Route . . . . . . . . . . . . . . . . . . . . 65
10.18. Delete Destination Group . . . . . . . . . . . . . . . . 77 10.18. Delete Destination Group . . . . . . . . . . . . . . . . 66
10.19. Delete Public Identity . . . . . . . . . . . . . . . . . 78 10.19. Delete Public Identity . . . . . . . . . . . . . . . . . 67
10.20. Delete SED Group Request . . . . . . . . . . . . . . . . 80 10.20. Delete SED Group Request . . . . . . . . . . . . . . . . 69
10.21. Delete SED Group Offers Request . . . . . . . . . . . . . 81 10.21. Delete SED Group Offers Request . . . . . . . . . . . . 70
10.22. Delete Egress Route . . . . . . . . . . . . . . . . . . . 82 10.22. Delete Egress Route . . . . . . . . . . . . . . . . . . 71
10.23. Batch Request . . . . . . . . . . . . . . . . . . . . . . 83 10.23. Batch Request . . . . . . . . . . . . . . . . . . . . . 72
11. Security Considerations . . . . . . . . . . . . . . . . . . . 86 11. Security Considerations . . . . . . . . . . . . . . . . . . . 74
11.1. Vulnerabilities . . . . . . . . . . . . . . . . . . . . . 86 11.1. Vulnerabilities . . . . . . . . . . . . . . . . . . . . 75
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 87 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 75
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 88 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 75
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 89 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 76
14.1. Normative References . . . . . . . . . . . . . . . . . . 89 14.1. Normative References . . . . . . . . . . . . . . . . . . 76
14.2. Informative References . . . . . . . . . . . . . . . . . 89 14.2. Informative References . . . . . . . . . . . . . . . . . 76
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 77
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
transactional provisioning of user addresses and their associated transactional provisioning of user addresses and their associated
session establishment data. While the server side of SPPF is likely session establishment data. While the server side of SPPF is likely
to reside in a separate organization's network, resulting the SPPF to reside in a separate organization's network, resulting in the SPPF
provisioning transactions traversing the Internet as they are provisioning transactions traversing the Internet as they are
propagated from the SPPF client to the SPPF server. Given the propagated from the SPPF client to the SPPF server. Given the
current state of industry practice and technologies, SOAP and HTTP(s) current state of industry practice and technologies, SOAP and HTTP(S)
are well suited for this type of environment. This document are well suited for this type of environment. This document
describes the specification for transporting SPPF XML structures over describes the specification for transporting SPPF XML structures over
SOAP and HTTP(s). SOAP and HTTP(S).
The specification in this document for transporting SPPF XML The specification in this document for transporting SPPF XML
structures over SOAP and HTTP(s) is primarily comprised of five structures over SOAP and HTTP(s) is primarily comprised of five
subjects: (1) a description of any applicable SOAP features, (2) any subjects: (1) a description of any applicable SOAP features, (2) any
applicable HTTP features, (3) security considerations, and perhaps applicable HTTP features, (3) security considerations, and perhaps
most importantly, (4) the Web Services Description Language (WSDL) most importantly, (4) the Web Services Description Language (WSDL)
definition for SPP Protocol over SOAP, and (5) "transport" specific definition for SPP Protocol over SOAP, and (5) "transport" specific
XML schema type definitions XML Schema type definitions
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3. SOAP Features and Protocol Layering 3. SOAP Features and Protocol Layering
The list of SOAP features that are explicitly used and required for The list of SOAP features that are explicitly used and required for
SPP Protocol over SOAP are limited. Most SOAP features are not SPP Protocol over SOAP are limited. Most SOAP features are not
necessary for SPPF. SPP Protocol over SOAP primarily uses SOAP necessary for SPPF. SPP Protocol over SOAP primarily uses SOAP
simply as a standard message envelope technology. The SOAP message simply as a standard message envelope technology. The SOAP message
envelope is comprised of the SOAP header and body. As described in envelope is comprised of the SOAP header and body. As described in
the SOAP specifications, the SOAP header can contain optional, the SOAP specifications [SOAPREF], the SOAP header can contain
application specific, information about the message. The SOAP body optional, application specific, information about the message. The
contains the SPPF message itself, whose structure is defined by the SOAP body contains the SPPF message itself, whose structure is
combination of one of the WSDL operations defined in this document defined by the combination of one of the WSDL operations defined in
and the SPPF XML data structures defined in this document and the this document and the SPPF XML data structures defined in this
SPPF document. SPPF does not rely on any data elements in the SOAP document and the SPPF document. SPPF does not rely on any data
header. All relevant data elements are defined in the SPPF XML elements in the SOAP header. All relevant data elements are defined
schema described in [I-D.draft-ietf-drinks-spp-framework] and the in the SPPF XML schema described in
SPPF WSDL types specification described in this document. [I-D.draft-ietf-drinks-spp-framework] and the SPPF WSDL types
specification described in this document and in
[I-D.draft-ietf-drinks-spp-framework].
WSDL is a widely standardized and adopted technology for defining the WSDL is a widely standardized and adopted technology for defining the
top-level structures of the messages that are transported within the top-level structures of the messages that are transported within the
body of a SOAP message. The WSDL definition for the SPPF SOAP body of a SOAP message. The WSDL definition for the SPPF SOAP
messages is defined later in this document, which imports by messages is defined later in this document, which imports by
reference the XML data types contained in the SPPF schema. The IANA reference the XML data types contained in the SPPF schema. The IANA
registry where the SPPF schema resides is described in The IETF XML registry where the SPPF schema resides is described in the IETF XML
Registry [RFC3688]. Registry [RFC3688].
There are multiple structural styles that SOAP WSDL allows. But the There are multiple structural styles that WSDL allows. The best
best practice for this type of application is what is sometimes practice for this type of application is what is sometimes referred
referred to as the Document Literal Wrapped style of designing SOAP to as the "document/literal wrapped style". This style is generally
WSDL. This style is generally regarded as an optimal approach that regarded as an optimal approach that enhances maintainability,
enhances maintainability, comprehension, portability, and, to a comprehension, portability, and, to a certain extent, performance.
certain extent, performance. It is characterized by setting the It is characterized by setting the soapAction binding style as
soapAction binding style as _document_, the soapAction encoding style "document", the soapAction encoding style as "literal", and then
as _literal_, and then defining the SOAP messages to simply contain a defining the SOAP messages to simply contain a single data element
single data element that _wraps_ a data structure containing all the that "wraps" a data structure containing all the required input or
required input or output data elements. The figure below illustrates output data elements. The figure below illustrates this high level
this high level technical structure as conceptual layers 3 through 6. technical structure as conceptual layers 3 through 6.
+-------------+ +-------------+
(1) | Transport |Example: (1) | Transport |Example:
| Protocol | TCP, TLS, BEEP, etc. | Protocol | TCP, TLS, BEEP, etc.
+-------------+
| +-------------+
V |
+-------------+ V
(2) | Message |Example: +-------------+
| Envelope | HTTP, SOAP, None, etc. (2) | Message |Example:
+-------------+ | Envelope | HTTP, SOAP, None, etc.
| +-------------+
V |
+--------------+ V
+----| SOAP |---+ +--------------+
|(3) | Operation | | +----| SOAP |---+
Contains | +--------------+ | Contains |(3) | Operation | |
| Example: | Contains | +--------------+ | Contains
V submitAddRqst V | Example: |
+--------------+ +-------------+ V submitAddRqst V
|SOAP Request | |SOAP Response| +--------------+ +-------------+
Example: | Message | (4) | Message | Example: |SOAP Request | |SOAP Response|
spppAdd | (Operation | | (Operation | spppAdd Example: | Message | (4) | Message | Example:
RequestMsg | Input) | | Output) | ResponseMsg spppAdd | (Operation | | (Operation | spppAdd
+--------------+ +-------------+ RequestMsg | Input) | | Output) | ResponseMsg
| | +--------------+ +-------------+
Contains | | Contains | |
| | Contains | | Contains
V V | |
+---------------+ +---------------+ V V
Example: | Wrapped | (5) | Wrapped | Example: +---------------+ +---------------+
spppAdd |Request Object | |Response Object| spppAdd Example: | Wrapped | (5) | Wrapped | Example:
Request +---------------+ +---------------+ Response spppAdd |Request Object | |Response Object| spppAdd
| | Request +---------------+ +---------------+ Response
Contains | | Contains | |
| | Contains | | Contains
V V | |
+-------------+ +---------------+ V V
| SPPF | | SPPF | +-------------+ +---------------+
|XML Types | (6) | XML Types | | SPPF | | SPPF |
+-------------+ +---------------+ |XML Types | (6) | XML Types |
+-------------+ +---------------+
Figure 1: Layering and Technical Structure of the SPP Protocol over Figure 1: Layering and Technical Structure of the SPP Protocol over
SOAP Messages SOAP Messages
The operations supported by SPP Protocol over SOAP are normatively The operations supported by SPP Protocol over SOAP are normatively
defined later in this document. Each SOAP operation defines a defined later in this document. Each SOAP operation defines a
request/input message and a response/output message. Each such request/input message and a response/output message. Each such
request and response message then contains a single object that wraps request and response message then contains a single object that wraps
the SPPF XML data types that comprise the inputs and the outputs, the SPPF XML data types that comprise the inputs and the outputs,
respectively, of the SOAP operation. respectively, of the SOAP operation.
SOAP faults are not used by the SPP Protocol over SOAP. All success SOAP faults are not used by the SPP Protocol over SOAP. All success
and error responses are specified in the "Response Codes and and error responses are specified in Section 7.3 of this document.
Messages" section of this document. However, if a SOAP fault were to However, if a SOAP fault were to occur, perhaps due to failures in
occur, perhaps due to failures in the SOAP message handling layer of the SOAP message handling layer of a SOAP library, the client
a SOAP library, the client application should capture and handle the application should capture and handle the fault. Specifics on how to
fault. Specifics on how to handle such SOAP faults, if they should handle such SOAP faults, if they should occur, will be specific to
occur, will be specific to the chosen SOAP implementation. the chosen SOAP implementation.
SOAP 1.2 [SOAPREF] or higher and WSDL 1.1 [WSDLREF] or higher SHOULD This document RECOMMENDS SOAP 1.2 [SOAPREF] or higher, and WSDL 1.1
be used. [WSDLREF] or higher.
SPPF is a request/reply framework that allows a client application to SPPF is a request/reply framework that allows a client application to
submit provisioning data and query requests to a server. The SPPF submit provisioning data and query requests to a server. The SPPF
data structures are designed to be protocol agnostic. Concerns data structures are designed to be protocol agnostic. Concerns
regarding encryption, non-repudiation, and authentication are beyond regarding encryption, non-repudiation, and authentication are beyond
the scope of this document. For more details, please refer to the the scope of this document. For more details, please refer to
"Transport Protocol Requirements" section in the framework document. Section 4 ("Transport Protocol Requirements") of
[I-D.draft-ietf-drinks-spp-framework].
As illustrated in the previous diagram, SPPF can be viewed as a set As illustrated in the previous diagram, SPPF can be viewed as a set
of layers that collectively define the structure of an SPPF request of layers that collectively define the structure of an SPPF request
and response. Layers 1 and 2 represent the transport, envelope, and and response. Layers 1 and 2 represent the transport, envelope, and
authentication technologies. This document defines layers 3, 4, 5, authentication technologies. This document defines layers 3, 4, 5,
and 6 below for SPP Protocol over SOAP. and 6 for SPP Protocol over SOAP.
1. Layer 1: The transport protocol layer represents the 1. Layer 1: The transport protocol layer represents the
communication mechanism between the client and server. SPPF can communication mechanism between the client and server. SPPF can
be layered over any transport protocol that provides a set of be layered over any transport protocol that provides a set of
basic requirements defined in the Transport Protocol Requirements basic requirements defined in Section 4 of
section. But this document specifies the required mechanism. [I-D.draft-ietf-drinks-spp-framework].
2. Layer 2: The message envelope layer is optional, but can provide 2. Layer 2: The message envelope layer is optional, but can provide
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.
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 provide 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 SPP Protocol over SOAP 4. HTTP(s) Features and SPP Protocol over SOAP
SOAP is not tied to HTTP(s), however, for reasons described in the While SOAP is not tied to HTTP(S), 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.
be used for the SPPF HTTP connections.
HTTP 1.1 [RFC2616] or higher SHOULD be used. Implementations compliant with this document MUST use HTTP 1.1
[RFC2616] or higher. Also, implementations SHOULD use persistent
connections.
5. Authentication, Integrity and Confidentiality 5. Authentication, Integrity and Confidentiality
To accomplish authentication, conforming SPP Protocol over SOAP To accomplish authentication, conforming SPP Protocol over SOAP
Clients and Servers MUST use HTTP Digest Authentication as defined in Clients and Servers MUST use HTTP Digest Authentication as defined in
[RFC2617] as the authentication mechanism. [RFC2617].
To achieve integrity and privacy, conforming SPP Protocol over SOAP To achieve integrity and privacy, conforming SPP Protocol over SOAP
Clients and Servers MUST support Transport Layer Security (TLS) as Clients and Servers MUST support Transport Layer Security (TLS) as
defined in [RFC5246] as the secure transport mechanism. defined in [RFC5246] as the secure transport mechanism.
6. Language Identification 6. Language Identification
Section 9 of [I-D.draft-ietf-drinks-spp-framework] requires transport Section 9 of [I-D.draft-ietf-drinks-spp-framework] requires transport
protocols to provide a mechanism to transmit language tags together protocols to provide a mechanism to transmit language tags together
with human-readable messages. When conforming SPP Protocol SOAP with human-readable messages. When conforming SPP Protocol SOAP
servers use such tagging, the XML "lang" attribute (see Section 2.12 servers use such tagging, the XML "lang" attribute
of [W3C.REC-xml-20081126]) MUST be used for that purpose. Clients ([W3C.REC-xml-20081126], Section 2.12) MUST be used. Clients MAY use
MAY use the HTTP "Accept-Language" header field (see Section 14.4 of the HTTP "Accept-Language" header field (see Section 14.4 of
[RFC2616]) in order to indicate their language preference. [RFC2616]) in order to indicate their language preference.
7. SPP Protocol SOAP Data Structures 7. SPP Protocol SOAP Data Structures
SPP Protocol over SOAP uses a set of XML based data structures for SPP Protocol over SOAP uses a set of XML based data structures for
all the supported operations and any parameters that those operations all the supported operations and any parameters that those operations
are applied to. As also mentioned earlier in this document, these are applied to. As also mentioned earlier in this document, these
XML structures are envelope-independent and transport-independent. XML structures are envelope-independent and transport-independent.
Refer the "Protocol Operations" section of this document for a Refer the "Protocol Operations" (Section 8) of this document for a
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.
7.1. Concrete Object Key Types 7.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 abstract manner and delegates the concrete representation to in an abstract manner and delegates the concrete representation to
any conforming transport protocol. The following sub-sections define any conforming transport protocol. The following sub-sections define
the various types of concrete object key types used in various the various types of concrete object key types used in various
operations in SPP Protocol over SOAP: operations in SPP Protocol over SOAP.
7.1.1. Generic Object Key 7.1.1. Generic Object Key
Most objects in SPP Protocol over SOAP are uniquely identified by the Most objects in SPP Protocol over SOAP are uniquely identified by the
attributes in the generic object key (Refer "Generic Object Key Type" attributes in the generic object key (Refer Section 5.2.1 "Generic
section of the framework document for details). The concrete XML Object Key Type" of [I-D.draft-ietf-drinks-spp-framework] for
representation of ObjKeyType is as below: 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="sppfs: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
the object. 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 value that represents the type of SPPF o type: The enumeration value that represents the type of SPPF
object. For example, both a Destination Group and a SED Group object. For example, both a Destination Group and a SED Group can
can have the same name "TestObj" and be associated with same have the same name "TestObj" and be associated with same
Registrant Id "iana-en:222". Hence, to uniquely identify the Registrant Id. Hence, to uniquely identify the object that
object that represents a Destination Group with the name represents a Destination Group with the name "TestObj", the type
"TestObj", the type "DestGrp" must be specified when using this "DestGrp" must be specified when using this concrete ObjKeyType
concrete ObjKeyType structure to identify the Destination Group structure to identify the Destination Group "TestObj".
"TestObj".
The object types in SPP Protocol over SOAP that MUST adhere to the The object types in SPP Protocol over SOAP MUST adhere to the above
above definition of generic object key are defined as an enumeration definition of generic object key, and are defined as an enumeration
in the XML data structure. The structure of the the enumeration is in the XML data structure as follows:
as follows:
<simpleType name="ObjKeyTypeEnum"> <simpleType name="ObjKeyTypeEnum">
<restriction base="token"> <restriction base="token">
<enumeration value="SedGrp"/> <enumeration value="SedGrp"/>
<enumeration value="DestGrp"/> <enumeration value="DestGrp"/>
<enumeration value="SedRec"/> <enumeration value="SedRec"/>
<enumeration value="EgrRte"/> <enumeration value="EgrRte"/>
</restriction> </restriction>
</simpleType> </simpleType>
7.1.2. Public Identity Object Key 7.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, URI, or a TN Range and cannot be cleanly a Telephone Number (TN), Routing Number (RN), TN Prefix, URI, or a TN
identified with the attributes in the generic ObjKeyType. The Range and cannot be cleanly identified with the attributes in the
definition of PubIdKeyType is as below: generic ObjKeyType. The 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"/>
<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" <element name="uri"
type="anyURI"/> type="anyURI"/>
</choice> </choice>
</sequence> </sequence>
</extension> </extension>
</complexContent> </complexContent>
</complexType> </complexType>
The PubIdKeyType has the data elements as described below: The PubIdKeyType has data elements, as described below:
o rant: The identifier of the registrant organization that owns
the object.
o dgName: The name of the Destination Group that a Public o rant: The identifier of the registrant organization that owns the
Identifier is member of. Note that this is an optional object.
attribute of the key as Public Identifiers may or may not be
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 Section 12 of
that contains the value and type of a number . [I-D.draft-ietf-drinks-spp-framework]) 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 Section 12 of
document) that contains a range of numbers. [I-D.draft-ietf-drinks-spp-framework]) that contains a range of
numbers.
o uri: A value that represents a Public Identifier. o uri: A value that represents a Public Identifier.
Any instance of PubIdKeyType MUST contain exactly one element from Any instance of PubIdKeyType MUST contain exactly one element from
the following set of elements: "number", "range", "uri". the following set of elements: "number", "range", "uri".
7.1.3. SED Group Offer Key 7.1.3. SED Group Offer Key
In addition to the attributes in the generic ObjKeyType, a SED Group In addition to the attributes in the generic ObjKeyType, a SED Group
Offer object is uniquely identified by the organization ID of the Offer object is uniquely identified by the organization ID of the
organization to whom an SED Group has been offered. The definition organization to whom an SED Group has been offered. The definition
of SedGrpOfferKeyType is as below: of SedGrpOfferKeyType is as below:
skipping to change at page 15, line 19 skipping to change at page 10, line 38
<sequence> <sequence>
<element name="sedGrpKey" type="sppfs:ObjKeyType"/> <element name="sedGrpKey" type="sppfs:ObjKeyType"/>
<element name="offeredTo" type="sppfb:OrgIdType"/> <element name="offeredTo" type="sppfb:OrgIdType"/>
</sequence> </sequence>
</extension> </extension>
</complexContent> </complexContent>
</complexType> </complexType>
The SedGrpOfferKeyType has the data elements as described below: The SedGrpOfferKeyType has the data elements as described below:
o sedGrpKey: Identifies the SED Group that was offered. o sedGrpKey: Identifies the SED Group that was offered.
o offeredTo: The organization ID of the organization that was o offeredTo: The organization ID of the organization that was
offered the SED Group object identified by the sedGrpKey. offered the SED Group object identified by the sedGrpKey.
7.2. Operation Request and Response Structures 7.2. Operation Request and Response Structures
An SPPF client interacts with an SPPF server by using one of the An SPPF client interacts with an SPPF server by sending one or more
supported transport mechanisms to send one or more requests to the requests to the server, and by receiving corresponding responses from
server and receive corresponding replies from the server. The basic the server. The basic set of operations that an SPPF client can
set of operations that an SPPF client can submit to an SPPF server submit to an SPPF server and the semantics of those operations are
and the semantics of those operations are defined in the "Framework defined in Section 7 ("Framework Operations") of
Operations" section of the framework document. The following sub- [I-D.draft-ietf-drinks-spp-framework]. The following sub-sections
sections describe the XML data structures that are used for each of describe the XML data structures that are used for each of those
those types of operations for a SPP Protocol over SOAP types of operations for a SPP Protocol over SOAP implementation.
implementation.
7.2.1. Add Operation Structure 7.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 SPP Protocol over SOAP Add response <spppAddRequest> element while an SPP Protocol over SOAP Add response
is wrapped within an <spppAddResponse> element. The following sub- is wrapped within an <spppAddResponse> element. The following sub-
sections describe the spppAddRequest and spppAddResponse elements. sections describe the spppAddRequest and spppAddResponse elements.
Refer the "SPP Protocol over SOAP Examples" section of this document Refer to Section 10 for an example of Add operation on each type of
for an example of Add operation on each type of SPPF object. SPPF object.
7.2.1.1. Add Request 7.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"
skipping to change at page 16, line 26 skipping to change at page 12, line 5
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>
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
server MUST echo back this value to the client in the MUST echo back this value to the client in the corresponding
corresponding response to the incoming request. SPPF server response to the incoming request. SPPF server will not check this
will not check this value for uniqueness. value for uniqueness.
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 SPPF API that the client is attempting to
use. This is used in conjunction with the major version use. This is used in conjunction with the major version
identifier in the XML namespace to identify the version of SPPF identifier in the XML namespace to identify the version of SPPF
that the client is using. If the element is not present, the that the client is using. If the element is not present, the
server assumes that the client is using the latest minor version server assumes that the client is using the latest minor version
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 supported by a given SPPF server can be retrieved by the
the client using the SPPF server menu operation described later client using the "Get Server Details" operation described in
in the document. Section 7.2.9.
o obj: One or more elements of abstract type BasicObjType (defined o obj: One or more elements of abstract type BasicObjType (defined
in the framework document). Each element contains all the in [I-D.draft-ietf-drinks-spp-framework]). Each element contains
attributes of an SPPF object that that the client is requesting all the attributes of an SPPF object that that the client is
the SPPF server to add. Refer the "Framework Data Model requesting the SPPF server to add. Refer to section 3.1 of
Objects" section of the framework document for the XML structure [I-D.draft-ietf-drinks-spp-framework] for the XML structure of all
of all concrete types, for various SPPF objects, that extend concrete types, for various SPPF objects, that extend from
from abstract BasicObjType and hence are eligible to be passed abstract BasicObjType and hence are eligible to be passed into
into this element. The elements are processed by the SPPF this element. The elements are processed by the SPPF server in
server in the order in which they are included in the request. the order in which they are included in the request. With respect
With respect to handling of error conditions, conforming SPPP to handling of error conditions, conforming SPPP SOAP servers MUST
SOAP servers MUST stop processing BasicObjType elements in the stop processing BasicObjType elements in the request at the first
request at the first error, and roll back any BasicObjType error, and roll back any BasicObjType elements that had already
elements that had already been processed for that add request been processed for that add request ("stop and rollback").
("stop and rollback").
7.2.1.2. Add Response 7.2.1.2. Add Response
An SPP Protocol over SOAP add response object is contained within the An SPP Protocol over SOAP add response object is contained within the
generic <spppAddResponse> element. This response structure is used generic <spppAddResponse> element. This response structure is used
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>
skipping to change at page 18, line 15 skipping to change at page 13, line 35
</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 SPP Protocol over SOAP Add response are The data elements within the SPP Protocol over SOAP Add response are
described as 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
for a given SPPF server. 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 Section 7.3
Response Code section for further details. for further details.
o detailResult: 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 [I-D.draft-ietf-drinks-spp-framework])
This element will be present only if an object level error has triplet. This element will be present only if an object level
occurred. It indicates the error condition and the exact error has occurred. It indicates the error condition and the
request object that contributed to the error. The response code exact request object that contributed to the error. The response
will reflect the exact error. See the Response Code section for code will reflect the exact error. See Section 7.3 for further
further details. details.
7.2.2. Delete Operation Structure 7.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 Delete request is wrapped within the <spppDelRequest> element SOAP Delete request is wrapped within the <spppDelRequest> element
while a SPP Protocol over SOAP Delete response is wrapped within the while a SPP Protocol over SOAP Delete response is wrapped within the
generic <spppDelResponse> element. The following sub-sections generic <spppDelResponse> element. The following sub-sections
describe the spppDelRequest and spppDelResponse elements. Refer the describe the spppDelRequest and spppDelResponse elements. Refer to
"SPP Protocol over SOAP Examples" section of this document for an Section 10 for an example of Delete operation on each type of SPPF
example of Delete operation on each type of SPPF object. object.
7.2.2.1. Delete Request 7.2.2.1. Delete Request
An SPP Protocol over SOAP Delete request definition is contained An SPP Protocol over SOAP Delete request definition is contained
within 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"
skipping to change at page 19, line 26 skipping to change at page 14, line 45
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"/>
</sequence> </sequence>
</complexType> </complexType>
</element> </element>
The data elements within the <spppDelRequest> element are described The data elements within the <spppDelRequest> 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
server MUST echo back this value to the client in the MUST echo back this value to the client in the corresponding
corresponding response to the incoming request. SPPF server response to the incoming request. SPPF server will not check this
will not check this value for uniqueness. value for uniqueness.
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 SPPF API that the client is attempting to
use. This is used in conjunction with the major version use. This is used in conjunction with the major version
identifier in the XML namespace to identify the version of SPPF identifier in the XML namespace to identify the version of SPPF
that the client is using. If the element is not present, the that the client is using. If the element is not present, the
server assumes that the client is using the latest minor version server assumes that the client is using the latest minor version
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 supported by a given SPPF server can be retrieved by the
the client using the SPPF server menu operation described later client using the Get Server Details Operation described in
in the document. Section 7.2.9.
o objKey: One or more elements of abstract type ObjKeyType (as o objKey: One or more elements of abstract type ObjKeyType (as
defined in the framework document). Each element contains defined in [I-D.draft-ietf-drinks-spp-framework]). Each element
attributes that uniquely identify the object that the client is contains attributes that uniquely identify the object that the
requesting the server to delete. Refer the "Concrete Object client is requesting the server to delete. Refer to Section 7.1
Keys" section of this document for a description of all concrete for a description of all concrete object key types, for various
object key types, for various SPPF objects, which are eligible SPPF objects, which are eligible to be passed into this element.
to be passed into this element. The elements are processed by The elements are processed by the SPPF server in the order in
the SPPF server in the order in which they are included in the which they are included in the request. With respect to handling
request. With respect to handling of error conditions, of error conditions, conforming SPPP SOAP servers MUST stop
conforming SPPP SOAP servers MUST stop processing ObjKeyType processing ObjKeyType elements in the request at the first error,
elements in the request at the first error, and roll back any and roll back any ObjKeyType elements that had already been
ObjKeyType elements that had already been processed for that processed for that delete request ("stop and rollback").
delete request ("stop and rollback").
7.2.2.2. Delete Response 7.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>
skipping to change at page 21, line 15 skipping to change at page 16, line 32
</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 SPP Protocol over SOAP Delete response The data elements within the SPP Protocol over SOAP Delete response
are described as 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
for a given SPPF server. 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 Section 7.3
Response Code section for further details. for further details.
o detailResult: 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 [I-D.draft-ietf-drinks-spp-framework])
element will be present only if an specific object key level triplet. This element will be present only if an specific object
error has occurred. It indicates the error condition and the key level error has occurred. It indicates the error condition
exact request object key that contributed to the error. The and the exact request object key that contributed to the error.
response code will reflect the exact error. See the Response The response code will reflect the exact error. See Section 7.3
Code section for further details. for further details.
7.2.3. Accept Operation Structure 7.2.3. Accept Operation Structure
In SPPF, a SED Group Offer can be accepted or rejected by, or on In SPPF, a SED Group Offer can be accepted or rejected by, or on
behalf of, the registrant to whom the SED Group has been offered behalf of, the registrant to whom the SED Group has been offered
(refer "Framework Data Model Objects" section of the framework (refer Section 3.1 of [I-D.draft-ietf-drinks-spp-framework] for a
document for a description of the SED Group Offer object). The description of the SED Group Offer object). The Accept operation is
Accept operation is used to accept such SED Group Offers by, or on used to accept such SED Group Offers by, or on behalf of, the
behalf of, the Registrant. The request structure for an SPP Protocol Registrant. The request structure for an SPP Protocol over SOAP
over SOAP Accept operation is wrapped within the <spppAcceptRequest> Accept operation is wrapped within the <spppAcceptRequest> element
element while an SPP Protocol over SOAP Accept response is wrapped while an SPP Protocol over SOAP Accept response is wrapped within the
within the generic <spppAcceptResponse> element. The following sub- generic <spppAcceptResponse> element. The following sub-sections
sections describe the spppAcceptRequest and spppAcceptResponse describe the spppAcceptRequest and spppAcceptResponse elements.
elements. Refer the "SPP Protocol over SOAP Examples" section of Refer to Section 10 for an example of Accept operation on a SED Group
this document for an example of Accept operation on a SED Group
Offer. Offer.
7.2.3.1. Accept Request Structure 7.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>
skipping to change at page 22, line 28 skipping to change at page 17, line 45
<element name="sedGrpOfferKey" <element name="sedGrpOfferKey"
type="sppfs:SedGrpOfferKeyType" type="sppfs:SedGrpOfferKeyType"
maxOccurs="unbounded"/> maxOccurs="unbounded"/>
</sequence> </sequence>
</complexType> </complexType>
</element> </element>
The data elements within the <spppAcceptRequest> element are The data elements within the <spppAcceptRequest> element are
described as follows: described 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
track, log or correlate requests and their responses. SPPF
server MUST echo back this value to the client in the
corresponding response to the incoming request. SPPF server
will not check this value for uniqueness.
o minorVer: Zero or one minor version identifier, indicating the This value can be used at the discretion of the SPPF client to
minor version of the SPPF API that the client is attempting to track, log or correlate requests and their responses. SPPF server
use. This is used in conjunction with the major version MUST echo back this value to the client in the corresponding
identifier in the XML namespace to identify the version of SPPF response to the incoming request. SPPF server will not check this
that the client is using. If the element is not present, the value for uniqueness.
server assumes that the client is using the latest minor version
supported by the SPPF server for the given major version. The
versions supported by a given SPPF server can be retrieved by
the client using the SPPF server menu operation described later
in the document.
o sedGrpOfferKey: One or more elements of type SedGrpOfferKeyType o minorVer: Zero or one minor version identifier, indicating the
(as defined in this document). Each element contains attributes minor version of the SPPF API that the client is attempting to
that uniquely identify a SED Group Offer that the client is use. This is used in conjunction with the major version
requesting the server to accept. The elements are processed by identifier in the XML namespace to identify the version of SPPF
the SPPF server in the order in which they are included in the that the client is using. If the element is not present, the
request. With respect to handling of error conditions, server assumes that the client is using the latest minor version
conforming SPPP SOAP servers MUST stop processing supported by the SPPF server for the given major version. The
SedGrpOfferKeyType elements in the request at the first error, versions supported by a given SPPF server can be retrieved by the
and roll back any SedGrpOfferKeyType elements that had already client using the Get Server Details Operation described in
been processed for that accept request ("stop and rollback"). Section 7.2.9.
o sedGrpOfferKey: One or more elements of type SedGrpOfferKeyType
(as defined in this document). Each element contains attributes
that uniquely identify a SED Group Offer that the client is
requesting the server to accept. The elements are processed by
the SPPF server in the order in which they are included in the
request. With respect to handling of error conditions, conforming
SPPP SOAP servers MUST stop processing SedGrpOfferKeyType elements
in the request at the first error, and roll back any
SedGrpOfferKeyType elements that had already been processed for
that accept request ("stop and rollback").
7.2.3.2. Accept Response 7.2.3.2. Accept Response
An SPP Protocol over SOAP accept response structure is contained An SPP Protocol over SOAP accept response structure is contained
within the generic <sppAcceptResponse> element. This response within the generic <sppAcceptResponse> element. This response
structure is used for an Accept request on a SED Group Offer. structure is used for an Accept request on a SED Group Offer.
<element name="spppAcceptResponse"> <element name="spppAcceptResponse">
<complexType> <complexType>
<sequence> <sequence>
skipping to change at page 24, line 15 skipping to change at page 19, line 29
</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 SED if an error occurred, it provides information about the specific SED
Group Offer key(s) that caused the error. Group Offer key(s) that caused the error.
The data elements within the SPP Protocol over SOAP Accept response The data elements within the SPP Protocol over SOAP Accept response
are described as 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
for a given SPPF server. 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 Section 7.3
Response Code section for further details. for further details.
o detailResult: An optional response code, response message, and o detailResult: An optional response code, response message, and
SedGrpOfferKeyType (as defined in this document) triplet. This SedGrpOfferKeyType (as defined in this document) triplet. This
element will be present only if any specific SED Group Offer key element will be present only if any specific SED Group Offer key
level error has occurred. It indicates the error condition and level error has occurred. It indicates the error condition and
the exact request SED Group Offer key that contributed to the the exact request SED 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
Response Code section for further details. Section 7.3 for further details.
7.2.4. Reject Operation Structure 7.2.4. Reject Operation Structure
In SPPF, SED Group Offer can be accepted or rejected by, or on behalf In SPPF, SED Group Offer can be accepted or rejected by, or on behalf
of, the registrant to whom the SED Group has been offered (refer of, the registrant to whom the SED Group has been offered (refer
"Framework Data Model Objects" section of the framework document for "Framework Data Model Objects" section of
a description of the SED Group Offer object). The Reject operation [I-D.draft-ietf-drinks-spp-framework] for a description of the SED
is used to reject such SED Group Offers by, or on behalf of, the Group Offer object). The Reject operation is used to reject such SED
Registrant. The request structure for an SPP Protocol over SOAP Group Offers by, or on behalf of, the Registrant. The request
Reject operation is wrapped within the <spppRejectRequest> element structure for an SPP Protocol over SOAP Reject operation is wrapped
while an SPP Protocol over SOAP Reject response is wrapped within the within the <spppRejectRequest> element while an SPP Protocol over
generic <spppRejecResponse> element. The following sub-sections SOAP Reject response is wrapped within the generic
describe the spppRejectRequest and spppRejecResponse elements. Refer <spppRejecResponse> element. The following sub-sections describe the
the "SPP Protocol over SOAP Examples" section of this document for an spppRejectRequest and spppRejecResponse elements. Refer to
example of Reject operation on a SED Group Offer. Section 10 for an example of Reject operation on a SED Group Offer.
7.2.4.1. Reject Request 7.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>
<element name="clientTransId" <element name="clientTransId"
skipping to change at page 25, line 26 skipping to change at page 21, line 5
type="sppfb:MinorVerType" minOccurs="0"/> type="sppfb:MinorVerType" minOccurs="0"/>
<element name="sedGrpOfferKey" <element name="sedGrpOfferKey"
type="sppfs:SedGrpOfferKeyType" type="sppfs:SedGrpOfferKeyType"
maxOccurs="unbounded"/> maxOccurs="unbounded"/>
</complexType> </complexType>
</element> </element>
The data elements within the <spppRejectRequest> element are The data elements within the <spppRejectRequest> element are
described as follows: described 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
server MUST echo back this value to the client in the MUST echo back this value to the client in the corresponding
corresponding response to the incoming request. SPPF server response to the incoming request. SPPF server will not check this
will not check this value for uniqueness. value for uniqueness.
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 SPPF API that the client is attempting to
use. This is used in conjunction with the major version use. This is used in conjunction with the major version
identifier in the XML namespace to identify the version of SPPF identifier in the XML namespace to identify the version of SPPF
that the client is using. If the element is not present, the that the client is using. If the element is not present, the
server assumes that the client is using the latest minor version server assumes that the client is using the latest minor version
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 supported by a given SPPF server can be retrieved by the
the client using the SPPF server menu operation described later client using the Get Server Details Operation described in
in the document. Section 7.2.9.
o sedGrpOfferKey: One or more elements of type SedGrpOfferKeyType o sedGrpOfferKey: One or more elements of type SedGrpOfferKeyType
(as defined in this document). Each element contains attributes (as defined in this document). Each element contains attributes
that uniquely identify a SED Group Offer that the client is that uniquely identify a SED Group Offer that the client is
requesting the server to reject. The elements are processed by requesting the server to reject. The elements are processed by
the SPPF server in the order in which they are included in the the SPPF server in the order in which they are included in the
request. With respect to handling of error conditions, request. With respect to handling of error conditions, conforming
conforming SPPP SOAP servers MUST stop processing SPPF servers MUST stop processing SedGrpOfferKeyType elements in
SedGrpOfferKeyType elements in the request at the first error, the request at the first error, and roll back any
and roll back any SedGrpOfferKeyType elements that had already SedGrpOfferKeyType elements that had already been processed for
been processed for that reject request ("stop and rollback"). that reject request ("stop and rollback").
7.2.4.2. Reject Response 7.2.4.2. Reject Response
An SPP Protocol over SOAP reject response structure is contained An SPP Protocol over SOAP reject response structure is contained
within the generic <sppRejectResponse> element. This response within the generic <sppRejectResponse> element. This response
structure is used for an Reject request on a SED Group Offer. structure is used for an Reject request on a SED Group Offer.
<element name="spppRejectResponse"> <element name="spppRejectResponse">
<complexType> <complexType>
<sequence> <sequence>
skipping to change at page 27, line 4 skipping to change at page 22, line 24
<complexType name="SedGrpOfferKeyResultCodeType"> <complexType name="SedGrpOfferKeyResultCodeType">
<complexContent> <complexContent>
<extension base="sppfs:ResultCodeType"> <extension base="sppfs:ResultCodeType">
<sequence> <sequence>
<element name="sedGrpOfferKey" type="sppfs:SedGrpOfferKeyType"/> <element name="sedGrpOfferKey" type="sppfs:SedGrpOfferKeyType"/>
</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 SED if an error occurred, it provides information about the specific SED
Group Offer key(s) that caused the error. Group Offer key(s) that caused the error.
The data elements within the SPP Protocol over SOAP Reject response The data elements within the SPP Protocol over SOAP Reject response
are described as 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
for a given SPPF server. 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 Section 7.3
Response Code section for further details. for further details.
o detailResult: An optional response code, response message, and o detailResult: An optional response code, response message, and
SedGrpOfferKeyType (as defined in this document) triplet. This SedGrpOfferKeyType (as defined in this document) triplet. This
element will be present only if any specific SED Group Offer key element will be present only if any specific SED Group Offer key
level error has occurred. It indicates the error condition and level error has occurred. It indicates the error condition and
the exact request SED Group Offer key that contributed to the the exact request SED 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
Response Code section for further details. Section 7.3 for further details.
7.2.5. Batch Operation Structure 7.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 "SPP Protocol over SOAP Examples" section of this document for an to Section 10 for an example of a batch operation.
example of a batch operation.
7.2.5.1. Batch Request Structure 7.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 28, line 27 skipping to change at page 24, line 5
<element name="rejectSedGrpOffer" <element name="rejectSedGrpOffer"
type="sppfs:SedGrpOfferKeyType"/> type="sppfs:SedGrpOfferKeyType"/>
</choice> </choice>
</sequence> </sequence>
</complexType> </complexType>
</element> </element>
The data elements within the <sppBatchRequest> element are described The data elements within the <sppBatchRequest> 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
server MUST echo back this value to the client in the MUST echo back this value to the Client in the corresponding
corresponding response to the incoming request. SPPF server response to the incoming request. SPPF Server will not check this
will not check this value for uniqueness. value for uniqueness.
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 SPPF API that the client is attempting to
use. This is used in conjunction with the major version use. This is used in conjunction with the major version
identifier in the XML namespace to identify the version of SPPF identifier in the XML namespace to identify the version of SPPF
that the client is using. If the element is not present, the that the client is using. If the element is not present, the
server assumes that the client is using the latest minor version server assumes that the client is using the latest minor version
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 supported by a given SPPF server can be retrieved by the
the client using the SPPF server menu operation described later client using the Get Server Details Operation described in
in the document. Section 7.2.9.
o addObj: One or more elements of abstract type BasicObjType where o addObj: One or more elements of abstract type BasicObjType where
each element identifies an object that needs to be added. each element identifies an object that needs to be added.
o delObj: One or more elements of abstract type ObjKeyType where o delObj: One or more elements of abstract type ObjKeyType where
each element identifies a key for the object that needs to be each element identifies a key for the object that needs to be
deleted . deleted .
o acceptSedGrpOffer: One or more elements of type o acceptSedGrpOffer: One or more elements of type SedGrpOfferKeyType
SedGrpOfferKeyType where each element identifies a SED Group where each element identifies a SED Group Offer that needs to be
Offer that needs to be accepted. accepted.
o rejectSedGrpOffer: One or more elements of type o rejectSedGrpOffer: One or more elements of type SedGrpOfferKeyType
SedGrpOfferKeyType where each element identifies a SED Group where each element identifies a SED Group Offer that needs to be
Offer that needs to be rejected. rejected.
With respect to handling of error conditions, conforming SPPP SOAP With respect to handling of error conditions, conforming SPPP SOAP
servers MUST stop processing elements in the request at the first servers MUST stop processing elements in the request at the first
error, and roll back any elements that had already been processed for error, and roll back any elements that had already been processed for
that batch request ("stop and rollback"). that batch request ("stop and rollback").
7.2.5.2. Batch Response 7.2.5.2. Batch Response
An SPP Protocol over SOAP batch response structure is contained An SPP Protocol over SOAP batch response structure is contained
within the generic <sppBatchResponse> element. This response within the generic <sppBatchResponse> element. This response
skipping to change at page 30, line 10 skipping to change at page 25, line 33
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 SPP Protocol over SOAP Batch response The data elements within the SPP Protocol over SOAP Batch response
are described as 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
for a given SPPF server. 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 Section 7.3
Response Code section for further details. for further details.
o addResult: One or more elements of type ObjResultCodeType where o addResult: One or more elements of type ObjResultCodeType where
each element identifies the result code, result message and the each element identifies the result code, result message and the
specific object that the result relates to. specific object that the result relates to.
o delResult: One or more elements of type ObjKeyResultCodeType o delResult: One or more elements of type ObjKeyResultCodeType where
where each element identifies the result code, result message each element identifies the result code, result message and the
and the specific object key that the result relates to. specific object key that the result relates to.
o acceptResult: One or more elements of type o acceptResult: One or more elements of type
SedGrpOfferKeyResultCodeType where each element identifies the SedGrpOfferKeyResultCodeType where each element identifies the
result code, result message and the specific SED Group Offer key result code, result message and the specific SED Group Offer key
that the result relates to. that the result relates to.
o rejectResult: One or more elements of type o rejectResult: One or more elements of type
SedGrpOfferKeyResultCodeType where each element identifies the SedGrpOfferKeyResultCodeType where each element identifies the
result code, result message and the specific SED Group Offer key result code, result message and the specific SED Group Offer key
that the result relates to. that the result relates to.
7.2.6. Get Operation Structure 7.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 structure for an SPP Protocol over SOAP Get operation is The request structure for an SPP Protocol over SOAP Get operation is
contained within the generic <spppGetRequest> element while an SPP contained within the generic <spppGetRequest> element while an SPP
Protocol over SOAP Get response is wrapped within the generic Protocol over SOAP Get response is wrapped within the generic
<spppGetResponse> element. The following sub-sections describe the <spppGetResponse> element. The following sub-sections describe the
spppGetRequest and spppGetResponse element. Refer the examples spppGetRequest and spppGetResponse element. Refer to Section 10 for
section for an example of SPP Protocol over SOAP Get operation on an example of SPP Protocol over SOAP Get operation on each type of
each type of SPPF object SPPF object
7.2.6.1. Get Request 7.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"
maxOccurs="unbounded"/> maxOccurs="unbounded"/>
</sequence> </sequence>
</complexType> </complexType>
</element> </element>
The data elements within the <spppGetRequest> element are described The data elements within the <spppGetRequest> element are described
as follows: 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 SPPF API that the client is attempting to
use. This is used in conjunction with the major version use. This is used in conjunction with the major version
identifier in the XML namespace to identify the version of SPPF identifier in the XML namespace to identify the version of SPPF
that the client is using. If the element is not present, the that the client is using. If the element is not present, the
server assumes that the client is using the latest minor version server assumes that the client is using the latest minor version
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 supported by a given SPPF server can be retrieved by the
the client using the SPPF server menu operation described later client using the Get Server Details Operation described in
in the document. Section 7.2.9.
o objKey: One or more elements of abstract type ObjKeyType (as o objKey: One or more elements of abstract type ObjKeyType (as
defined in the framework document). Each element contains defined in [I-D.draft-ietf-drinks-spp-framework]). Each element
attributes that uniquely identify the object that the client is contains attributes that uniquely identify the object that the
requesting the server to query. Refer the "Concrete Object client is requesting the server to query. Refer to Section 7.1 of
Keys" section of this document for a description of all concrete this document for a description of all concrete object key types,
object key types, for various SPPF objects, which are eligible for various SPPF objects, which are eligible to be passed into
to be passed into this element. this element.
7.2.6.2. Get Response 7.2.6.2. Get Response
The spppGetResponse element is described later in section titled The spppGetResponse element is described in Section 7.2.8.
"Generic Query Response".
7.2.7. Get SED Group Offers Operation Structure 7.2.7. Get SED Group Offers Operation Structure
In addition to the ability to query the details of one or more SED In addition to the ability to query the details of one or more SED
Group offers using an a SED Group Offer key in the spppGetRequest, Group offers using an a SED Group Offer key in the spppGetRequest,
this operation also provides an additional, more flexible, structure this operation also provides an additional, more flexible, structure
to query for SED Group Offer objects. This additional structure is to query for SED Group Offer objects. This additional structure is
contained within the <getSedGrpOffersRequest> element while the contained within the <getSedGrpOffersRequest> 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 getSedGrpOffersRequest and The following sub-sections describe the getSedGrpOffersRequest and
spppGetResponse elements. spppGetResponse elements.
7.2.7.1. Get SED Group Offers Request 7.2.7.1. Get SED 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 SED Group Offer objects that satisfy all the criteria passed to find SED Group Offer objects that satisfy all the criteria passed
into the request. If no criteria is passed in then the server will into the request. If no criteria is passed in then the SPPF Server
return the list of SED Group Offer objects that belongs to the will return the list of SED Group Offer objects that belongs to the
registrant. If there are no matching SED Group Offers found then an registrant. If there are no matching SED Group Offers found then an
empty result set will be returned. empty result set will be returned.
<element name="getSedGrpOffersRequest"> <element name="getSedGrpOffersRequest">
<complexType> <complexType>
<sequence> <sequence>
<element name="minorVer" type="sppfb:MinorVerType" <element name="minorVer" type="sppfb:MinorVerType"
minOccurs="0"/> minOccurs="0"/>
<element name="offeredBy" type="sppfb:OrgIdType" <element name="offeredBy" type="sppfb:OrgIdType"
minOccurs="0" maxOccurs="unbounded"/> minOccurs="0" maxOccurs="unbounded"/>
skipping to change at page 32, line 45 skipping to change at page 28, line 23
minOccurs="0"/> minOccurs="0"/>
<element name="sedGrpOfferKey" type="sppfs:SedGrpOfferKeyType" <element name="sedGrpOfferKey" type="sppfs:SedGrpOfferKeyType"
minOccurs="0" maxOccurs="unbounded"/> minOccurs="0" maxOccurs="unbounded"/>
</sequence> </sequence>
</complexType> </complexType>
</element> </element>
The data elements within the <getSedGrpOffersRequest> element are The data elements within the <getSedGrpOffersRequest> 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 SPPF API that the client is attempting to
use. This is used in conjunction with the major version use. This is used in conjunction with the major version
identifier in the XML namespace to identify the version of SPPF identifier in the XML namespace to identify the version of SPPF
that the client is using. If the element is not present, the that the client is using. If the element is not present, the
server assumes that the client is using the latest minor version server assumes that the client is using the latest minor version
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 supported by a given SPPF server can be retrieved by the
the client using the SPPF server menu operation described later client using the Get Server Details Operation described in
in the document. Section 7.2.9.
o offeredBy: Zero or more organization IDs. Only offers that are o offeredBy: Zero or more organization IDs. Only offers that are
offered to the organization IDs in this list should be included offered to the organization IDs in this list should be included in
in the result set. The result set is also subject to other the result set. The result set is also subject to other query
query criteria in the request. criteria in the request.
o offeredTo: Zero or more organization IDs. Only offers that are o offeredTo: Zero or more organization IDs. Only offers that are
offered by the organization IDs in this list should be included offered by the organization IDs in this list should be included in
in the result set. The result set is also subject to other the result set. The result set is also subject to other query
query criteria in the request. criteria in the request.
o status: The status of the offer, offered or accepted. Only o status: The status of the offer, offered or accepted. Only offers
offers in the specified status should be included in the result in the specified status should be included in the result set. If
set. If this element is not present then the status of the this element is not present then the status of the offer should
offer should not be considered in the query. The result set is not be considered in the query. The result set is also subject to
also subject to other query criteria in the request. other query criteria in the request.
o sedGrpOfferKey: Zero or more SED Group Offer Keys. Only offers o sedGrpOfferKey: Zero or more SED Group Offer Keys. Only offers
having one of these keys should be included in the result set. having one of these keys should be included in the result set.
The result set is also subject to other query criteria in the The result set is also subject to other query criteria in the
request. request.
7.2.7.2. Get SED Group Offers Response 7.2.7.2. Get SED Group Offers Response
The spppGetResponse element is described later in section titled The spppGetResponse element is described in Section 7.2.8.
"Generic Query Response".
7.2.8. Generic Query Response 7.2.8. Generic Query Response
An SPP Protocol over SOAP query response object is contained within An SPP Protocol over SOAP query response object is contained within
the generic <spppGetResponse> element. the generic <spppGetResponse> element.
<element name="spppGetResponse"> <element name="spppGetResponse">
<complexType> <complexType>
<sequence> <sequence>
<element name="overallResult" <element name="overallResult"
skipping to change at page 34, line 15 skipping to change at page 29, line 38
</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 SPP Protocol over SOAP query response The data elements within the SPP Protocol over SOAP query response
are described as 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 Section 7.3
Response Code section for further details. 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
query criteria. If no objects matched the query criteria then criteria. If no objects matched the query criteria then the
the result object(s) MUST be empty and the overallResult value result object(s) MUST be empty and the overallResult value MUST
MUST indicate success (if no matches are found for the query indicate success (if no matches are found for the query criteria,
criteria, the response is considered a success). the response is considered a success).
7.2.9. Get Server Details Operation Structure 7.2.9. Get Server Details Operation Structure
In order to query certain details of the SPPF server, such as the
In order to query certain details of the SPPF server, like the SPPF SPPF server's status and the major/minor version supported by the
server's status and the major/minor version supported by the server, server, the Server Details operation structure SHOULD be used. This
the Server Details operation structure SHOULD be used. This
structure is contained within the <spppServerStatusRequest> element structure is contained within the <spppServerStatusRequest> element
while a SPPF server status response is wrapped within the whereas a SPPF server status response is wrapped within the
<spppServerStatusResponse> element. This following sub-sections <spppServerStatusResponse> element. The following sub-sections
describe the spppServerStatusRequest and spppServerStatusResponse describe the spppServerStatusRequest and spppServerStatusResponse
elements. elements.
7.2.9.1. Get Server Details Request 7.2.9.1. Get Server Details Request
<element name="spppServerStatusRequest"> <element name="spppServerStatusRequest">
<complexType> <complexType>
<sequence> <sequence>
<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 SPP Protocol over SOAP API that the client minor version of the SPP Protocol over SOAP API that the client is
is attempting to use. This is used in conjunction with the attempting to use. This is used in conjunction with the major
major version identifier in the XML namespace to identify the version identifier in the XML namespace to identify the version of
version of SPP Protocol over SOAP that the client is using. If SPP Protocol over SOAP that the client is using. If the element
the element is not present, the server assumes that the client is not present, the server assumes that the client is using the
is using the latest minor version of SPP Protocol over SOAP latest minor version of SPP Protocol over SOAP supported by the
supported by the SPPF server for the given major version. The SPPF server for the given major version. The versions of SPP
versions of SPP Protocol over SOAP supported by a given SPPF Protocol over SOAP supported by a given SPPF server can be
server can be retrieved by the client using this same retrieved by the client using this same spppServerStatusRequest
spppServerStatusRequest without passing in the minorVer element. without passing in the minorVer element.
7.2.9.2. Get Server Details Response 7.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"/>
<element name="svcMenu" type="sppfb:SvcMenuType"/> <element name="svcMenu" type="sppfb:SvcMenuType"/>
</sequence> </sequence>
</complexType> </complexType>
</element> </element>
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 Section 7.3
Response Code section for further details. 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, the major and
minor version of the SPP Protocol over SOAP supported by the minor versions of the SPP Protocol over SOAP supported by the SPPF
SPPF server (refer framework document for definition of server (refer Section 12 of [I-D.draft-ietf-drinks-spp-framework]
SvcMenuType) . for definition of SvcMenuType).
7.3. Response Codes and Messages 7.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 Section 5.3 of
Message Types" of the framework document. [I-D.draft-ietf-drinks-spp-framework].
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]:
o The first digit of the response code can only be 1 or 2: 1 = a o The first digit of the response code can only be 1 or 2: 1 = a
positive result, 2 = a negative result. positive result, 2 = a negative result.
o The second digit of the response code indicates the category: 0 o The second digit of the response code indicates the category: 0 =
= 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
first two digits. 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 "detailResult" response codes that may only be returned in the "detailResult"
element of the SPPF responses. element of the SPPF responses.
+--------+--------------------------+-------------------------------+ +----------+------------------------------------------+-------------+
| Result | Result Message | Overall or Object Level | | Result | Result Message | Overall or |
| Code | | | | Code | | Object |
+--------+--------------------------+-------------------------------+ | | | Level |
| 1000 | Request Succeeded. | Overall Response Code | +----------+------------------------------------------+-------------+
| | | | | 1000 | Request Succeeded. | Overall |
| 2000 | Request syntax invalid. | Overall Response Code | | | | Response |
| | | | | | | Code |
| 2001 | Request too large. | Overall Response Code | | | | |
| | MaxSupported:[Maximum | | | 2000 | Request syntax invalid. | Overall |
| | requests supported] | | | | | Response |
| | | | | | | Code |
| 2002 | Version not supported. | Overall Response Code | | | | |
| | | | | 2001 | Request too large. MaxSupported:[Maximum | Overall |
| 2100 | Command invalid. | Overall Response Code | | | requests supported] | Response |
| | | | | | | Code |
| 2300 | System temporarily | Overall Response Code | | | | |
| | unavailable. | | | 2002 | Version not supported. | Overall |
| | | | | | | Response |
| 2301 | Unexpected internal | Overall Response Code | | | | Code |
| | system or server error. | | | | | |
| | | | | 2100 | Command invalid. | Overall |
| 2101 | Attribute value invalid. | Object Level Response Code | | | | Response |
| | | | | | | Code |
| | AttrName:[AttributeName] | | | | | |
| | AttrVal:[AttributeValue] | | | 2300 | System temporarily unavailable. | Overall |
| | | | | | | Response |
| 2102 | Object does not exist. | Object Level Response Code | | | | Code |
| | AttrName:[AttributeName] | | | | | |
| | AttrVal:[AttributeValue] | | | 2301 | Unexpected internal system or server | Overall |
| | | | | | error. | Response |
| 2103 | Object status or | Object Level Response Code | | | | Code |
| | ownership does not allow | | | | | |
| | for operation. | | | 2101 | Attribute value invalid. | Object |
| | AttrName:[AttributeName] | | | | AttrName:[AttributeName] | Level |
| | AttrVal:[AttributeValue] | | | | AttrVal:[AttributeValue] | Response |
+--------+--------------------------+-------------------------------+ | | | Code |
| | | |
| 2102 | Object does not exist. | Object |
| | AttrName:[AttributeName] | Level |
| | AttrVal:[AttributeValue] | Response |
| | | Code |
| | | |
| 2103 | Object status or ownership does not | Object |
| | allow for operation. | Level |
| | AttrName:[AttributeName] | Response |
| | AttrVal:[AttributeValue] | Code |
+----------+------------------------------------------+-------------+
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 Response message for response code 2001 is "parameterized" with the
following parameter: "[Maximum requests supported]". When the following parameter: "[Maximum requests supported]". When the
request is too large, this parameter MUST be used to indicate the request is too large, this parameter MUST be used to indicate the
maximum number of requests supported by the server in a single maximum number of requests supported by the server in a single
protocol operation. 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 For example, if an SPPF client sends a request to delete a
Destination Group with a name "TestDG", and it does not already Destination Group with a name "TestDG", and it does not already
exist, then the error message returned should be: "Attribute value exist, then the error message returned should be: "Attribute value
invalid. AttrName:dgName AttrVal:TestDG". 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. Section 5.3 of [I-D.draft-ietf-drinks-spp-framework].
8. Protocol Operations 8. Protocol Operations
Refer the "Framework Operations" section of the framework document Refer to Section 7 of [I-D.draft-ietf-drinks-spp-framework] for a
for a description of all SPPF operations, and any necessary semantics description of all SPPF operations, and any necessary semantics that
that MUST be adhered to in order to conform with the SPPF MUST be adhered to in order to conform with SPPF.
specification.
9. SPP Protocol over SOAP WSDL Definition 9. SPP Protocol over SOAP WSDL Definition
The SPP Protocol over SOAP WSDL and data types are defined below. The SPP Protocol over SOAP WSDL and data types are defined below.
The WSDL design approach is commonly referred to as _Generic WSDL_. The WSDL design approach is commonly referred to as "Generic WSDL".
It is generic in the sense that there is not a specific WSDL It is generic in the sense that there is not a specific WSDL
operation defined for each object type that is supported by the SPPF operation defined for each object type that is supported by the SPPF
protocol. There is a single WSDL structure for each type of SPPF protocol. There is a single WSDL structure for each type of SPPF
operation. Each such WSDL structure contains exactly one input operation. Each such WSDL structure contains exactly one input
structure and one output structure that wraps any data elements that structure and one output structure that wraps any data elements that
are part of the incoming request and the outgoing response are part of the incoming request and the outgoing response
respectively. The spppSOAPBinding in the WSDL defines the binding respectively. The spppSOAPBinding in the WSDL defines the binding
style as _document_ and the encoding as _literal_. It is this style as "document" and the encoding as "literal". It is this
combination of _wrapped_ input and output data structures, _document_ combination of "wrapped" input and output data structures, "document"
binding style, and _literal_ encoding that characterize the Document binding style, and "literal" encoding that characterize the Document
Literal Wrapped style of WSDL specifications. Literal Wrapped style of WSDL specifications.
Note: The following WSDL has been formatted (e.g., tabs, spaces) to Notes: The following WSDL has been formatted (e.g. tabs, spaces) to
meet I-D requirements. meet IETF document requirements. Deployments MUST replace
"REPLACE_WITH_ACTUAL_URL" in the WSDL below with the URI of the SPPF
Server instance.
<?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>
skipping to change at page 40, line 39 skipping to change at page 35, line 17
</sequence> </sequence>
</extension> </extension>
</complexContent> </complexContent>
</complexType> </complexType>
<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"/>
<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>
skipping to change at page 51, line 10 skipping to change at page 44, line 46
</wsdl:service> </wsdl:service>
</wsdl:definitions> </wsdl:definitions>
Figure 2: WSDL Figure 2: WSDL
10. SPP Protocol over SOAP Examples 10. SPP Protocol over SOAP Examples
This section shows XML message exchange between two SIP Service This section shows XML message exchange between two SIP Service
Providers (SSP) and a registry. The messages in this section are Providers (SSP) and a registry. The messages in this section are
valid XML instances that conform to the SPP Protocol over SOAP schema valid XML instances that conform to the SPP Protocol over SOAP schema
version within this document. This section relies on the XML data version within this document. This section also relies on the XML
structures defined in the base SPPF specification data structures defined in the SPPF specification
[I-D.draft-ietf-drinks-spp-framework]. So refer to that document to [I-D.draft-ietf-drinks-spp-framework]. Which should also be
understand XML object types embedded in these example messages. referenced to understand XML object types embedded in these example
messages.
In this sample use case scenario, SSP1 and SSP2 provision resource In this sample use case scenario, SSP1 and SSP2 provision resource
data in the registry and use SPPF constructs to selectively share the data in the registry and use SPPF constructs to selectively share the
SED groups. In the figure below, SSP2 has two ingress SBE instances SED groups. In the figure below, SSP2 has two ingress SBE instances
that are associated with the public identities that SSP2 has the that are associated with the public identities that SSP2 has the
retail relationship with. Also, the two SBE instances for SSP1 are retail relationship with. Also, the two Session Border Element
used to show how to use SPPF to associate route preferences for the instances for SSP1 are used to show how to use SPPF to associate
destination ingress routes and exercise greater control on outbound route preferences for the destination ingress routes and exercise
traffic to the peer's ingress SBEs. greater control on outbound traffic to the peer's ingress SBEs.
---------------+ +------------------ ---------------+ +------------------
| | | |
+------+ +------+ +------+ +------+
| sbe1 | | sbe2 | | sbe1 | | sbe2 |
+------+ +------+ +------+ +------+
SSP1 | | SSP2 SSP1 | | SSP2
+------+ +------+ +------+ +------+
| sbe3 | | sbe4 | | sbe3 | | sbe4 |
+------+ +------+ +------+ +------+
skipping to change at page 68, line 4 skipping to change at page 59, line 41
<sedGrpKey> <sedGrpKey>
<rant>iana-en:222</rant> <rant>iana-en:222</rant>
<name>SED_GRP_SSP2_1</name> <name>SED_GRP_SSP2_1</name>
<type>SedGrp</type> <type>SedGrp</type>
</sedGrpKey> </sedGrpKey>
<offeredTo>iana-en:111</offeredTo> <offeredTo>iana-en:111</offeredTo>
</sedGrpOfferKey> </sedGrpOfferKey>
</urn:spppRejectRequest> </urn:spppRejectRequest>
</soapenv:Body> </soapenv:Body>
</soapenv:Envelope> </soapenv:Envelope>
Registry confirms that the request has been processed successfully. Registry confirms that the request has been processed successfully.
From this point forward, if SSP1 looks up a public identity through From this point forward, if SSP1 looks up a public identity through
the query resolution server, where the public identity is part of the the query resolution server, where the public identity is part of the
destination group by way of "SED_GRP_SSP2_1" session establishment destination group by way of "SED_GRP_SSP2_1" session establishment
data association, SSP2 ingress SBE information will NOT be shared data association, SSP2 ingress SBE information will not be shared
with SSP1 and hence SSP2 ingress SBE will NOT be returned in the with SSP1 and hence SSP2 ingress SBE will not be returned in the
query response. query response.
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<S:Envelope <S:Envelope
xmlns:S="http://schemas.xmlsoap.org/soap/envelope/"> xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
<S:Body> <S:Body>
<ns3:spppRejectResponse <ns3:spppRejectResponse
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>
skipping to change at page 79, line 17 skipping to change at page 68, line 18
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>
<!--1 or more repetitions:--> <!--1 or more repetitions:-->
<objKey xsi:type="urn:PubIdKeyType"> <objKey xsi:type="urn:PubIdKeyType">
<rant>iana-en:222</rant> <rant>iana-en:222</rant>
<dgName>DEST_GRP_SSP2_1</dgName>
<number> <number>
<urn1:value>+12025556666</urn1:value> <urn1:value>+12025556666</urn1:value>
<urn1:type>TN</urn1:type> <urn1:type>TN</urn1:type>
</number> </number>
</objKey> </objKey>
</urn:spppDelRequest> </urn:spppDelRequest>
</soapenv:Body> </soapenv:Body>
</soapenv:Envelope> </soapenv:Envelope>
Registry completes the request successfully and returns a favorable Registry completes the request successfully and returns a favorable
skipping to change at page 84, line 49 skipping to change at page 73, line 45
<offeredTo>iana-en:111</offeredTo> <offeredTo>iana-en:111</offeredTo>
</urn1:sedGrpOfferKey> </urn1:sedGrpOfferKey>
<urn1:status>offered</urn1:status> <urn1:status>offered</urn1:status>
<urn1:offerDateTime> <urn1:offerDateTime>
2006-05-04T18:13:51.0Z 2006-05-04T18:13:51.0Z
</urn1:offerDateTime> </urn1:offerDateTime>
</addObj> </addObj>
<delObj xsi:type="urn:PubIdKeyType"> <delObj xsi:type="urn:PubIdKeyType">
<rant>iana-en:222</rant> <rant>iana-en:222</rant>
<dgxDEST_GRP_SSP2_Previous</dgName>
<number> <number>
<urn1:value>+12025556666</urn1:value> <urn1:value>+12025556666</urn1:value>
<urn1:type>TN</urn1:type> <urn1:type>TN</urn1:type>
</number> </number>
</delObj> </delObj>
<delObj xsi:type="urn:ObjKeyType"> <delObj xsi:type="urn:ObjKeyType">
<rant>iana-en:222</rant> <rant>iana-en:222</rant>
<name>SED_GRP_SSP2_Previous</name> <name>SED_GRP_SSP2_Previous</name>
<type>SedGrp</type> <type>SedGrp</type>
skipping to change at page 86, line 23 skipping to change at page 75, line 16
by the client, which is often accomplished using the TLS certificate by the client, which is often accomplished using the TLS certificate
exchange and validation described in [RFC2818]. exchange and validation described in [RFC2818].
11.1. Vulnerabilities 11.1. Vulnerabilities
Section 5 describes the use of HTTP and TLS as the underlying Section 5 describes the use of HTTP and TLS as the underlying
transport protocols for SPP Protocol over SOAP. These underlying transport protocols for SPP Protocol over SOAP. These underlying
protocols may have various vulnerabilities, and these may be protocols may have various vulnerabilities, and these may be
inherited by SPP Protocol over SOAP. SPP Protocol over SOAP itself inherited by SPP Protocol over SOAP. SPP Protocol over SOAP itself
may have vulnerabilities because an authorization model is not may have vulnerabilities because an authorization model is not
explicitly specified in the current specification. explicitly specified in this document.
During a TLS handshake, non-anonymous TLS servers can optionally During a TLS handshake, TLS servers can optionally request a
request a certificate from a TLS client; that option is not a certificate from a TLS client; that option is not a requirement for
requirement for this protocol. This presents a denial of service this protocol. This presents a denial of service risk in which
risk in which unauthenticated clients can consume server CPU unauthenticated clients can consume server CPU resources by creating
resources by creating TLS sessions. The risk is increased if the TLS sessions. The risk is increased if the server supports client-
server supports client-initiated renegotiation. This risk can be initiated renegotiation. This risk can be mitigated by disabling
mitigated by disabling client-initiated renegotiation on the server client-initiated renegotiation on the server and by ensuring that
and by ensuring that other means (such as firewall access control other means (such as firewall access control lists) are used to
lists) are used to restrict unauthenticated client access to servers. restrict unauthenticated client access to servers.
In conjunction with the above, it is important that SPP Protocol over In conjunction with the above, it is important that SPP Protocol over
SOAP implementations implement an authorization model that considers SOAP implementations implement an authorization model that considers
the source of each query or update request and determines whether it the source of each query or update request and determines whether it
is reasonable to authorize that source to perform that specific query is reasonable to authorize that source to perform that specific query
or update. or update.
12. IANA Considerations 12. 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 requested are: urn:ietf:params:xml:ns:sppf:soap:1 URN assignment requested is: urn:ietf:params:xml:ns:sppf:soap:1
13. Acknowledgements 13. Acknowledgements
This document is a result of various discussions held by the DRINKS This document is a result of various discussions held with the IETF
design team, with contributions from the following individuals, in DRINKS working group, specifically the protocol design team, with
alphabetical order: Alexander Mayrhofer, David Schwartz, Deborah A contributions from the following individuals, in alphabetical order:
Guyton, Jean-Francois Mule Kenneth Cartwright, Lisa Dusseault, Manjul Alexander Mayrhofer, David Schwartz, Deborah A Guyton, Jean-Francois
Maharishi, Mickael Marrache, Otmar Lendl, Peter Saint-Andre, Richard Mule Kenneth Cartwright, Lisa Dusseault, Manjul Maharishi, Mickael
Shockey, Samuel Melloul, Scott Hollenbeck, Sumanth Channabasappa, Marrache, Otmar Lendl, Peter Saint-Andre, Richard Shockey, Samuel
Syed Ali, and Vikas Bhatia . Melloul, Scott Hollenbeck, Sumanth Channabasappa, Syed Ali, and Vikas
Bhatia .
14. References 14. References
14.1. Normative References 14.1. Normative References
[I-D.draft-ietf-drinks-spp-framework] [I-D.draft-ietf-drinks-spp-framework]
Cartwright, K., Bhatia, V., Ali, S., and D. Schwartz, Cartwright, K., Bhatia, V., Ali, S., and D. Schwartz,
"Session Peering Provisioning Framework", "Session Peering Provisioning Framework ", draft-ietf-
draft-ietf-drinks-spp-framework-03 (work in progress), drinks-spp-framework-04 (work in progress), October 2012.
October 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
skipping to change at page 91, line 34 skipping to change at page 77, line 34
CableLabs CableLabs
858 Coal Creek Circle 858 Coal Creek Circle
Louisville, CO 80027 Louisville, CO 80027
USA USA
Email: jfm@cablelabs.com Email: jfm@cablelabs.com
Alexander Mayrhofer Alexander Mayrhofer
enum.at GmbH enum.at GmbH
Karlsplatz 1/9 Karlsplatz 1/9
Wien, A-1010 Wien A-1010
Austria Austria
Email: alexander.mayrhofer@enum.at Email: alexander.mayrhofer@enum.at
 End of changes. 136 change blocks. 
672 lines changed or deleted 670 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/