draft-ietf-drinks-spp-protocol-over-soap-07.txt   draft-ietf-drinks-spp-protocol-over-soap-08.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 25, 2015 J-F. Mule Expires: January 23, 2016 J-F. Mule
CableLabs CableLabs
A. Mayrhofer A. Mayrhofer
enum.at GmbH enum.at GmbH
October 22, 2014 July 22, 2015
Session Peering Provisioning (SPP) Protocol over SOAP Session Peering Provisioning (SPP) Protocol over SOAP
draft-ietf-drinks-spp-protocol-over-soap-07 draft-ietf-drinks-spp-protocol-over-soap-08
Abstract Abstract
The Session Peering Provisioning Framework (SPPF) specifies the data The Session Peering Provisioning Framework (SPPF) specifies the data
model and the overall structure to provision session establishment model and the overall structure to provision session establishment
data into Session Data Registries and SIP Service Provider data data into Session Data Registries and SIP Service Provider data
stores. To utilize this framework one needs a transport protocol. stores. To utilize this framework one needs a substrate protocol.
Given that Simple Object Access Protocol (SOAP) is currently widely Given that Simple Object Access Protocol (SOAP) is currently widely
used for messaging between elements of such provisioning systems, used for messaging between elements of such provisioning systems,
this document specifies the usage of SOAP (via HTTPS) as the this document specifies the usage of SOAP (via HTTPS) as the
transport protocol for SPPF. The benefits include leveraging substrate protocol for SPPF. The benefits include leveraging
prevalent expertise, and a higher probability that existing prevalent expertise, and a higher probability that existing
provisioning systems will be able to easily migrate to using an SPPF provisioning systems will be able to easily migrate to using an SPPF
based protocol. based protocol.
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 25, 2015. This Internet-Draft will expire on January 23, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2015 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
skipping to change at page 2, line 40 skipping to change at page 2, line 40
7.1.1. Generic Object Key . . . . . . . . . . . . . . . . . 8 7.1.1. Generic Object Key . . . . . . . . . . . . . . . . . 8
7.1.2. Public Identity Object Key . . . . . . . . . . . . . 9 7.1.2. Public Identity Object Key . . . . . . . . . . . . . 9
7.1.3. SED Group Offer Key . . . . . . . . . . . . . . . . . 10 7.1.3. SED Group Offer Key . . . . . . . . . . . . . . . . . 10
7.2. Operation Request and Response Structures . . . . . . . . 10 7.2. Operation Request and Response Structures . . . . . . . . 10
7.2.1. Add Operation Structure . . . . . . . . . . . . . . . 11 7.2.1. Add Operation Structure . . . . . . . . . . . . . . . 11
7.2.2. Delete Operation Structure . . . . . . . . . . . . . 14 7.2.2. Delete Operation Structure . . . . . . . . . . . . . 14
7.2.3. Accept Operation Structure . . . . . . . . . . . . . 17 7.2.3. Accept Operation Structure . . . . . . . . . . . . . 17
7.2.4. Reject Operation Structure . . . . . . . . . . . . . 20 7.2.4. Reject Operation Structure . . . . . . . . . . . . . 20
7.2.5. Batch Operation Structure . . . . . . . . . . . . . . 23 7.2.5. Batch Operation Structure . . . . . . . . . . . . . . 23
7.2.6. Get Operation Structure . . . . . . . . . . . . . . . 26 7.2.6. Get Operation Structure . . . . . . . . . . . . . . . 26
7.2.7. Get SED Group Offers Operation Structure . . . . . . 28 7.2.7. Get SED Group Offers Operation Structure . . . . . . 27
7.2.8. Generic Query Response . . . . . . . . . . . . . . . 29 7.2.8. Generic Query Response . . . . . . . . . . . . . . . 29
7.2.9. Get Server Details Operation Structure . . . . . . . 30 7.2.9. Get Server Details Operation Structure . . . . . . . 29
7.3. Response Codes and Messages . . . . . . . . . . . . . . . 31 7.3. Response Codes and Messages . . . . . . . . . . . . . . . 31
8. Protocol Operations . . . . . . . . . . . . . . . . . . . . . 34 7.4. Minor Version Identifier . . . . . . . . . . . . . . . . 33
9. SPP Protocol over SOAP WSDL Definition . . . . . . . . . . . 34 8. Protocol Operations . . . . . . . . . . . . . . . . . . . . . 33
10. SPP Protocol over SOAP Examples . . . . . . . . . . . . . . . 45 9. SPP Protocol over SOAP WSDL Definition . . . . . . . . . . . 33
10.1. Add Destination Group . . . . . . . . . . . . . . . . . 46 10. SPP Protocol over SOAP Examples . . . . . . . . . . . . . . . 44
10.1. Add Destination Group . . . . . . . . . . . . . . . . . 45
10.2. Add SED Records . . . . . . . . . . . . . . . . . . . . 47 10.2. Add SED Records . . . . . . . . . . . . . . . . . . . . 47
10.3. Add SED Records -- URIType . . . . . . . . . . . . . . . 49 10.3. Add SED Records -- URIType . . . . . . . . . . . . . . . 48
10.4. Add SED Group . . . . . . . . . . . . . . . . . . . . . 50 10.4. Add SED Group . . . . . . . . . . . . . . . . . . . . . 49
10.5. Add Public Identity -- Successful COR claim . . . . . . 52 10.5. Add Public Identity -- Successful COR claim . . . . . . 51
10.6. Add LRN . . . . . . . . . . . . . . . . . . . . . . . . 54 10.6. Add LRN . . . . . . . . . . . . . . . . . . . . . . . . 53
10.7. Add TN Range . . . . . . . . . . . . . . . . . . . . . . 55 10.7. Add TN Range . . . . . . . . . . . . . . . . . . . . . . 54
10.8. Add TN Prefix . . . . . . . . . . . . . . . . . . . . . 56 10.8. Add TN Prefix . . . . . . . . . . . . . . . . . . . . . 55
10.9. Enable Peering -- SED Group Offer . . . . . . . . . . . 58 10.9. Enable Peering -- SED Group Offer . . . . . . . . . . . 57
10.10. Enable Peering -- SED Group Offer Accept . . . . . . . . 59 10.10. Enable Peering -- SED Group Offer Accept . . . . . . . . 58
10.11. Add Egress Route . . . . . . . . . . . . . . . . . . . . 60 10.11. Add Egress Route . . . . . . . . . . . . . . . . . . . . 59
10.12. Remove Peering -- SED Group Offer Reject . . . . . . . . 62 10.12. Remove Peering -- SED Group Offer Reject . . . . . . . . 61
10.13. Get Destination Group . . . . . . . . . . . . . . . . . 63 10.13. Get Destination Group . . . . . . . . . . . . . . . . . 62
10.14. Get Public Identity . . . . . . . . . . . . . . . . . . 65 10.14. Get Public Identity . . . . . . . . . . . . . . . . . . 64
10.15. Get SED Group Request . . . . . . . . . . . . . . . . . 66 10.15. Get SED Group Request . . . . . . . . . . . . . . . . . 65
10.16. Get SED Group Offers Request . . . . . . . . . . . . . . 68 10.16. Get SED Group Offers Request . . . . . . . . . . . . . . 67
10.17. Get Egress Route . . . . . . . . . . . . . . . . . . . . 70 10.17. Get Egress Route . . . . . . . . . . . . . . . . . . . . 69
10.18. Delete Destination Group . . . . . . . . . . . . . . . . 72 10.18. Delete Destination Group . . . . . . . . . . . . . . . . 71
10.19. Delete Public Identity . . . . . . . . . . . . . . . . . 73 10.19. Delete Public Identity . . . . . . . . . . . . . . . . . 72
10.20. Delete SED Group Request . . . . . . . . . . . . . . . . 74 10.20. Delete SED Group Request . . . . . . . . . . . . . . . . 73
10.21. Delete SED Group Offers Request . . . . . . . . . . . . 75 10.21. Delete SED Group Offers Request . . . . . . . . . . . . 74
10.22. Delete Egress Route . . . . . . . . . . . . . . . . . . 77 10.22. Delete Egress Route . . . . . . . . . . . . . . . . . . 76
10.23. Batch Request . . . . . . . . . . . . . . . . . . . . . 78 10.23. Batch Request . . . . . . . . . . . . . . . . . . . . . 77
11. Security Considerations . . . . . . . . . . . . . . . . . . . 80 11. Security Considerations . . . . . . . . . . . . . . . . . . . 79
11.1. Vulnerabilities . . . . . . . . . . . . . . . . . . . . 81 11.1. Vulnerabilities . . . . . . . . . . . . . . . . . . . . 80
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 81 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 80
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 81 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 80
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 82 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 81
14.1. Normative References . . . . . . . . . . . . . . . . . . 82 14.1. Normative References . . . . . . . . . . . . . . . . . . 81
14.2. Informative References . . . . . . . . . . . . . . . . . 82 14.2. Informative References . . . . . . . . . . . . . . . . . 81
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 82
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 in 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,
SOAP and HTTP(S). using SOAP and HTTP(S) as substrates.
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) "substrate" 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
skipping to change at page 6, line 28 skipping to change at page 6, line 28
the chosen SOAP implementation. the chosen SOAP implementation.
This document RECOMMENDS SOAP 1.2 [SOAPREF] or higher, and WSDL 1.1 This document RECOMMENDS SOAP 1.2 [SOAPREF] or higher, and WSDL 1.1
[WSDLREF] or higher. [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 scope of this document. For more details, please refer to
Section 4 ("Transport Protocol Requirements") of Section 4 ("Substrate Protocol Requirements") of
[I-D.draft-ietf-drinks-spp-framework]. [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 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 substrate protocol that provides a set of
basic requirements defined in Section 4 of basic requirements defined in Section 4 of
[I-D.draft-ietf-drinks-spp-framework]. [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. SOAP are examples of messaging envelope technologies.
3. Layers 3,4,5,6: The operation and message layers provide 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 substrate-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
While SOAP is not tied to HTTP(S), 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 substrate protocol 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. consuming SSL handshake has occurred.
Implementations compliant with this document MUST use HTTP 1.1 Implementations compliant with this document MUST use HTTP 1.1
[RFC2616] or higher. Also, implementations SHOULD use persistent [RFC2616] or higher. Also, implementations SHOULD use persistent
connections. connections.
skipping to change at page 7, line 32 skipping to change at page 7, line 32
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]. [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 protocols
protocols to provide a mechanism to transmit language tags together to provide a mechanism to transmit language tags together with human-
with human-readable messages. When conforming SPP Protocol SOAP readable messages. When conforming SPP Protocol SOAP servers use
servers use such tagging, the XML "lang" attribute such tagging, the XML "lang" attribute ([W3C.REC-xml-20081126],
([W3C.REC-xml-20081126], Section 2.12) MUST be used. Clients MAY use Section 2.12) MUST be used. Clients MAY use the HTTP "Accept-
the HTTP "Accept-Language" header field (see Section 14.4 of Language" header field (see Section 14.4 of [RFC2616]) in order to
[RFC2616]) in order to indicate their language preference. 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 substrate-independent.
Refer the "Protocol Operations" (Section 8) 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 substrate 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 Section 5.2.1 "Generic attributes in the generic object key (Refer Section 5.2.1 "Generic
Object Key Type" of [I-D.draft-ietf-drinks-spp-framework] for Object Key Type" of [I-D.draft-ietf-drinks-spp-framework] for
details). The concrete XML representation of ObjKeyType is as below: details). The concrete XML representation of ObjKeyType is as below:
skipping to change at page 12, line 5 skipping to change at page 12, line 5
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 server track, log or correlate requests and their responses. SPPF server
MUST echo back this value to the client in the corresponding MUST echo back this value to the client in the corresponding
response to the incoming request. SPPF server will not check this response to the incoming request. SPPF server 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, as defined in
minor version of the SPPF API that the client is attempting to Section 7.4.
use. This is used in conjunction with the major version
identifier in the XML namespace to identify the version of SPPF
that the client is using. If the element is not present, the
server assumes that the client is using the latest minor version
supported by the SPPF server for the given major version. The
versions supported by a given SPPF server can be retrieved by the
client using the "Get Server Details" operation described in
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 [I-D.draft-ietf-drinks-spp-framework]). Each element contains in [I-D.draft-ietf-drinks-spp-framework]). Each element contains
all the attributes of an SPPF object that that the client is all the attributes of an SPPF object that that the client is
requesting the SPPF server to add. Refer to section 3.1 of requesting the SPPF server to add. Refer to section 3.1 of
[I-D.draft-ietf-drinks-spp-framework] for the XML structure of all [I-D.draft-ietf-drinks-spp-framework] for the XML structure of all
concrete types, for various SPPF objects, that extend from concrete types, for various SPPF objects, that extend from
abstract BasicObjType and hence are eligible to be passed into abstract BasicObjType and hence are eligible to be passed into
this element. The elements are processed by the SPPF server in this element. The elements are processed by the SPPF server in
the order in which they are included in the request. With respect the order in which they are included in the request. With respect
skipping to change at page 13, line 11 skipping to change at page 13, line 11
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>
<sequence> <sequence>
<element name="clientTransId" type="sppfb:TransIdType" <element name="clientTransId" type="sppfb:TransIdType"
minOccurs="0"/> minOccurs="0"/>
<element name="serverTransId" type="sppfb:TransIdType"/> <element name="serverTransId" type="sppfb:TransIdType"/>
<element name="overallResult" type="sppfb:ResultCodeType"/> <element name="overallResult" type="sppfs:ResultCodeType"/>
<element name="detailResult" type="sppfs:ObjResultCodeType" <element name="detailResult" type="sppfs:ObjResultCodeType"
minOccurs="0" maxOccurs="unbounded"/> minOccurs="0" maxOccurs="unbounded"/>
</sequence> </sequence>
</complexType> </complexType>
</element> </element>
<complexType name="ResultCodeType"> <complexType name="ResultCodeType">
<sequence> <sequence>
<element name="code" type="int"/> <element name="code" type="int"/>
<element name="msg" type="string"/> <element name="msg" type="string"/>
skipping to change at page 15, line 16 skipping to change at page 15, line 16
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 server track, log or correlate requests and their responses. SPPF server
MUST echo back this value to the client in the corresponding MUST echo back this value to the client in the corresponding
response to the incoming request. SPPF server will not check this response to the incoming request. SPPF server 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, as defined in
minor version of the SPPF API that the client is attempting to Section 7.4.
use. This is used in conjunction with the major version
identifier in the XML namespace to identify the version of SPPF
that the client is using. If the element is not present, the
server assumes that the client is using the latest minor version
supported by the SPPF server for the given major version. The
versions supported by a given SPPF server can be retrieved by the
client using the Get Server Details Operation described in
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 [I-D.draft-ietf-drinks-spp-framework]). Each element defined in [I-D.draft-ietf-drinks-spp-framework]). Each element
contains attributes that uniquely identify the object that the contains attributes that uniquely identify the object that the
client is requesting the server to delete. Refer to Section 7.1 client is requesting the server to delete. Refer to Section 7.1
for a description of all concrete object key types, for various for a description of all concrete object key types, for various
SPPF objects, which are eligible to be passed into this element. SPPF objects, which are eligible to be passed into this element.
The elements are processed by the SPPF server in the order in The elements are processed by the SPPF server in the order in
which they are included in the request. With respect to handling which they are included in the request. With respect to handling
of error conditions, conforming SPPP SOAP servers MUST stop of error conditions, conforming SPPP SOAP servers MUST stop
skipping to change at page 16, line 11 skipping to change at page 16, line 11
the generic <sppDeleteResponse> element. This response structure is the generic <sppDeleteResponse> element. This response structure is
used for a delete request on all types of SPPF objects that are used for a delete request on all types of SPPF objects that are
provisioned by the SPPF client. provisioned by the SPPF client.
<element name="spppDelResponse"> <element name="spppDelResponse">
<complexType> <complexType>
<sequence> <sequence>
<element name="clientTransId" type="sppfb:TransIdType" <element name="clientTransId" type="sppfb:TransIdType"
minOccurs="0"/> minOccurs="0"/>
<element name="serverTransId" type="sppfb:TransIdType"/> <element name="serverTransId" type="sppfb:TransIdType"/>
<element name="overallResult" type="sppfb:ResultCodeType"/> <element name="overallResult" type="sppfs:ResultCodeType"/>
<element name="detailResult" type="sppfs:ObjKeyResultCodeType" <element name="detailResult" type="sppfs:ObjKeyResultCodeType"
minOccurs="0" maxOccurs="unbounded"/> minOccurs="0" maxOccurs="unbounded"/>
</sequence> </sequence>
</complexType> </complexType>
</element> </element>
<complexType name="ResultCodeType"> <complexType name="ResultCodeType">
<sequence> <sequence>
<element name="code" type="int"/> <element name="code" type="int"/>
<element name="msg" type="string"/> <element name="msg" type="string"/>
skipping to change at page 18, line 30 skipping to change at page 18, line 30
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 server track, log or correlate requests and their responses. SPPF server
MUST echo back this value to the client in the corresponding MUST echo back this value to the client in the corresponding
response to the incoming request. SPPF server will not check this response to the incoming request. SPPF server 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, as defined in
minor version of the SPPF API that the client is attempting to Section 7.4.
use. This is used in conjunction with the major version
identifier in the XML namespace to identify the version of SPPF
that the client is using. If the element is not present, the
server assumes that the client is using the latest minor version
supported by the SPPF server for the given major version. The
versions supported by a given SPPF server can be retrieved by the
client using the Get Server Details Operation described in
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 accept. The elements are processed by requesting the server to accept. 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, conforming request. With respect to handling of error conditions, conforming
SPPP SOAP servers MUST stop processing SedGrpOfferKeyType elements SPPP SOAP servers MUST stop processing SedGrpOfferKeyType elements
in the request at the first error, and roll back any in the request at the first error, and roll back any
SedGrpOfferKeyType elements that had already been processed for SedGrpOfferKeyType elements that had already been processed for
skipping to change at page 19, line 17 skipping to change at page 19, line 11
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>
<element name="clientTransId" type="sppfb:TransIdType" <element name="clientTransId" type="sppfb:TransIdType"
minOccurs="0"/> minOccurs="0"/>
<element name="serverTransId" type="sppfb:TransIdType"/> <element name="serverTransId" type="sppfb:TransIdType"/>
<element name="overallResult" type="sppfb:ResultCodeType"/> <element name="overallResult" type="sppfs:ResultCodeType"/>
<element name="detailResult" <element name="detailResult"
type="sppfs:SedGrpOfferKeyResultCodeType" type="sppfs:SedGrpOfferKeyResultCodeType"
minOccurs="0" maxOccurs="unbounded"/> minOccurs="0" maxOccurs="unbounded"/>
</sequence> </sequence>
</complexType> </complexType>
</element> </element>
<complexType name="ResultCodeType"> <complexType name="ResultCodeType">
<sequence> <sequence>
<element name="code" type="int"/> <element name="code" type="int"/>
skipping to change at page 21, line 29 skipping to change at page 21, line 29
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 server track, log or correlate requests and their responses. SPPF server
MUST echo back this value to the client in the corresponding MUST echo back this value to the client in the corresponding
response to the incoming request. SPPF server will not check this response to the incoming request. SPPF server 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, as defined in
minor version of the SPPF API that the client is attempting to Section 7.4.
use. This is used in conjunction with the major version
identifier in the XML namespace to identify the version of SPPF
that the client is using. If the element is not present, the
server assumes that the client is using the latest minor version
supported by the SPPF server for the given major version. The
versions supported by a given SPPF server can be retrieved by the
client using the Get Server Details Operation described in
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, conforming request. With respect to handling of error conditions, conforming
SPPF servers MUST stop processing SedGrpOfferKeyType elements in SPPF servers MUST stop processing SedGrpOfferKeyType elements in
the request at the first error, and roll back any the request at the first error, and roll back any
SedGrpOfferKeyType elements that had already been processed for SedGrpOfferKeyType elements that had already been processed for
skipping to change at page 22, line 17 skipping to change at page 22, line 11
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>
<element name="clientTransId" type="sppfb:TransIdType" <element name="clientTransId" type="sppfb:TransIdType"
minOccurs="0"/> minOccurs="0"/>
<element name="serverTransId" type="sppfb:TransIdType"/> <element name="serverTransId" type="sppfb:TransIdType"/>
<element name="overallResult" type="sppfb:ResultCodeType"/> <element name="overallResult" type="sppfs:ResultCodeType"/>
<element name="detailResult" <element name="detailResult"
type="sppfs:SedGrpOfferKeyResultCodeType" type="sppfs:SedGrpOfferKeyResultCodeType"
minOccurs="0" maxOccurs="unbounded"/> minOccurs="0" maxOccurs="unbounded"/>
</sequence> </sequence>
</complexType> </complexType>
</element> </element>
<complexType name="ResultCodeType"> <complexType name="ResultCodeType">
<sequence> <sequence>
<element name="code" type="int"/> <element name="code" type="int"/>
skipping to change at page 24, line 35 skipping to change at page 24, line 35
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 Server track, log or correlate requests and their responses. SPPF Server
MUST echo back this value to the Client in the corresponding MUST echo back this value to the Client in the corresponding
response to the incoming request. SPPF Server will not check this response to the incoming request. SPPF Server 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, as defined in
minor version of the SPPF API that the client is attempting to Section 7.4.
use. This is used in conjunction with the major version
identifier in the XML namespace to identify the version of SPPF
that the client is using. If the element is not present, the
server assumes that the client is using the latest minor version
supported by the SPPF server for the given major version. The
versions supported by a given SPPF server can be retrieved by the
client using the Get Server Details Operation described in
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 SedGrpOfferKeyType o acceptSedGrpOffer: One or more elements of type SedGrpOfferKeyType
where each element identifies a SED Group Offer that needs to be where each element identifies a SED Group Offer that needs to be
skipping to change at page 25, line 31 skipping to change at page 25, line 23
within the generic <sppBatchResponse> element. This response within the generic <sppBatchResponse> element. This response
structure is used for an Batch request that contains many different structure is used for an Batch request that contains many different
types of SPPF operations. types of SPPF operations.
<element name="spppBatchResponse"> <element name="spppBatchResponse">
<complexType> <complexType>
<sequence> <sequence>
<element name="clientTransId" type="sppfb:TransIdType" <element name="clientTransId" type="sppfb:TransIdType"
minOccurs="0"/> minOccurs="0"/>
<element name="serverTransId" type="sppfb:TransIdType"/> <element name="serverTransId" type="sppfb:TransIdType"/>
<element name="overallResult" type="sppfb:ResultCodeType"/> <element name="overallResult" type="sppfs:ResultCodeType"/>
<choice minOccurs="0" maxOccurs="unbounded"> <choice minOccurs="0" maxOccurs="unbounded">
<element name="addResult" <element name="addResult"
type="sppfs:ObjResultCodeType"/> type="sppfs:ObjResultCodeType"/>
<element name="delResult" <element name="delResult"
type="sppfs:ObjKeyResultCodeType"/> type="sppfs:ObjKeyResultCodeType"/>
<element name="acceptResult" <element name="acceptResult"
type="sppfs:SedGrpOfferKeyResultCodeType"/> type="sppfs:SedGrpOfferKeyResultCodeType"/>
<element name="rejectResult" <element name="rejectResult"
type="sppfs:SedGrpOfferKeyResultCodeType"/> type="sppfs:SedGrpOfferKeyResultCodeType"/>
</choice> </choice>
skipping to change at page 27, line 25 skipping to change at page 27, line 19
<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, as defined in
minor version of the SPPF API that the client is attempting to Section 7.4.
use. This is used in conjunction with the major version
identifier in the XML namespace to identify the version of SPPF
that the client is using. If the element is not present, the
server assumes that the client is using the latest minor version
supported by the SPPF server for the given major version. The
versions supported by a given SPPF server can be retrieved by the
client using the Get Server Details Operation described in
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 [I-D.draft-ietf-drinks-spp-framework]). Each element defined in [I-D.draft-ietf-drinks-spp-framework]). Each element
contains attributes that uniquely identify the object that the contains attributes that uniquely identify the object that the
client is requesting the server to query. Refer to Section 7.1 of client is requesting the server to query. Refer to Section 7.1 of
this document for a description of all concrete object key types, this document for a description of all concrete object key types,
for various SPPF objects, which are eligible to be passed into for various SPPF objects, which are eligible to be passed into
this element. this element.
7.2.6.2. Get Response 7.2.6.2. Get Response
skipping to change at page 28, line 45 skipping to change at page 28, line 27
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, as defined in
minor version of the SPPF API that the client is attempting to Section 7.4.
use. This is used in conjunction with the major version
identifier in the XML namespace to identify the version of SPPF
that the client is using. If the element is not present, the
server assumes that the client is using the latest minor version
supported by the SPPF server for the given major version. The
versions supported by a given SPPF server can be retrieved by the
client using the Get Server Details Operation described in
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 in offered to the organization IDs in this list should be included in
the result set. The result set is also subject to other query the result set. The result set is also subject to other 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 in offered by the organization IDs in this list should be included in
the result set. The result set is also subject to other query the result set. The result set is also subject to other query
criteria in the request. criteria in the request.
skipping to change at page 30, line 47 skipping to change at page 30, line 21
<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, as defined in
minor version of the SPP Protocol over SOAP API that the client is Section 7.4.
attempting to use. This is used in conjunction with the major
version identifier in the XML namespace to identify the version of
SPP Protocol over SOAP that the client is using. If the element
is not present, the server assumes that the client is using the
latest minor version of SPP Protocol over SOAP supported by the
SPPF server for the given major version. The versions of SPP
Protocol over SOAP supported by a given SPPF server can be
retrieved by the client using this same spppServerStatusRequest
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"/>
skipping to change at page 34, line 13 skipping to change at page 33, line 13
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
Section 5.3 of [I-D.draft-ietf-drinks-spp-framework]. Section 5.3 of [I-D.draft-ietf-drinks-spp-framework].
7.4. Minor Version Identifier
The minor version identifier element is defined as follows:
o minorVer: Zero or one minor version identifier, indicating the
minor version of the SPP Protocol over SOAP API that the client is
attempting to use. This is used in conjunction with the major
version identifier in the XML namespace to identify the version of
SPP Protocol over SOAP that the client is using. If the element
is not present, the server assumes that the client is using the
latest minor version of SPP Protocol over SOAP supported by the
SPPF server for the given major version. The versions of SPP
Protocol over SOAP supported by a given SPPF server can be
retrieved by the client using this same spppServerStatusRequest
without passing in the minorVer element.
8. Protocol Operations 8. Protocol Operations
Refer to Section 7 of [I-D.draft-ietf-drinks-spp-framework] for a Refer to Section 7 of [I-D.draft-ietf-drinks-spp-framework] for a
description of all SPPF operations, and any necessary semantics that description of all SPPF operations, and any necessary semantics that
MUST be adhered to in order to conform with SPPF. MUST be adhered to in order to conform with SPPF.
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".
skipping to change at page 81, line 10 skipping to change at page 80, line 10
limited to users and systems that are authorized to query and update limited to users and systems that are authorized to query and update
this data. Because this data is sent in both directions, it may not this data. Because this data is sent in both directions, it may not
be sufficient for just the client or user to be authenticated with be sufficient for just the client or user to be authenticated with
the server. The identity of the server should also be authenticated the server. The identity of the server should also be authenticated
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 substrate 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 this document. explicitly specified in this document.
During a TLS handshake, TLS servers can optionally request a During a TLS handshake, TLS servers can optionally request a
certificate from a TLS client; that option is not a requirement for certificate from a TLS client; that option is not a requirement for
this protocol. This presents a denial of service risk in which this protocol. This presents a denial of service risk in which
unauthenticated clients can consume server CPU resources by creating unauthenticated clients can consume server CPU resources by creating
TLS sessions. The risk is increased if the server supports client- TLS sessions. The risk is increased if the server supports client-
skipping to change at page 82, line 14 skipping to change at page 81, line 14
Melloul, Scott Hollenbeck, Sumanth Channabasappa, Syed Ali, and Vikas Melloul, Scott Hollenbeck, Sumanth Channabasappa, Syed Ali, and Vikas
Bhatia . 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", draft-ietf- "Session Peering Provisioning Framework", draft-ietf-
drinks-spp-framework-08 (work in progress), October 2014. drinks-spp-framework-08 (work in progress), July 2015.
[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
Authentication: Basic and Digest Access Authentication", Authentication: Basic and Digest Access Authentication",
RFC 2617, June 1999. RFC 2617, DOI 10.17487/RFC2617, June 1999,
<http://www.rfc-editor.org/info/rfc2617>.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004. DOI 10.17487/RFC3688, January 2004,
<http://www.rfc-editor.org/info/rfc3688>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008,
<http://www.rfc-editor.org/info/rfc5246>.
[SOAPREF] Gudgin, M., Hadley, M., Moreau, J., and H. Nielsen, "SOAP [SOAPREF] Gudgin, M., Hadley, M., Moreau, J., and H. Nielsen, "SOAP
Version 1.2 Part 1: Messaging Framework", W3C Version 1.2 Part 1: Messaging Framework", W3C
Recommendation REC-SOAP12-part1-20030624, June 2002. Recommendation REC-SOAP12-part1-20030624, June 2002.
14.2. Informative References 14.2. Informative References
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818,
DOI 10.17487/RFC2818, May 2000,
<http://www.rfc-editor.org/info/rfc2818>.
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
October 2008. DOI 10.17487/RFC5321, October 2008,
<http://www.rfc-editor.org/info/rfc5321>.
[W3C.REC-xml-20081126] [W3C.REC-xml-20081126]
Sperberg-McQueen, C., Yergeau, F., Bray, T., Maler, E., Sperberg-McQueen, C., Yergeau, F., Bray, T., Maler, E.,
and J. Paoli, "Extensible Markup Language (XML) 1.0 (Fifth and J. Paoli, "Extensible Markup Language (XML) 1.0 (Fifth
Edition)", World Wide Web Consortium Recommendation REC- Edition)", World Wide Web Consortium Recommendation REC-
xml-20081126, November 2008, xml-20081126, November 2008,
<http://www.w3.org/TR/2008/REC-xml-20081126>. <http://www.w3.org/TR/2008/REC-xml-20081126>.
[WSDLREF] Christensen, E., Curbera, F., Meredith, G., and S. [WSDLREF] Christensen, E., Curbera, F., Meredith, G., and S.
Weerawarana, "Web Services Description Language (WSDL) Weerawarana, "Web Services Description Language (WSDL)
 End of changes. 41 change blocks. 
151 lines changed or deleted 110 lines changed or added

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