GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc7878

Internet Engineering Task Force (IETF) K. Cartwright Request for Comments: 7878 V. Bhatia Category: Standards Track TNS ISSN: 2070-1721 J-F. Mule

                                                            Apple Inc.
                                                          A. Mayrhofer
                                                           nic.at GmbH
                                                           August 2016
       Session Peering Provisioning (SPP) Protocol over SOAP

Abstract

 The Session Peering Provisioning Framework (SPPF) specifies the data
 model and the overall structure to provision Session Establishment
 Data (SED) into Session Data Registries and SIP Service Provider data
 stores.  To utilize this framework, one needs a substrate protocol.
 Given that the Simple Object Access Protocol (SOAP) is currently
 widely used for messaging between elements of such provisioning
 systems, this document specifies the usage of SOAP (via HTTPS) as the
 substrate protocol for SPPF.  The benefits include leveraging
 prevalent expertise and a higher probability that existing
 provisioning systems will be able to easily migrate to using an SPPF-
 based protocol.

Status of This Memo

 This is an Internet Standards Track document.
 This document is a product of the Internet Engineering Task Force
 (IETF).  It represents the consensus of the IETF community.  It has
 received public review and has been approved for publication by the
 Internet Engineering Steering Group (IESG).  Further information on
 Internet Standards is available in Section 2 of RFC 7841.
 Information about the current status of this document, any errata,
 and how to provide feedback on it may be obtained at
 http://www.rfc-editor.org/info/rfc7878.

Cartwright, et al. Standards Track [Page 1] RFC 7878 SPP Protocol over SOAP August 2016

Copyright Notice

 Copyright (c) 2016 IETF Trust and the persons identified as the
 document authors.  All rights reserved.
 This document is subject to BCP 78 and the IETF Trust's Legal
 Provisions Relating to IETF Documents
 (http://trustee.ietf.org/license-info) in effect on the date of
 publication of this document.  Please review these documents
 carefully, as they describe your rights and restrictions with respect
 to this document.  Code Components extracted from this document must
 include Simplified BSD License text as described in Section 4.e of
 the Trust Legal Provisions and are provided without warranty as
 described in the Simplified BSD License.

Table of Contents

 1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
 2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
 3.  SOAP Features and Protocol Layering . . . . . . . . . . . . .   4
 4.  HTTP(S) Features and SPPP over SOAP . . . . . . . . . . . . .   7
 5.  Authentication, Integrity, and Confidentiality  . . . . . . .   7
 6.  Language Identification . . . . . . . . . . . . . . . . . . .   7
 7.  SPPP SOAP Data Structures . . . . . . . . . . . . . . . . . .   7
   7.1.  Concrete Object Key Types . . . . . . . . . . . . . . . .   8
     7.1.1.  Generic Object Key  . . . . . . . . . . . . . . . . .   8
     7.1.2.  Public Identifier Object Key  . . . . . . . . . . . .   9
     7.1.3.  SED Group Offer Key . . . . . . . . . . . . . . . . .  10
   7.2.  Operation Request and Response Structures . . . . . . . .  10
     7.2.1.  Add Operation Structure . . . . . . . . . . . . . . .  10
     7.2.2.  Delete Operation Structure  . . . . . . . . . . . . .  13
     7.2.3.  Accept Operation Structure  . . . . . . . . . . . . .  16
     7.2.4.  Reject Operation Structure  . . . . . . . . . . . . .  19
     7.2.5.  Batch Operation Structure . . . . . . . . . . . . . .  22
     7.2.6.  Get Operation Structure . . . . . . . . . . . . . . .  25
     7.2.7.  Get SED Group Offers Operation Structure  . . . . . .  26
     7.2.8.  Generic Query Response  . . . . . . . . . . . . . . .  28
     7.2.9.  Get Server Details Operation Structure  . . . . . . .  29
   7.3.  Response Codes and Messages . . . . . . . . . . . . . . .  30
   7.4.  Minor Version Identifier  . . . . . . . . . . . . . . . .  32
 8.  Protocol Operations . . . . . . . . . . . . . . . . . . . . .  32
 9.  SPPP over SOAP WSDL Definition  . . . . . . . . . . . . . . .  32
 10. SPPP over SOAP Examples . . . . . . . . . . . . . . . . . . .  44
   10.1.  Add Destination Group  . . . . . . . . . . . . . . . . .  44
   10.2.  Add SED Records  . . . . . . . . . . . . . . . . . . . .  46
   10.3.  Add SED Records -- URIType . . . . . . . . . . . . . . .  47
   10.4.  Add SED Group  . . . . . . . . . . . . . . . . . . . . .  49
   10.5.  Add Public Identifier -- Successful COR Claim  . . . . .  50

Cartwright, et al. Standards Track [Page 2] RFC 7878 SPP Protocol over SOAP August 2016

   10.6.  Add LRN  . . . . . . . . . . . . . . . . . . . . . . . .  52
   10.7.  Add TN Range . . . . . . . . . . . . . . . . . . . . . .  53
   10.8.  Add TN Prefix  . . . . . . . . . . . . . . . . . . . . .  54
   10.9.  Enable Peering -- SED Group Offer  . . . . . . . . . . .  56
   10.10. Enable Peering -- SED Group Offer Accept . . . . . . . .  58
   10.11. Add Egress Route . . . . . . . . . . . . . . . . . . . .  60
   10.12. Remove Peering -- SED Group Offer Reject . . . . . . . .  61
   10.13. Get Destination Group  . . . . . . . . . . . . . . . . .  62
   10.14. Get Public Identifier  . . . . . . . . . . . . . . . . .  64
   10.15. Get SED Group Request  . . . . . . . . . . . . . . . . .  66
   10.16. Get SED Group Offers Request . . . . . . . . . . . . . .  68
   10.17. Get Egress Route . . . . . . . . . . . . . . . . . . . .  70
   10.18. Delete Destination Group . . . . . . . . . . . . . . . .  72
   10.19. Delete Public Identifier . . . . . . . . . . . . . . . .  73
   10.20. Delete SED Group Request . . . . . . . . . . . . . . . .  74
   10.21. Delete SED Group Offers Request  . . . . . . . . . . . .  75
   10.22. Delete Egress Route  . . . . . . . . . . . . . . . . . .  76
   10.23. Batch Request  . . . . . . . . . . . . . . . . . . . . .  77
 11. Security Considerations . . . . . . . . . . . . . . . . . . .  80
   11.1.  Vulnerabilities  . . . . . . . . . . . . . . . . . . . .  80
 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  81
 13. References  . . . . . . . . . . . . . . . . . . . . . . . . .  81
   13.1.  Normative References . . . . . . . . . . . . . . . . . .  81
   13.2.  Informative References . . . . . . . . . . . . . . . . .  82
 Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  82
 Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  83

1. Introduction

 SPPF, defined in [RFC7877], is best supported by a transport and
 messaging infrastructure that is connection oriented, is request-
 response oriented, is easily secured, supports propagation through
 firewalls in a standard fashion, and 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 organizations' operational support
 systems that facilitate transactional provisioning of user addresses
 and their associated SED.  The server side of SPPF is likely to
 reside in a separate organization's network, resulting in the SPPF
 provisioning transactions traversing the Internet as they are
 propagated from the SPPF client to the SPPF server.  Given the
 current state of industry practice and technologies, SOAP and HTTP(S)
 are well suited for this type of environment.  This document
 describes the specification for transporting SPPF XML structures,
 using SOAP and HTTP(S) as substrates.
 The specification in this document for transporting SPPF XML
 structures over SOAP and HTTP(S) is primarily comprised of five
 subjects: (1) a description of any applicable SOAP features, (2) any

Cartwright, et al. Standards Track [Page 3] RFC 7878 SPP Protocol over SOAP August 2016

 applicable HTTP features, (3) security considerations, (4) (perhaps
 most importantly) the Web Services Description Language (WSDL)
 definition for the SPP Protocol over SOAP, and (5) XML Schema
 Definition (XSD) types that are "substrate" specific.

2. Terminology

 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
 document are to be interpreted as described in [RFC2119].

3. SOAP Features and Protocol Layering

 The list of SOAP features that are explicitly used and required for
 SPPP over SOAP are limited.  Most SOAP features are not necessary for
 SPPF.  SPPP over SOAP primarily uses SOAP simply as a standard
 message-envelope technology.  The SOAP message envelope is comprised
 of the SOAP header and body.  As described in the SOAP specification
 [SOAPREF], the SOAP header can contain optional, application-
 specific, information about the message.  The SOAP body contains the
 SPPF message itself, whose structure is defined by the combination of
 one of the WSDL operations defined in this document and the SPPF XML
 data structures defined in this document and the SPPF document.  SPPF
 does not rely on any data elements in the SOAP header.  All relevant
 data elements are defined in the SPPF XML Schema described in
 [RFC7877] and the SPPF WSDL types specification described in
 Section 9 of this document.
 WSDL is a widely standardized and adopted technology for defining the
 top-level structures of the messages that are transported within the
 body of a SOAP message.  The WSDL definition for the SPPF SOAP
 messages is defined later in this document, which imports by
 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" [RFC3688].
 There are multiple structural styles that WSDL allows.  The best
 practice for this type of application is what is sometimes referred
 to as the "document/literal wrapped style".  This style is generally
 regarded as an optimal approach that enhances maintainability,
 comprehension, portability, and, to a certain extent, performance.
 It is characterized by setting the soapAction binding style as
 "document", the soapAction encoding style as "literal", and then
 defining the SOAP messages to simply contain a single data element
 that "wraps" a data structure containing all the required input or
 output data elements.  The figure below illustrates this high-level
 technical structure as conceptual layers 3 through 6.

Cartwright, et al. Standards Track [Page 4] RFC 7878 SPP Protocol over SOAP August 2016

                               +-------------+
                           (1) |  Transport  |Example:
                               |  Protocol   |  TCP, TLS, BEEP, etc.
                               +-------------+
                                      |
                                      V
                               +-------------+
                           (2) |   Message   |Example:
                               |   Envelope  | HTTP, SOAP, None, etc.
                               +-------------+
                                      |
                                      V
                              +--------------+
                         +----|    SOAP      |---+
                         |(3) |  Operation   |   |
                Contains |    +--------------+   | Contains
                         |        Example:       |
                         V      submitAddRqst    V
                +--------------+           +-------------+
                | SOAP Request |           |SOAP Response|
     Example:   |   Message    |  (4)      |   Message   | Example:
     spppAdd    |  (Operation  |           |  (Operation | spppAdd
     RequestMsg |   Input)     |           |   Output)   | ResponseMsg
                +--------------+           +-------------+
                         |                       |
                Contains |                       | Contains
                         |                       |
                         V                       V
                +--------------+          +---------------+
     Example:   |   Wrapped    |  (5)     |    Wrapped    | Example:
     spppAdd    |Request Object|          |Response Object| spppAdd
     Request    +--------------+          +---------------+ Response
                         |                       |
                Contains |                       | Contains
                         |                       |
                         V                       V
                +--------------+          +---------------+
                |    SPPF      |          |     SPPF      |
                |  XML Types   |  (6)     |   XML Types   |
                +--------------+          +---------------+
 Legend:
 BEEP = Blocks Extensible Exchange Protocol
 TLS = Transport Layer Security
 Figure 1: Layering and Technical Structure of SPPP over SOAP Messages

Cartwright, et al. Standards Track [Page 5] RFC 7878 SPP Protocol over SOAP August 2016

 The operations supported by SPPP over SOAP are normatively defined
 later in this document.  Each SOAP operation defines a request/input
 message and a response/output message.  Each such request and
 response message then contains a single object that wraps the SPPF
 XML data types that comprise the inputs and the outputs,
 respectively, of the SOAP operation.
 SOAP faults are not used by the SPPP over SOAP.  All success and
 error responses are specified in Section 7.3 of this document.
 However, if a SOAP fault were to occur, perhaps due to failures in
 the SOAP message handling layer of a SOAP library, the client
 application should capture and handle the fault.  Specifics on how to
 handle such SOAP faults, if they should occur, will be specific to
 the chosen SOAP implementation.
 Implementations MUST use SOAP 1.2 [SOAPREF] or higher and MUST
 support SOAP 1.2.  Implementations SHOULD use WSDL 1.1 [WSDLREF] and
 MUST NOT use earlier versions.  Use of WSDL versions greater than 1.1
 may introduce interoperability problems with implementations that use
 1.1.
 SPPF is a request/reply framework that allows a client application to
 submit provisioning data and query requests to a server.  The SPPF
 data structures are designed to be protocol agnostic.  Concerns
 regarding encryption, non-repudiation, and authentication are beyond
 the scope of this document.  For more details, please refer to
 Section 4 ("Transport Substrate Protocol Requirements") of [RFC7877].
 As illustrated in the previous diagram, SPPF can be viewed as a set
 of layers that collectively define the structure of an SPPF request
 and response.  Layers 1 and 2 represent the transport, envelope, and
 authentication technologies.  This document defines layers 3, 4, 5,
 and 6 for SPPP over SOAP.
 1.  Layer 1: The transport protocol layer represents the
     communication mechanism between the client and server.  SPPF can
     be layered over any substrate protocol that provides a set of
     basic requirements defined in Section 4 of [RFC7877].
 2.  Layer 2: The message-envelope layer is optional but can provide
     features that are above the transport technology layer but below
     the application messaging layer.  Technologies such as HTTP and
     SOAP are examples of message-envelope technologies.
 3.  Layers 3, 4, 5, and 6: The operation and message layers provide
     an envelope-independent and substrate-independent wrapper for the
     SPPF data model objects that are being acted on (created,
     modified, and queried).

Cartwright, et al. Standards Track [Page 6] RFC 7878 SPP Protocol over SOAP August 2016

4. HTTP(S) Features and SPPP over SOAP

 While SOAP is not tied to HTTP(S), for reasons described in the
 Introduction, HTTP(S) is a good choice as the substrate protocol for
 the SPP Protocol SOAP messages.  HTTP 1.1 includes the "persistent
 connection" feature, which allows multiple HTTP request/response
 pairs to be transported across a single HTTP connection.  This is an
 important performance optimization feature, particularly when the
 connection is an HTTPS connection where the relatively time-consuming
 TLS handshake has occurred.
 Implementations compliant with this document MUST use HTTP 1.1
 [RFC7230] or higher.  Also, implementations SHOULD use persistent
 connections.

5. Authentication, Integrity, and Confidentiality

 To accomplish authentication, conforming SPPP over SOAP clients and
 servers MUST use HTTP Digest Authentication as defined in [RFC7235].
 To achieve integrity and privacy, conforming SPPP over SOAP clients
 and servers MUST support TLS as defined in [RFC5246] as the secure
 transport mechanism.  Use of TLS MUST follow the recommendations
 contained in [RFC7525]

6. Language Identification

 Section 9 of [RFC7877] requires protocols to provide a mechanism to
 transmit language tags together with human-readable messages.  When
 conforming SPPP SOAP servers use such tagging, the XML "lang"
 attribute ([W3C.REC-xml-20081126], Section 2.12) MUST be used.
 Clients MAY use the HTTP "Accept-Language" header field (see
 Section 5.3.5 of [RFC7231]) in order to indicate their language
 preference.

7. SPPP SOAP Data Structures

 SPPP over SOAP uses a set of XML-based data structures for all the
 supported operations and any parameters to which those operations are
 applied.  As also mentioned earlier in this document, these XML
 structures are envelope independent and substrate independent.  Refer
 to "Protocol Operations" (Section 8) of this document for a
 description of all the operations that MUST be supported.
 The following sections describe the definitions of all the XML data
 structures.

Cartwright, et al. Standards Track [Page 7] RFC 7878 SPP Protocol over SOAP August 2016

7.1. Concrete Object Key Types

 Certain operations in SPPF require an object key that uniquely
 identifies the object(s) on which a given operation needs to be
 performed.  SPPF defines the XML structure of any such object key in
 an abstract manner and delegates the concrete representation to any
 conforming substrate protocol.  The following subsections define the
 various types of concrete object key types used in various operations
 in SPPP over SOAP.

7.1.1. Generic Object Key

 Most objects in SPPP over SOAP are uniquely identified by the
 attributes in the generic object key (Refer to "Generic Object Key
 Type", Section 5.2.1 of [RFC7877], for details).  The concrete XML
 representation of ObjKeyType is as below:
    <complexType name="ObjKeyType">
     <complexContent>
      <extension base="sppfb:ObjKeyType">
       <sequence>
        <element name="rant" type="sppfb:OrgIdType"/>
        <element name="name" type="sppfb:ObjNameType"/>
        <element name="type" type="sppfs:ObjKeyTypeEnum"/>
       </sequence>
      </extension>
     </complexContent>
    </complexType>
 The ObjKeyType has the data elements as described below:
 o  rant: The identifier of the Registrant organization that owns 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
    object.  For example, both a Destination Group and a SED Group can
    have the same name "TestObj" and be associated with the same
    Registrant ID.  Hence, to uniquely identify the object that
    represents a Destination Group with the name "TestObj", the type
    "DestGrp" must be specified when using this concrete ObjKeyType
    structure to identify the Destination Group "TestObj".

Cartwright, et al. Standards Track [Page 8] RFC 7878 SPP Protocol over SOAP August 2016

 The object types in SPPP over SOAP MUST adhere to the above
 definition of generic object key and are defined as an enumeration in
 the XML data structure as follows:
  <simpleType name="ObjKeyTypeEnum">
    <restriction base="token">
      <enumeration value="SedGrp"/>
      <enumeration value="DestGrp"/>
      <enumeration value="SedRec"/>
      <enumeration value="EgrRte"/>
    </restriction>
  </simpleType>

7.1.2. Public Identifier Object Key

 Public Identifier type objects can further be of various sub-types
 like a Telephone Number (TN), Routing Number (RN), TN Prefix, URI, or
 TN Range and cannot be cleanly identified with the attributes in the
 generic ObjKeyType.  The definition of PubIdKeyType is as below:
    <complexType name="PubIdKeyType">
     <complexContent>
      <extension base="sppfb:PubIdKeyType">
       <sequence>
        <element name="rant" type="sppfb:OrgIdType"/>
        <choice>
         <element name="number"
         type="sppfb:NumberType"/>
         <element name="range"
          type="sppfb:NumberRangeType"/>
         <element name="uri"
          type="anyURI"/>
        </choice>
       </sequence>
      </extension>
     </complexContent>
    </complexType>
 The PubIdKeyType has data elements, as described below:
 o  rant: The identifier of the Registrant organization that owns the
    object.
 o  number: An element of type NumberType (refer to Section 12 of
    [RFC7877]) that contains the value and type of a number.
 o  range: An element of type NumberRangeType (refer to Section 12 of
    [RFC7877]) that contains a range of numbers.

Cartwright, et al. Standards Track [Page 9] RFC 7878 SPP Protocol over SOAP August 2016

 o  uri: A value that represents a Public Identifier.
 Any instance of PubIdKeyType MUST contain exactly one element from
 the following set of elements: "number", "range", "uri".

7.1.3. SED Group Offer Key

 In addition to the attributes in the generic ObjKeyType, a SED Group
 Offer object is uniquely identified by the organization ID of the
 organization to whom a SED Group has been offered.  The definition of
 SedGrpOfferKeyType is as below:
    <complexType name="SedGrpOfferKeyType">
     <complexContent>
      <extension base="sppfb:SedGrpOfferKeyType">
       <sequence>
        <element name="sedGrpKey" type="sppfs:ObjKeyType"/>
        <element name="offeredTo" type="sppfb:OrgIdType"/>
       </sequence>
      </extension>
     </complexContent>
    </complexType>
 The SedGrpOfferKeyType has the data elements as described below:
 o  sedGrpKey: Identifies the SED Group that was offered.
 o  offeredTo: The organization ID of the organization that was
    offered the SED Group object identified by the sedGrpKey.

7.2. Operation Request and Response Structures

 An SPPF client interacts with an SPPF server by sending one or more
 requests to the server and by receiving corresponding responses from
 the server.  The basic set of operations that an SPPF client can
 submit to an SPPF server and the semantics of those operations are
 defined in "Framework Operations", Section 7 of [RFC7877].  The
 following subsections describe the XML data structures that are used
 for each of those types of operations for an SPPP over SOAP
 implementation.

7.2.1. Add Operation Structure

 In order to add (or modify) an object in the Registry, an authorized
 entity can send the spppAddRequest to the Registry.

Cartwright, et al. Standards Track [Page 10] RFC 7878 SPP Protocol over SOAP August 2016

 An SPPP over SOAP Add request is wrapped within the <spppAddRequest>
 element while an SPPP over SOAP Add response is wrapped within an
 <spppAddResponse> element.  The following sub-sections describe the
 <spppAddRequest> and <spppAddResponse> elements.  Refer to Section 10
 for an example of an Add operation on each type of SPPF object.

7.2.1.1. Add Request

 An SPPP over SOAP Add request definition is contained within the
 generic <spppAddRequest> element.
    <element name="spppAddRequest">
     <complexType>
      <sequence>
       <element name="clientTransId"
        type="sppfb:TransIdType" minOccurs="0"/>
       <element name="minorVer"
        type="sppfb:MinorVerType" minOccurs="0"/>
       <element name="obj" type="sppfb:BasicObjType"
       maxOccurs="unbounded"/>
      </sequence>
     </complexType>
    </element>
 The data elements within the <spppAddRequest> element are described
 as follows:
 o  clientTransId: Zero or one client-generated transaction ID that,
    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.  The SPPF
    server MUST echo back this value to the client in the
    corresponding response to the incoming request.  The SPPF server
    will not check this value for uniqueness.
 o  minorVer: Zero or one minor version identifier, as defined in
    Section 7.4.
 o  obj: One or more elements of abstract type BasicObjType (defined
    in [RFC7877]).  Each element contains all the attributes of an
    SPPF object that the client is requesting the SPPF server to add.
    Refer to Section 3.1 of [RFC7877] for the XML structure of all
    concrete types, for various SPPF objects, that extend from
    abstract BasicObjType and hence are eligible to be passed into
    this element.  The elements are processed by the SPPF server in
    the order in which they are included in the request.  With respect
    to the handling of error conditions, conforming SPPP SOAP servers
    MUST stop processing BasicObjType elements in the request at the

Cartwright, et al. Standards Track [Page 11] RFC 7878 SPP Protocol over SOAP August 2016

    first error and roll back any BasicObjType elements that had
    already been processed for that add request ("stop and roll
    back").

7.2.1.2. Add Response

 An SPPP over SOAP add response object is contained within the generic
 <spppAddResponse> element.  This response structure is used for all
 types of SPPF objects that are provisioned by the SPPF client.
   <element name="spppAddResponse">
     <complexType>
       <sequence>
         <element name="clientTransId" type="sppfb:TransIdType"
          minOccurs="0"/>
         <element name="serverTransId" type="sppfb:TransIdType"/>
         <element name="overallResult" type="sppfs:ResultCodeType"/>
         <element name="detailResult" type="sppfs:ObjResultCodeType"
         minOccurs="0" maxOccurs="unbounded"/>
       </sequence>
     </complexType>
   </element>
   <complexType name="ResultCodeType">
     <sequence>
        <element name="code" type="int"/>
        <element name="msg" type="string"/>
     </sequence>
   </complexType>
    <complexType name="ObjResultCodeType">
     <complexContent>
      <extension base="sppfs:ResultCodeType">
       <sequence>
        <element name="obj" type="sppfb:BasicObjType"/>
       </sequence>
      </extension>
     </complexContent>
    </complexType>
 An <spppAddResponse> contains the elements necessary for the SPPF
 client to precisely determine the overall result of the request, and
 if an error occurs, it provides information about the specific
 object(s) that caused the error.

Cartwright, et al. Standards Track [Page 12] RFC 7878 SPP Protocol over SOAP August 2016

 The data elements within the SPPP over SOAP Add response are
 described as follows:
 o  clientTransId: Zero or one client transaction ID.  This value is
    simply an echo of the client transaction ID that the SPPF client
    passed into the SPPF update request.  When included in the
    request, the SPPF server MUST return it in the corresponding
    response message.
 o  serverTransId: Exactly one server transaction ID that identifies
    this request for tracking purposes.  This value MUST be unique for
    a given SPPF server.
 o  overallResult: Exactly one response code and message pair that
    explicitly identifies the result of the request.  See Section 7.3
    for further details.
 o  detailResult: An optional response code, response message, and
    BasicObjType (as defined in [RFC7877]) triplet.  This element will
    be present only if an object-level error has occurred.  It
    indicates the error condition and the exact request object that
    contributed to the error.  The response code will reflect the
    exact error.  See Section 7.3 for further details.

7.2.2. Delete Operation Structure

 In order to remove an object from the Registry, an authorized entity
 can send the spppDelRequest into the Registry.  An SPPP over SOAP
 Delete request is wrapped within the <spppDelRequest> element while
 an SPPP over SOAP Delete response is wrapped within the generic
 <spppDelResponse> element.  The following subsections describe the
 <spppDelRequest> and <spppDelResponse> elements.  Refer to Section 10
 for an example of the Delete operation on each type of SPPF object.

Cartwright, et al. Standards Track [Page 13] RFC 7878 SPP Protocol over SOAP August 2016

7.2.2.1. Delete Request

 An SPPP over SOAP Delete request definition is contained within the
 generic <spppDelRequest> element.
    <element name="spppDelRequest">
     <complexType>
      <sequence>
       <element name="clientTransId"
       type="sppfb:TransIdType" minOccurs="0"/>
       <element name="minorVer"
       type="sppfb:MinorVerType" minOccurs="0"/>
      <element name="objKey" type="sppfb:ObjKeyType"
       maxOccurs="unbounded"/>
      </sequence>
     </complexType>
    </element>
 The data elements within the <spppDelRequest> element are described
 as follows:
 o  clientTransId: Zero or one client-generated transaction ID that,
    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.  The 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, as defined in
    Section 7.4.
 o  objKey: One or more elements of abstract type ObjKeyType (as
    defined in [RFC7877]).  Each element contains attributes that
    uniquely identify the object that the client is requesting the
    server to delete.  Refer to Section 7.1 for a description of all
    concrete object key types, for various SPPF objects, which are
    eligible to be passed into this element.  The elements are
    processed by the SPPF server in the order in which they are
    included in the request.  With respect to the handling of error
    conditions, conforming SPPP SOAP servers MUST stop processing
    ObjKeyType elements in the request at the first error and roll
    back any ObjKeyType elements that had already been processed for
    that Delete request ("stop and roll back").

Cartwright, et al. Standards Track [Page 14] RFC 7878 SPP Protocol over SOAP August 2016

7.2.2.2. Delete Response

 An SPPP over SOAP delete response object is contained within the
 generic <sppDeleteResponse> element.  This response structure is used
 for a Delete request on all types of SPPF objects that are
 provisioned by the SPPF client.
 <element name="spppDelResponse">
  <complexType>
   <sequence>
    <element name="clientTransId" type="sppfb:TransIdType"
             minOccurs="0"/>
    <element name="serverTransId" type="sppfb:TransIdType"/>
    <element name="overallResult" type="sppfs:ResultCodeType"/>
    <element name="detailResult" type="sppfs:ObjKeyResultCodeType"
             minOccurs="0" maxOccurs="unbounded"/>
   </sequence>
  </complexType>
 </element>
 <complexType name="ResultCodeType">
  <sequence>
   <element name="code" type="int"/>
   <element name="msg" type="string"/>
  </sequence>
 </complexType>
 <complexType name="ObjKeyResultCodeType">
  <complexContent>
   <extension base="sppfs:ResultCodeType">
    <sequence>
     <element name="objKey" type="sppfb:ObjKeyType"/>
    </sequence>
   </extension>
  </complexContent>
 </complexType>
 An <spppDelResponse> contains the elements necessary for the SPPF
 client to precisely determine the overall result of the request, and
 if an error occurs, it provides information about the specific object
 key(s) that caused the error.

Cartwright, et al. Standards Track [Page 15] RFC 7878 SPP Protocol over SOAP August 2016

 The data elements within the SPPP over SOAP Delete response are
 described as follows:
 o  clientTransId: Zero or one client transaction ID.  This value is
    simply an echo of the client transaction ID that the SPPF client
    passed into the SPPF update request.  When included in the
    request, the SPPF server MUST return it in the corresponding
    response message.
 o  serverTransId: Exactly one server transaction ID that identifies
    this request for tracking purposes.  This value MUST be unique for
    a given SPPF server.
 o  overallResult: Exactly one response code and message pair that
    explicitly identifies the result of the request.  See Section 7.3
    for further details.
 o  detailResult: An optional response code, response message, and
    ObjKeyType (as defined in [RFC7877]) triplet.  This element will
    be present only if a specific object key level error has occurred.
    It indicates the error condition and the exact request object key
    that contributed to the error.  The response code will reflect the
    exact error.  See Section 7.3 for further details.

7.2.3. Accept Operation Structure

 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
 (refer to Section 3.1 of [RFC7877] for a description of the SED Group
 Offer object).  The Accept operation is used to accept such SED Group
 Offers by, or on behalf of, the Registrant.  The request structure
 for an SPPP over SOAP Accept operation is wrapped within the
 <spppAcceptRequest> element while an SPPP over SOAP Accept response
 is wrapped within the generic <spppAcceptResponse> element.  The
 following subsections describe the <spppAcceptRequest> and
 <spppAcceptResponse> elements.  Refer to Section 10 for an example of
 the Accept operation on a SED Group Offer.

Cartwright, et al. Standards Track [Page 16] RFC 7878 SPP Protocol over SOAP August 2016

7.2.3.1. Accept Request Structure

 An SPPP over SOAP Accept request definition is contained within the
 generic <sppAcceptRequest> element.
    <element name="spppAcceptRequest">
     <complexType>
      <sequence>
       <element name="clientTransId"
       type="sppfb:TransIdType" minOccurs="0"/>
       <element name="minorVer"
       type="sppfb:MinorVerType" minOccurs="0"/>
       <element name="sedGrpOfferKey"
       type="sppfs:SedGrpOfferKeyType"
       maxOccurs="unbounded"/>
      </sequence>
     </complexType>
    </element>
 The data elements within the <spppAcceptRequest> element are
 described as follows:
 o  clientTransId: Zero or one client-generated transaction ID that,
    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.  The SPPF
    server MUST echo back this value to the client in the
    corresponding response to the incoming request.  The SPPF server
    will not check this value for uniqueness.
 o  minorVer: Zero or one minor version identifier, as defined in
    Section 7.4.
 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 the 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 roll back").

Cartwright, et al. Standards Track [Page 17] RFC 7878 SPP Protocol over SOAP August 2016

7.2.3.2. Accept Response

 An SPPP over SOAP accept response structure is contained within the
 generic <sppAcceptResponse> element.  This response structure is used
 for an Accept request on a SED Group Offer.
 <element name="spppAcceptResponse">
  <complexType>
   <sequence>
    <element name="clientTransId" type="sppfb:TransIdType"
             minOccurs="0"/>
    <element name="serverTransId" type="sppfb:TransIdType"/>
    <element name="overallResult" type="sppfs:ResultCodeType"/>
    <element name="detailResult"
             type="sppfs:SedGrpOfferKeyResultCodeType"
             minOccurs="0" maxOccurs="unbounded"/>
   </sequence>
  </complexType>
 </element>
 <complexType name="ResultCodeType">
  <sequence>
   <element name="code" type="int"/>
   <element name="msg" type="string"/>
  </sequence>
 </complexType>
 <complexType name="SedGrpOfferKeyResultCodeType">
  <complexContent>
   <extension base="sppfs:ResultCodeType">
    <sequence>
     <element name="sedGrpOfferKey" type="sppfs:SedGrpOfferKeyType"/>
    </sequence>
   </extension>
  </complexContent>
 </complexType>
 An <spppAcceptResponse> contains the elements necessary for the SPPF
 client to precisely determine the overall result of the request, and
 if an error occurs, it provides information about the specific SED
 Group Offer key(s) that caused the error.

Cartwright, et al. Standards Track [Page 18] RFC 7878 SPP Protocol over SOAP August 2016

 The data elements within the SPPP over SOAP Accept response are
 described as follows:
 o  clientTransId: Zero or one client transaction ID.  This value is
    simply an echo of the client transaction ID that the SPPF client
    passed into the SPPF update request.  When included in the
    request, the SPPF server MUST return it in the corresponding
    response message.
 o  serverTransId: Exactly one server transaction ID that identifies
    this request for tracking purposes.  This value MUST be unique for
    a given SPPF server.
 o  overallResult: Exactly one response code and message pair that
    explicitly identifies the result of the request.  See Section 7.3
    for further details.
 o  detailResult: An optional response code, response message, and
    SedGrpOfferKeyType (as defined in this document) triplet.  This
    element will be present only if any specific SED Group Offer key
    level error has occurred.  It indicates the error condition and
    the exact request SED Group Offer key that contributed to the
    error.  The response code will reflect the exact error.  See
    Section 7.3 for further details.

7.2.4. Reject Operation Structure

 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
 (refer to "Framework Data Model Objects", Section 6 of [RFC7877] for
 a description of the SED Group Offer object).  The Reject operation
 is used to reject such SED Group Offers by, or on behalf of, the
 Registrant.  The request structure for an SPPP over SOAP Reject
 operation is wrapped within the <spppRejectRequest> element while an
 SPPP over SOAP Reject response is wrapped within the generic
 <spppRejecResponse> element.  The following subsections describe the
 <spppRejectRequest> and <spppRejecResponse> elements.  Refer to
 Section 10 for an example of the Reject operation on a SED Group
 Offer.

Cartwright, et al. Standards Track [Page 19] RFC 7878 SPP Protocol over SOAP August 2016

7.2.4.1. Reject Request

 An SPPP over SOAP Reject request definition is contained within the
 generic <spppRejectRequest> element.
    <element name="spppRejectRequest">
     <complexType>
      <sequence>
       <element name="clientTransId"
       type="sppfb:TransIdType" minOccurs="0"/>
       <element name="minorVer"
       type="sppfb:MinorVerType" minOccurs="0"/>
       <element name="sedGrpOfferKey"
       type="sppfs:SedGrpOfferKeyType"
       maxOccurs="unbounded"/>
      </sequence>
     </complexType>
    </element>
 The data elements within the <spppRejectRequest> element are
 described as follows:
 o  clientTransId: Zero or one client-generated transaction ID that,
    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.  The SPPF
    server MUST echo back this value to the client in the
    corresponding response to the incoming request.  The SPPF server
    will not check this value for uniqueness.
 o  minorVer: Zero or one minor version identifier, as defined in
    Section 7.4.
 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 reject.  The elements are processed by
    the SPPF server in the order in which they are included in the
    request.  With respect to the handling of error conditions,
    conforming SPPF 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 Reject request ("stop and roll back").

Cartwright, et al. Standards Track [Page 20] RFC 7878 SPP Protocol over SOAP August 2016

7.2.4.2. Reject Response

 An SPPP over SOAP reject response structure is contained within the
 generic <sppRejectResponse> element.  This response structure is used
 for a Reject request on a SED Group Offer.
 <element name="spppRejectResponse">
  <complexType>
   <sequence>
    <element name="clientTransId" type="sppfb:TransIdType"
             minOccurs="0"/>
    <element name="serverTransId" type="sppfb:TransIdType"/>
    <element name="overallResult" type="sppfs:ResultCodeType"/>
    <element name="detailResult"
             type="sppfs:SedGrpOfferKeyResultCodeType"
             minOccurs="0" maxOccurs="unbounded"/>
   </sequence>
  </complexType>
 </element>
 <complexType name="ResultCodeType">
  <sequence>
   <element name="code" type="int"/>
   <element name="msg" type="string"/>
  </sequence>
 </complexType>
 <complexType name="SedGrpOfferKeyResultCodeType">
  <complexContent>
   <extension base="sppfs:ResultCodeType">
    <sequence>
     <element name="sedGrpOfferKey" type="sppfs:SedGrpOfferKeyType"/>
    </sequence>
   </extension>
  </complexContent>
 </complexType>
 An <spppRejectResponse> contains the elements necessary for the SPPF
 client to precisely determine the overall result of the request, and
 if an error occurs, it provides information about the specific SED
 Group Offer key(s) that caused the error.

Cartwright, et al. Standards Track [Page 21] RFC 7878 SPP Protocol over SOAP August 2016

 The data elements within the SPPP over SOAP Reject response are
 described as follows:
 o  clientTransId: Zero or one client transaction ID.  This value is
    simply an echo of the client transaction ID that the SPPF client
    passed into the SPPF update request.  When included in the
    request, the SPPF server MUST return it in the corresponding
    response message.
 o  serverTransId: Exactly one server transaction ID that identifies
    this request for tracking purposes.  This value MUST be unique for
    a given SPPF server.
 o  overallResult: Exactly one response code and message pair that
    explicitly identifies the result of the request.  See Section 7.3
    for further details.
 o  detailResult: An optional response code, response message, and
    SedGrpOfferKeyType (as defined in this document) triplet.  This
    element will be present only if any specific SED Group Offer key
    level error has occurred.  It indicates the error condition and
    the exact request SED Group Offer key that contributed to the
    error.  The response code will reflect the exact error.  See
    Section 7.3 for further details.

7.2.5. Batch Operation Structure

 An SPPP over SOAP Batch request XML structure allows the SPPF client
 to send any of the Add, Del, Accept, or Reject operations together in
 one single request.  This gives an SPPF client the flexibility to use
 one single request structure to perform more than operations (verbs).
 The batch request structure is wrapped within the <spppBatchRequest>
 element while an SPPF Batch response is wrapped within the
 <spppBatchResponse> element.  The following subsections describe the
 <spppBatchRequest> and <spppBatchResponse> elements.  Refer to
 Section 10 for an example of a Batch operation.

Cartwright, et al. Standards Track [Page 22] RFC 7878 SPP Protocol over SOAP August 2016

7.2.5.1. Batch Request Structure

 An SPPP over SOAP Batch request definition is contained within the
 generic <spppBatchRequest> element.
     <element name="spppBatchRequest">
     <complexType>
      <sequence>
       <element name="clientTransId"
       type="sppfb:TransIdType" minOccurs="0"/>
       <element name="minorVer"
       type="sppfb:MinorVerType" minOccurs="0"/>
        <choice minOccurs="1" maxOccurs="unbounded">
         <element name="addObj" type="sppfb:BasicObjType"/>
         <element name="delObj" type="sppfb:ObjKeyType"/>
         <element name="acceptSedGrpOffer"
         type="sppfs:SedGrpOfferKeyType"/>
         <element name="rejectSedGrpOffer"
         type="sppfs:SedGrpOfferKeyType"/>
        </choice>
      </sequence>
     </complexType>
    </element>
 The data elements within the <sppBatchRequest> element are described
 as follows:
 o  clientTransId: Zero or one client-generated transaction ID that,
    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.  The SPPF
    server MUST echo back this value to the client in the
    corresponding response to the incoming request.  The SPPF server
    will not check this value for uniqueness.
 o  minorVer: Zero or one minor version identifier, as defined in
    Section 7.4.
 o  addObj: One or more elements of abstract type BasicObjType where
    each element identifies an object that needs to be added.
 o  delObj: One or more elements of abstract type ObjKeyType where
    each element identifies a key for the object that needs to be
    deleted .
 o  acceptSedGrpOffer: One or more elements of type SedGrpOfferKeyType
    where each element identifies a SED Group Offer that needs to be
    accepted.

Cartwright, et al. Standards Track [Page 23] RFC 7878 SPP Protocol over SOAP August 2016

 o  rejectSedGrpOffer: One or more elements of type SedGrpOfferKeyType
    where each element identifies a SED Group Offer that needs to be
    rejected.
 With respect to the handling of error conditions, conforming SPPP
 SOAP servers MUST stop processing elements in the request at the
 first error and roll back any elements that had already been
 processed for that Batch request ("stop and roll back").

7.2.5.2. Batch Response

 An SPPP over SOAP batch response structure is contained within the
 generic <sppBatchResponse> element.  This response structure is used
 for a Batch request that contains many different types of SPPF
 operations.
   <element name="spppBatchResponse">
     <complexType>
       <sequence>
         <element name="clientTransId" type="sppfb:TransIdType"
          minOccurs="0"/>
         <element name="serverTransId" type="sppfb:TransIdType"/>
         <element name="overallResult" type="sppfs:ResultCodeType"/>
         <choice minOccurs="0" maxOccurs="unbounded">
            <element name="addResult"
            type="sppfs:ObjResultCodeType"/>
            <element name="delResult"
            type="sppfs:ObjKeyResultCodeType"/>
            <element name="acceptResult"
            type="sppfs:SedGrpOfferKeyResultCodeType"/>
            <element name="rejectResult"
            type="sppfs:SedGrpOfferKeyResultCodeType"/>
          </choice>
       </sequence>
     </complexType>
   </element>
 An <spppBatchResponse> contains the elements necessary for an SPPF
 client to precisely determine the overall result of various
 operations in the request, and if an error occurs, it provides
 information about the specific objects or keys in the request that
 caused the error.

Cartwright, et al. Standards Track [Page 24] RFC 7878 SPP Protocol over SOAP August 2016

 The data elements within the SPPP over SOAP Batch response are
 described as follows:
 o  clientTransId: Zero or one client transaction ID.  This value is
    simply an echo of the client transaction ID that the SPPF client
    passed into the SPPF update request.  When included in the
    request, the SPPF server MUST return it in the corresponding
    response message.
 o  serverTransId: Exactly one server transaction ID that identifies
    this request for tracking purposes.  This value MUST be unique for
    a given SPPF server.
 o  overallResult: Exactly one response code and message pair that
    explicitly identifies the result of the request.  See Section 7.3
    for further details.
 o  addResult: One or more elements of type ObjResultCodeType where
    each element identifies the result code, result message, and the
    specific object to which the result relates.
 o  delResult: One or more elements of type ObjKeyResultCodeType where
    each element identifies the result code, result message, and the
    specific object key to which the result relates.
 o  acceptResult: One or more elements of type
    SedGrpOfferKeyResultCodeType where each element identifies the
    result code, result message, and the specific SED Group Offer key
    to which the result relates.
 o  rejectResult: One or more elements of type
    SedGrpOfferKeyResultCodeType where each element identifies the
    result code, result message, and the specific SED Group Offer key
    to which the result relates.

7.2.6. Get Operation Structure

 In order to query the details of an object from the Registry, an
 authorized entity can send the spppGetRequest to the Registry with a
 GetRqstType XML data structure containing one or more object keys
 that uniquely identify the object whose details are being queried.
 The following subsections describe the <spppGetRequest> and
 <spppGetResponse> elements.  Refer to Section 10 for an example of
 the SPPP over SOAP Get operation on each type of SPPF object.

Cartwright, et al. Standards Track [Page 25] RFC 7878 SPP Protocol over SOAP August 2016

7.2.6.1. Get Request

 The request structure for an SPPP over SOAP Get operation is
 contained within the generic <spppGetRequest> element:
    <element name="spppGetRequest">
     <complexType>
      <sequence>
       <element name="minorVer"
       type="sppfb:MinorVerType" minOccurs="0"/>
       <element name="objKey"
       type="sppfb:ObjKeyType"
       maxOccurs="unbounded"/>
      </sequence>
     </complexType>
    </element>
 The data elements within the <spppGetRequest> element are described
 as follows:
 o  minorVer: Zero or one minor version identifier, as defined in
    Section 7.4.
 o  objKey: One or more elements of abstract type ObjKeyType (as
    defined in [RFC7877]).  Each element contains attributes that
    uniquely identify the object that the client is requesting the
    server to query.  Refer to Section 7.1 of this document for a
    description of all concrete object key types, for various SPPF
    objects, which are eligible to be passed into this element.

7.2.6.2. Get Response

 The SPPP over SOAP Get response is wrapped within the generic
 <spppGetResponse> element, as described in Section 7.2.8.

7.2.7. Get SED Group Offers Operation Structure

 In addition to the ability to query the details of one or more SED
 Group Offers using a SED Group Offer key in the spppGetRequest, this
 operation also provides an additional, more flexible, structure to
 query for SED Group Offer objects.  This additional structure is
 contained within the <getSedGrpOffersRequest> element while the
 response is wrapped within the generic <spppGetResponse> element.
 The following subsections describe the <getSedGrpOffersRequest> and
 <spppGetResponse> elements.

Cartwright, et al. Standards Track [Page 26] RFC 7878 SPP Protocol over SOAP August 2016

7.2.7.1. Get SED Group Offers Request

 Using the details passed into this structure, the server will attempt
 to find SED Group Offer objects that satisfy all the criteria passed
 into the request.  If no criteria are passed in, then the SPPF server
 will return the list of SED Group Offer objects that belong to the
 Registrant.  If there are no matching SED Group Offers found, then an
 empty result set will be returned.
     <element name="getSedGrpOffersRequest">
     <complexType>
      <sequence>
       <element name="minorVer" type="sppfb:MinorVerType"
       minOccurs="0"/>
      <element name="offeredBy" type="sppfb:OrgIdType"
      minOccurs="0" maxOccurs="unbounded"/>
      <element name="offeredTo" type="sppfb:OrgIdType"
      minOccurs="0" maxOccurs="unbounded"/>
      <element name="status" type="sppfb:SedGrpOfferStatusType"
       minOccurs="0"/>
      <element name="sedGrpOfferKey" type="sppfs:SedGrpOfferKeyType"
      minOccurs="0" maxOccurs="unbounded"/>
      </sequence>
     </complexType>
    </element>
 The data elements within the <getSedGrpOffersRequest> element are
 described as follows:
 o  minorVer: Zero or one minor version identifier, as defined in
    Section 7.4.
 o  offeredBy: Zero or more organization IDs.  Only offers that are
    offered to the organization IDs in this list should be included in
    the result set.  The result set is also subject to other query
    criteria in the request.
 o  offeredTo: Zero or more organization IDs.  Only offers that are
    offered by the organization IDs in this list should be included in
    the result set.  The result set is also subject to other query
    criteria in the request.
 o  status: The status of the offer, offered or accepted.  Only offers
    in the specified status should be included in the result set.  If
    this element is not present, then the status of the offer should
    not be considered in the query.  The result set is also subject to
    other query criteria in the request.

Cartwright, et al. Standards Track [Page 27] RFC 7878 SPP Protocol over SOAP August 2016

 o  sedGrpOfferKey: Zero or more SED Group Offer keys.  Only offers
    having one of these keys should be included in the result set.
    The result set is also subject to other query criteria in the
    request.

7.2.7.2. Get SED Group Offers Response

 The spppGetResponse element is described in Section 7.2.8.

7.2.8. Generic Query Response

 An SPPP over SOAP query response object is contained within the
 generic <spppGetResponse> element.
    <element name="spppGetResponse">
     <complexType>
      <sequence>
       <element name="overallResult"
       type="sppfs:ResultCodeType"/>
       <element name="resultObj"
       type="sppfb:BasicObjType"
       minOccurs="0" maxOccurs="unbounded"/>
      </sequence>
     </complexType>
    </element>
 An <spppGetResponse> contains the elements necessary for the SPPF
 client to precisely determine the overall result of the query and
 details of any SPPF objects that matched the criteria in the request.
 The data elements within the SPPP over SOAP query response are
 described as follows:
 o  overallResult: Exactly one response code and message pair that
    explicitly identifies the result of the request.  See Section 7.3
    for further details.
 o  resultObj: The set of zero or more objects that matched the query
    criteria.  If no objects matched the query criteria, then the
    result object(s) MUST be empty and the overallResult value MUST
    indicate success (if no matches are found for the query criteria,
    the response is considered a success).

Cartwright, et al. Standards Track [Page 28] RFC 7878 SPP Protocol over SOAP August 2016

7.2.9. Get Server Details Operation Structure

 In order to query certain details of the SPPF server, such as the
 SPPF server's status and the major/minor version supported by the
 server, the Server Details operation structure SHOULD be used.  This
 structure is contained within the <spppServerStatusRequest> element
 whereas an SPPF server status response is wrapped within the
 <spppServerStatusResponse> element.  The following subsections
 describe the <spppServerStatusRequest> and <spppServerStatusResponse>
 elements.

7.2.9.1. Get Server Details Request

 An SPPP over SOAP server details request structure is represented in
 the <spppServerStatusRequest> element as follows:
    <element name="spppServerStatusRequest">
     <complexType>
      <sequence>
       <element name="minorVer"
       type="sppfb:MinorVerType" minOccurs="0"/>
      </sequence>
     </complexType>
    </element>
 The data elements within the <spppServerStatusRequest> element are
 described as follows:
 o  minorVer: Zero or one minor version identifier, as defined in
    Section 7.4.

7.2.9.2. Get Server Details Response

 An SPPP over SOAP server details response structure is contained
 within the generic <spppServerStatusResponse> element.
    <element name="spppServerStatusResponse">
     <complexType>
      <sequence>
       <element name="overallResult" type="sppfs:ResultCodeType"/>
       <element name="svcMenu" type="sppfb:SvcMenuType"/>
      </sequence>
     </complexType>
    </element>

Cartwright, et al. Standards Track [Page 29] RFC 7878 SPP Protocol over SOAP August 2016

 The data elements within the <spppServerStatusResponse> element are
 described as follows:
 o  overallResult: Exactly one response code and message pair that
    explicitly identifies the result of the request.  See Section 7.3
    for further details.
 o  svcMenu: Exactly one element of type SvcMenuType that, in turn,
    contains the elements to return the server status, the major and
    minor versions of SPPP over SOAP supported by the SPPF server
    (refer to Section 12 of [RFC7877] for the definition of
    SvcMenuType).

7.3. Response Codes and Messages

 This section contains the listing of response codes and their
 corresponding human-readable text.  These response codes are in
 conformance with the response types defined in Section 5.3 of
 [RFC7877].
 The response code numbering scheme generally adheres to the theory
 formalized in Section 4.2.1 of [RFC5321]:
 o  The first digit of the response code can only be 1 or 2: 1 = a
    positive result, and 2 = a negative result.
 o  The second digit of the response code indicates the category: 0 =
    Protocol Syntax, 1 = Implementation Specific Business Rule, 2 =
    Security, and 3 = Server System.
 o  The third and fourth digits of the response code indicate the
    individual message event within the category defined by the first
    two digits.
 The response codes are also categorized as to whether they are
 overall response codes that may only be returned in the overallResult
 data element in SPPF responses or object-level response codes that
 may only be returned in the detailResult element of the SPPF
 responses.

Cartwright, et al. Standards Track [Page 30] RFC 7878 SPP Protocol over SOAP August 2016

 +--------+--------------------------+-------------------------------+
 | Result | Result Message           | Overall or Object Level       |
 | Code   |                          |                               |
 +--------+--------------------------+-------------------------------+
 | 1000   | Request succeeded        | Overall Response Code         |
 | 2000   | Request syntax invalid   | Overall Response Code         |
 | 2001   | Request too large        | Overall Response Code         |
 |        | MaxSupported:[Maximum    |                               |
 |        | requests supported]      |                               |
 | 2002   | Version not supported    | Overall Response Code         |
 | 2100   | Command invalid          | Overall Response Code         |
 | 2300   | System temporarily       | Overall Response Code         |
 |        | unavailable              |                               |
 | 2301   | Unexpected internal      | Overall Response Code         |
 |        | system or server error   |                               |
 | 2101   | Attribute value invalid  | Object-Level Response Code    |
 |        | AttrName:[AttributeName] |                               |
 |        | AttrVal:[AttributeValue] |                               |
 | 2102   | Object does not exist    | Object-Level Response Code    |
 |        | AttrName:[AttributeName] |                               |
 |        | AttrVal:[AttributeValue] |                               |
 | 2103   | Object status or         | Object-Level Response Code    |
 |        | ownership does not allow |                               |
 |        | for operation            |                               |
 |        | AttrName:[AttributeName] |                               |
 |        | AttrVal:[AttributeValue] |                               |
 +--------+--------------------------+-------------------------------+
         Table 1: Response Code Numbering Scheme and Messages
 The response message for response code 2001 is "parameterized" with
 the following parameter: "[Maximum requests supported]".  When the
 request is too large, this parameter MUST be used to indicate the
 maximum number of requests supported by the server in a single
 protocol operation.
 Response code 2000 SHOULD be used when the XML Schema validation of
 requests fails.
 Each of the object-level response messages are "parameterized" with
 the following parameters: "AttributeName" and "AttributeValue".
 For example, if an SPPF client sends a request to delete a
 Destination Group with a name "TestDG", and it does not already
 exist, then the error message returned should be: "Attribute value
 invalid.  AttrName:dgName AttrVal:TestDG".

Cartwright, et al. Standards Track [Page 31] RFC 7878 SPP Protocol over SOAP August 2016

 The use of these parameters MUST adhere to the rules defined in
 Section 5.3 of [RFC7877].

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 SPPP 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
    SPPP 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 SPPP over SOAP supported by the SPPF server for
    the given major version.  The versions of SPPP 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

 Refer to Section 7 of [RFC7877] for a description of all SPPF
 operations and any necessary semantics that MUST be adhered to in
 order to conform with SPPF.

9. SPPP over SOAP WSDL Definition

 The SPPP over SOAP WSDL and data types are defined below.  The WSDL
 design approach is commonly referred to as "Generic WSDL".  It is
 generic in the sense that there is not a specific WSDL operation
 defined for each object type that is supported by the SPPF protocol.
 There is a single WSDL structure for each type of SPPF operation.
 Each such WSDL structure contains exactly one input structure and one
 output structure that wraps any data elements that are part of the
 incoming request and the outgoing response, respectively.  The
 spppSOAPBinding in the WSDL defines the binding style as "document"
 and the encoding as "literal".  It is this combination of "wrapped"
 input and output data structures, "document" binding style, and
 "literal" encoding that characterize the Document Literal Wrapped
 style of WSDL specifications.
 Notes: The following WSDL has been formatted (e.g., tabs, spaces) to
 meet IETF requirements.  Deployments MUST replace
 "REPLACE_WITH_ACTUAL_URL" in the WSDL below with the URI of the SPPF
 server instance.

Cartwright, et al. Standards Track [Page 32] RFC 7878 SPP Protocol over SOAP August 2016

 <?xml version="1.0" encoding="UTF-8"?>
 <wsdl:definitions xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
 xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
 xmlns:xsd="http://www.w3.org/2001/XMLSchema"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xmlns:sppfb="urn:ietf:params:xml:ns:sppf:base:1"
 xmlns:sppfs="urn:ietf:params:xml:ns:sppf:soap:1"
 targetNamespace="urn:ietf:params:xml:ns:sppf:soap:1">
  <wsdl:types>
   <xsd:schema xmlns="http://www.w3.org/2001/XMLSchema"
   xmlns:sppfs="urn:ietf:params:xml:ns:sppf:soap:1"
   targetNamespace="urn:ietf:params:xml:ns:sppf:soap:1">
    <annotation>
     <documentation>
      ---- Import base schema ----
     </documentation>
    </annotation>
    <import namespace="urn:ietf:params:xml:ns:sppf:base:1"
    schemaLocation="sppfbase.xsd"/>
    <annotation>
     <documentation>
      ---- Key type(s) extended
      from base schema. ----
     </documentation>
    </annotation>
    <complexType name="ObjKeyType">
     <complexContent>
      <extension base="sppfb:ObjKeyType">
       <sequence>
        <element name="rant" type="sppfb:OrgIdType"/>
        <element name="name" type="sppfb:ObjNameType"/>
        <element name="type" type="sppfs:ObjKeyTypeEnum"/>
       </sequence>
      </extension>
     </complexContent>
    </complexType>
  <simpleType name="ObjKeyTypeEnum">
    <restriction base="token">
      <enumeration value="SedGrp"/>
      <enumeration value="DestGrp"/>
      <enumeration value="SedRec"/>
      <enumeration value="EgrRte"/>
    </restriction>
  </simpleType>
    <complexType name="SedGrpOfferKeyType">
     <complexContent>
      <extension base="sppfb:SedGrpOfferKeyType">

Cartwright, et al. Standards Track [Page 33] RFC 7878 SPP Protocol over SOAP August 2016

       <sequence>
        <element name="sedGrpKey"
        type="sppfs:ObjKeyType"/>
        <element name="offeredTo"
        type="sppfb:OrgIdType"/>
       </sequence>
      </extension>
     </complexContent>
    </complexType>
    <complexType name="PubIdKeyType">
     <complexContent>
      <extension base="sppfb:PubIdKeyType">
       <sequence>
        <element name="rant" type="sppfb:OrgIdType"/>
        <choice>
         <element name="number"
         type="sppfb:NumberType"/>
         <element name="range"
         type="sppfb:NumberRangeType"/>
        </choice>
       </sequence>
      </extension>
     </complexContent>
    </complexType>
    <annotation>
     <documentation>
      ---- Generic Request and
      Response Definitions ----
     </documentation>
    </annotation>
    <element name="spppAddRequest">
     <complexType>
      <sequence>
       <element name="clientTransId"
       type="sppfb:TransIdType" minOccurs="0"/>
       <element name="minorVer"
       type="sppfb:MinorVerType" minOccurs="0"/>
       <element name="obj" type="sppfb:BasicObjType"
       maxOccurs="unbounded"/>
      </sequence>
     </complexType>
    </element>
    <element name="spppDelRequest">
     <complexType>
      <sequence>
       <element name="clientTransId"

Cartwright, et al. Standards Track [Page 34] RFC 7878 SPP Protocol over SOAP August 2016

       type="sppfb:TransIdType" minOccurs="0"/>
       <element name="minorVer"
       type="sppfb:MinorVerType" minOccurs="0"/>
       <element name="objKey"
       type="sppfb:ObjKeyType" maxOccurs="unbounded"/>
      </sequence>
     </complexType>
    </element>
    <element name="spppAcceptRequest">
     <complexType>
      <sequence>
       <element name="clientTransId"
       type="sppfb:TransIdType" minOccurs="0"/>
       <element name="minorVer"
       type="sppfb:MinorVerType" minOccurs="0"/>
       <element name="sedGrpOfferKey"
       type="sppfs:SedGrpOfferKeyType"
       maxOccurs="unbounded"/>
      </sequence>
     </complexType>
    </element>
    <element name="spppRejectRequest">
     <complexType>
      <sequence>
       <element name="clientTransId"
       type="sppfb:TransIdType" minOccurs="0"/>
       <element name="minorVer"
       type="sppfb:MinorVerType" minOccurs="0"/>
       <element name="sedGrpOfferKey"
       type="sppfs:SedGrpOfferKeyType"
       maxOccurs="unbounded"/>
      </sequence>
     </complexType>
    </element>
    <element name="spppGetRequest">
     <complexType>
      <sequence>
       <element name="minorVer"
       type="sppfb:MinorVerType" minOccurs="0"/>
       <element name="objKey"
       type="sppfb:ObjKeyType"
       maxOccurs="unbounded"/>
      </sequence>
     </complexType>
    </element>
    <element name="spppBatchRequest">
     <complexType>
      <sequence>

Cartwright, et al. Standards Track [Page 35] RFC 7878 SPP Protocol over SOAP August 2016

       <element name="clientTransId"
       type="sppfb:TransIdType" minOccurs="0"/>
       <element name="minorVer"
       type="sppfb:MinorVerType" minOccurs="0"/>
        <choice minOccurs="1" maxOccurs="unbounded">
         <element name="addObj" type="sppfb:BasicObjType"/>
         <element name="delObj" type="sppfb:ObjKeyType"/>
         <element name="acceptSedGrpOffer"
         type="sppfs:SedGrpOfferKeyType"/>
         <element name="rejectSedGrpOffer"
         type="sppfs:SedGrpOfferKeyType"/>
        </choice>
      </sequence>
     </complexType>
    </element>
    <element name="spppServerStatusRequest">
     <complexType>
      <sequence>
       <element name="minorVer"
       type="sppfb:MinorVerType" minOccurs="0"/>
      </sequence>
     </complexType>
    </element>
    <element name="getSedGrpOffersRequest">
     <complexType>
      <sequence>
       <element name="minorVer"
       type="sppfb:MinorVerType" minOccurs="0"/>
      <element name="offeredBy"
      type="sppfb:OrgIdType" minOccurs="0"
      maxOccurs="unbounded"/>
      <element name="offeredTo" type="sppfb:OrgIdType"
      minOccurs="0" maxOccurs="unbounded"/>
      <element name="status"
      type="sppfb:SedGrpOfferStatusType" minOccurs="0"/>
      <element name="sedGrpOfferKey"
      type="sppfs:SedGrpOfferKeyType"
      minOccurs="0" maxOccurs="unbounded"/>
      </sequence>
     </complexType>
    </element>
    <element name="spppAddResponse">
     <complexType>
      <sequence>
       <element name="clientTransId"
       type="sppfb:TransIdType" minOccurs="0"/>
       <element name="serverTransId"
       type="sppfb:TransIdType"/>

Cartwright, et al. Standards Track [Page 36] RFC 7878 SPP Protocol over SOAP August 2016

       <element name="overallResult"
       type="sppfs:ResultCodeType"/>
       <element name="detailResult"
       type="sppfs:ObjResultCodeType"
       minOccurs="0" maxOccurs="unbounded"/>
      </sequence>
     </complexType>
    </element>
    <element name="spppDelResponse">
     <complexType>
      <sequence>
       <element name="clientTransId"
       type="sppfb:TransIdType" minOccurs="0"/>
       <element name="serverTransId"
       type="sppfb:TransIdType"/>
       <element name="overallResult"
       type="sppfs:ResultCodeType"/>
       <element name="detailResult"
       type="sppfs:ObjKeyResultCodeType"
       minOccurs="0" maxOccurs="unbounded"/>
      </sequence>
     </complexType>
    </element>
    <element name="spppAcceptResponse">
     <complexType>
      <sequence>
       <element name="clientTransId"
       type="sppfb:TransIdType" minOccurs="0"/>
       <element name="serverTransId"
       type="sppfb:TransIdType"/>
       <element name="overallResult"
       type="sppfs:ResultCodeType"/>
       <element name="detailResult"
       type="sppfs:SedGrpOfferKeyResultCodeType"
       minOccurs="0" maxOccurs="unbounded"/>
      </sequence>
     </complexType>
    </element>
    <element name="spppRejectResponse">
     <complexType>
      <sequence>
       <element name="clientTransId"
       type="sppfb:TransIdType" minOccurs="0"/>
       <element name="serverTransId"
       type="sppfb:TransIdType"/>
       <element name="overallResult"
       type="sppfs:ResultCodeType"/>
       <element name="detailResult"

Cartwright, et al. Standards Track [Page 37] RFC 7878 SPP Protocol over SOAP August 2016

       type="sppfs:SedGrpOfferKeyResultCodeType"
       minOccurs="0" maxOccurs="unbounded"/>
      </sequence>
     </complexType>
    </element>
     <element name="spppBatchResponse">
     <complexType>
      <sequence>
       <element name="clientTransId"
       type="sppfb:TransIdType" minOccurs="0"/>
       <element name="serverTransId"
       type="sppfb:TransIdType"/>
       <element name="overallResult"
       type="sppfs:ResultCodeType"/>
        <choice minOccurs="0" maxOccurs="unbounded">
         <element name="addResult"
                  type="sppfs:ObjResultCodeType"/>
         <element name="delResult"
                  type="sppfs:ObjKeyResultCodeType"/>
         <element name="acceptResult"
                  type="sppfs:SedGrpOfferKeyResultCodeType"/>
         <element name="rejectResult"
                type="sppfs:SedGrpOfferKeyResultCodeType"/>
        </choice>
      </sequence>
     </complexType>
    </element>
    <element name="spppGetResponse">
     <complexType>
      <sequence>
       <element name="overallResult"
       type="sppfs:ResultCodeType"/>
       <element name="resultObj"
       type="sppfb:BasicObjType"
       minOccurs="0" maxOccurs="unbounded"/>
      </sequence>
     </complexType>
    </element>
    <element name="spppServerStatusResponse">
     <complexType>
      <sequence>
       <element name="overallResult"
       type="sppfs:ResultCodeType"/>
       <element name="svcMenu"
       type="sppfb:SvcMenuType"/>
      </sequence>
     </complexType>
    </element>

Cartwright, et al. Standards Track [Page 38] RFC 7878 SPP Protocol over SOAP August 2016

    <annotation>
     <documentation>
      ---- Operation Result Type
      Definitions ----
     </documentation>
    </annotation>
    <complexType name="ResultCodeType">
     <sequence>
      <element name="code" type="sppfs:ResultCodeValType"/>
      <element name="msg" type="sppfs:MsgType"/>
     </sequence>
    </complexType>
    <simpleType name="ResultCodeValType">
      <restriction base="unsignedShort">
        <enumeration value="1000"/>
        <enumeration value="2000"/>
        <enumeration value="2001"/>
        <enumeration value="2002"/>
        <enumeration value="2100"/>
        <enumeration value="2101"/>
        <enumeration value="2102"/>
        <enumeration value="2103"/>
        <enumeration value="2300"/>
        <enumeration value="2301"/>
      </restriction>
    </simpleType>
    <simpleType name="MsgType">
      <restriction base="token">
       <minLength value="3"/>
       <maxLength value="255"/>
      </restriction>
     </simpleType>
    <complexType name="ObjResultCodeType">
     <complexContent>
      <extension base="sppfs:ResultCodeType">
       <sequence>
        <element name="obj" type="sppfb:BasicObjType"/>
       </sequence>
      </extension>
     </complexContent>
    </complexType>
    <complexType name="ObjKeyResultCodeType">
     <complexContent>
      <extension base="sppfs:ResultCodeType">
       <sequence>

Cartwright, et al. Standards Track [Page 39] RFC 7878 SPP Protocol over SOAP August 2016

        <element name="objKey" type="sppfb:ObjKeyType"/>
       </sequence>
      </extension>
     </complexContent>
    </complexType>
       <complexType name="SedGrpOfferKeyResultCodeType">
     <complexContent>
      <extension base="sppfs:ResultCodeType">
       <sequence>
        <element name="sedGrpOfferKey"
        type="sppfs:SedGrpOfferKeyType"/>
       </sequence>
      </extension>
     </complexContent>
     </complexType>
   </xsd:schema>
  </wsdl:types>
  <wsdl:message name="spppAddRequestMsg">
   <wsdl:part name="rqst" element="sppfs:spppAddRequest"/>
  </wsdl:message>
  <wsdl:message name="spppDelRequestMsg">
   <wsdl:part name="rqst" element="sppfs:spppDelRequest"/>
  </wsdl:message>
  <wsdl:message name="spppAcceptRequestMsg">
   <wsdl:part name="rqst" element="sppfs:spppAcceptRequest"/>
  </wsdl:message>
  <wsdl:message name="spppRejectRequestMsg">
   <wsdl:part name="rqst" element="sppfs:spppRejectRequest"/>
  </wsdl:message>
  <wsdl:message name="spppBatchRequestMsg">
   <wsdl:part name="rqst" element="sppfs:spppBatchRequest"/>
  </wsdl:message>
  <wsdl:message name="spppGetRequestMsg">
   <wsdl:part name="rqst" element="sppfs:spppGetRequest"/>
  </wsdl:message>
  <wsdl:message name="spppGetSedGrpOffersRequestMsg">
   <wsdl:part name="rqst" element="sppfs:getSedGrpOffersRequest"/>
  </wsdl:message>
  <wsdl:message name="spppAddResponseMsg">
   <wsdl:part name="rspns" element="sppfs:spppAddResponse"/>
  </wsdl:message>
   <wsdl:message name="spppDelResponseMsg">
   <wsdl:part name="rspns" element="sppfs:spppDelResponse"/>
  </wsdl:message>
   <wsdl:message name="spppAcceptResponseMsg">
   <wsdl:part name="rspns" element="sppfs:spppAcceptResponse"/>
  </wsdl:message>
   <wsdl:message name="spppRejectResponseMsg">

Cartwright, et al. Standards Track [Page 40] RFC 7878 SPP Protocol over SOAP August 2016

   <wsdl:part name="rspns" element="sppfs:spppRejectResponse"/>
  </wsdl:message>
   <wsdl:message name="spppBatchResponseMsg">
   <wsdl:part name="rspns" element="sppfs:spppBatchResponse"/>
  </wsdl:message>
  <wsdl:message name="spppGetResponseMsg">
   <wsdl:part name="rspns" element="sppfs:spppGetResponse"/>
  </wsdl:message>
  <wsdl:message name="spppServerStatusRequestMsg">
   <wsdl:part name="rqst" element="sppfs:spppServerStatusRequest"/>
  </wsdl:message>
  <wsdl:message name="spppServerStatusResponseMsg">
   <wsdl:part name="rspns" element="sppfs:spppServerStatusResponse"/>
  </wsdl:message>
  <wsdl:portType name="spppPortType">
   <wsdl:operation name="submitAddRqst">
    <wsdl:input message="sppfs:spppAddRequestMsg"/>
    <wsdl:output message="sppfs:spppAddResponseMsg"/>
   </wsdl:operation>
   <wsdl:operation name="submitDelRqst">
    <wsdl:input message="sppfs:spppDelRequestMsg"/>
    <wsdl:output message="sppfs:spppDelResponseMsg"/>
   </wsdl:operation>
   <wsdl:operation name="submitAcceptRqst">
    <wsdl:input message="sppfs:spppAcceptRequestMsg"/>
    <wsdl:output message="sppfs:spppAcceptResponseMsg"/>
   </wsdl:operation>
   <wsdl:operation name="submitRejectRqst">
    <wsdl:input message="sppfs:spppRejectRequestMsg"/>
    <wsdl:output message="sppfs:spppRejectResponseMsg"/>
   </wsdl:operation>
   <wsdl:operation name="submitBatchRqst">
    <wsdl:input message="sppfs:spppBatchRequestMsg"/>
    <wsdl:output message="sppfs:spppBatchResponseMsg"/>
   </wsdl:operation>
   <wsdl:operation name="submitGetRqst">
    <wsdl:input message="sppfs:spppGetRequestMsg"/>
    <wsdl:output message="sppfs:spppGetResponseMsg"/>
   </wsdl:operation>
   <wsdl:operation name="submitGetSedGrpOffersRqst">
    <wsdl:input message="sppfs:spppGetSedGrpOffersRequestMsg"/>
    <wsdl:output message="sppfs:spppGetResponseMsg"/>
   </wsdl:operation>
   <wsdl:operation name="submitServerStatusRqst">
    <wsdl:input message="sppfs:spppServerStatusRequestMsg"/>
    <wsdl:output message="sppfs:spppServerStatusResponseMsg"/>
   </wsdl:operation>
  </wsdl:portType>

Cartwright, et al. Standards Track [Page 41] RFC 7878 SPP Protocol over SOAP August 2016

  <wsdl:binding name="spppSoapBinding" type="sppfs:spppPortType">
   <soap:binding style="document"
   transport="http://schemas.xmlsoap.org/soap/http"/>
   <wsdl:operation name="submitAddRqst">
    <soap:operation soapAction="submitAddRqst" style="document"/>
    <wsdl:input>
     <soap:body use="literal"/>
    </wsdl:input>
    <wsdl:output>
     <soap:body use="literal"/>
    </wsdl:output>
   </wsdl:operation>
   <wsdl:operation name="submitDelRqst">
    <soap:operation soapAction="submitDelRqst" style="document"/>
    <wsdl:input>
     <soap:body use="literal"/>
    </wsdl:input>
    <wsdl:output>
     <soap:body use="literal"/>
    </wsdl:output>
   </wsdl:operation>
   <wsdl:operation name="submitAcceptRqst">
    <soap:operation soapAction="submitAcceptRqst" style="document"/>
    <wsdl:input>
     <soap:body use="literal"/>
    </wsdl:input>
    <wsdl:output>
     <soap:body use="literal"/>
    </wsdl:output>
   </wsdl:operation>
   <wsdl:operation name="submitRejectRqst">
    <soap:operation soapAction="submitRejectRqst" style="document"/>
    <wsdl:input>
     <soap:body use="literal"/>
    </wsdl:input>
    <wsdl:output>
     <soap:body use="literal"/>
    </wsdl:output>
   </wsdl:operation>
   <wsdl:operation name="submitBatchRqst">
    <soap:operation soapAction="submitBatchRqst" style="document"/>
    <wsdl:input>
     <soap:body use="literal"/>
    </wsdl:input>
    <wsdl:output>
     <soap:body use="literal"/>
    </wsdl:output>
   </wsdl:operation>

Cartwright, et al. Standards Track [Page 42] RFC 7878 SPP Protocol over SOAP August 2016

   <wsdl:operation name="submitGetRqst">
    <soap:operation soapAction="submitGetRqst" style="document"/>
    <wsdl:input>
     <soap:body use="literal"/>
    </wsdl:input>
    <wsdl:output>
     <soap:body use="literal"/>
    </wsdl:output>
   </wsdl:operation>
   <wsdl:operation name="submitGetSedGrpOffersRqst">
    <soap:operation soapAction="submitGetSedGrpOffersRqst"
    style="document"/>
    <wsdl:input>
     <soap:body use="literal"/>
    </wsdl:input>
    <wsdl:output>
     <soap:body use="literal"/>
    </wsdl:output>
   </wsdl:operation>
   <wsdl:operation name="submitServerStatusRqst">
    <soap:operation soapAction="submitServerStatusRqst"
    style="document"/>
    <wsdl:input>
     <soap:body use="literal"/>
    </wsdl:input>
    <wsdl:output>
     <soap:body use="literal"/>
    </wsdl:output>
   </wsdl:operation>
  </wsdl:binding>
  <wsdl:service name="spppService">
   <wsdl:port name="spppPort" binding="sppfs:spppSoapBinding">
    <soap:address location="REPLACE_WITH_ACTUAL_URL"/>
   </wsdl:port>
  </wsdl:service>
 </wsdl:definitions>
                            Figure 2: WSDL

Cartwright, et al. Standards Track [Page 43] RFC 7878 SPP Protocol over SOAP August 2016

10. SPPP over SOAP Examples

 This section shows an XML message exchange between two SIP Service
 Providers (SSPs) and a Registry.  The messages in this section are
 valid XML instances that conform to the SPPP over SOAP schema version
 within this document.  This section also relies on the XML data
 structures defined in the SPPF specification [RFC7877], which should
 also be referenced to understand XML object types embedded in these
 example messages.
 In this sample use-case scenario, SSP1 and SSP2 provision resource
 data in the Registry and use SPPF constructs to selectively share the
 SED Groups.  In the figure below, SSP2 has two ingress Signaling Path
 Border Element (SBE) instances that are associated with the Public
 Identities with which SSP2 has the retail relationship.  Also, the
 two SBE instances for SSP1 are used to show how to use SPPF to
 associate route preferences for the destination Ingress Routes and
 exercise greater control on outbound traffic to the peer's ingress
 SBEs.
  1. ————–+ +——————

| |

               +------+               +------+
               | sbe1 |               | sbe2 |
               +------+               +------+
     SSP1          |                      |           SSP2
               +------+               +------+
               | sbe3 |               | sbe4 |
               +------+               +------+
    iana-en:111    |                      |     iana-en:222
    ---------------+                      +------------------
            |                                     |
            |                                     |
            | SPPF   +------------------+   SPPF  |
            +------->|     Registry     |<--------+
                     +------------------+
                    Example Use-Case Infrastructure

10.1. Add Destination Group

 SSP2 adds a Destination Group to the Registry for later use.  The
 SSP2 SPPF client sets a unique transaction identifier "txn_1479" for
 tracking purposes.  The name of the Destination Group is set to
 DEST_GRP_SSP2_1.

Cartwright, et al. Standards Track [Page 44] RFC 7878 SPP Protocol over SOAP August 2016

 <?xml version="1.0" encoding="UTF-8"?>
 <soapenv:Envelope
 xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
 xmlns:urn="urn:ietf:params:xml:ns:sppf:soap:1"
 xmlns:urn1="urn:ietf:params:xml:ns:sppf:base:1"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <soapenv:Header/>
  <soapenv:Body>
   <urn:spppAddRequest>
    <!--Optional:-->
    <clientTransId>txn_1479</clientTransId>
     <!--1 or more repetitions:-->
    <obj xsi:type="urn1:DestGrpType">
     <urn1:rant>iana-en:222</urn1:rant>
     <urn1:rar>iana-en:223</urn1:rar>
     <urn1:dgName>DEST_GRP_SSP2_1</urn1:dgName>
    </obj>
   </urn:spppAddRequest>
  </soapenv:Body>
 </soapenv:Envelope>
 The Registry processes the request and returns a favorable response
 confirming successful creation of the named Destination Group.  In
 addition to returning a unique server transaction identifier, the
 Registry returns the matching client transaction identifier from the
 request message back to the SPPF client.
 <?xml version="1.0" encoding="UTF-8"?>
 <S:Envelope
 xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
  <S:Body>
   <ns3:spppAddResponse
    xmlns:ns2="urn:ietf:params:xml:ns:sppf:base:1"
    xmlns:ns3="urn:ietf:params:xml:ns:sppf:soap:1">
    <clientTransId>txn_1479</clientTransId>
    <serverTransId>tx_12345</serverTransId>
    <overallResult>
     <code>1000</code>
     <msg>Request Succeeded.</msg>
    </overallResult>
   </ns3:spppAddResponse>
  </S:Body>
 </S:Envelope>

Cartwright, et al. Standards Track [Page 45] RFC 7878 SPP Protocol over SOAP August 2016

10.2. Add SED Records

 SSP2 adds SED Records in the form of Ingress Routes to the Registry.
 <?xml version="1.0" encoding="UTF-8"?>
 <soapenv:Envelope
 xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
 xmlns:urn="urn:ietf:params:xml:ns:sppf:soap:1"
 xmlns:urn1="urn:ietf:params:xml:ns:sppf:base:1"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <soapenv:Header/>
  <soapenv:Body>
   <urn:spppAddRequest>
    <!--Optional:-->
    <clientTransId>txn_1479</clientTransId>
    <!--1 or more repetitions:-->
    <obj xsi:type="urn1:NAPTRType">
     <urn1:rant>iana-en:222</urn1:rant>
     <urn1:rar>iana-en:223</urn1:rar>
     <urn1:sedName>SED_SSP2_SBE2</urn1:sedName>
     <urn1:isInSvc>true</urn1:isInSvc>
     <urn1:order>10</urn1:order>
     <urn1:flags>u</urn1:flags>
     <urn1:svcs>E2U+sip</urn1:svcs>
     <urn1:regx>
      <urn1:ere>^(.*)$</urn1:ere>
      <urn1:repl>sip:\1@sbe2.ssp2.example.com</urn1:repl>
     </urn1:regx>
    </obj>
   </urn:spppAddRequest>
  </soapenv:Body>
 </soapenv:Envelope>

Cartwright, et al. Standards Track [Page 46] RFC 7878 SPP Protocol over SOAP August 2016

 The Registry returns a success response.
 <?xml version="1.0" encoding="UTF-8"?>
 <S:Envelope
 xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
  <S:Body>
   <ns3:spppAddResponse
    xmlns:ns2="urn:ietf:params:xml:ns:sppf:base:1"
    xmlns:ns3="urn:ietf:params:xml:ns:sppf:soap:1">
    <clientTransId>txn_1479</clientTransId>
    <serverTransId>tx_12345</serverTransId>
    <overallResult>
     <code>1000</code>
     <msg>Request Succeeded.</msg>
    </overallResult>
   </ns3:spppAddResponse>
  </S:Body>
 </S:Envelope>

10.3. Add SED Records – URIType

 SSP2 adds another SED Record to the Registry and makes use of
 URIType.
 <?xml version="1.0" encoding="UTF-8"?>
 <soapenv:Envelope
 xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
 xmlns:urn="urn:ietf:params:xml:ns:sppf:soap:1"
 xmlns:urn1="urn:ietf:params:xml:ns:sppf:base:1"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <soapenv:Header/>
  <soapenv:Body>
   <urn:spppAddRequest>
    <clientTransId>txn_1479</clientTransId>
     <!--1 or more repetitions:-->
    <obj xsi:type="urn1:URIType">
     <urn1:rant>iana-en:222</urn1:rant>
     <urn1:rar>iana-en:223</urn1:rar>
     <urn1:sedName>SED_SSP2_SBE4</urn1:sedName>
     <urn1:isInSvc>true</urn1:isInSvc>
     <urn1:ere>^(.*)$</urn1:ere>
     <urn1:uri>sip:\1;npdi@sbe4.ssp2.example.com</urn1:uri>
    </obj>
   </urn:spppAddRequest>
  </soapenv:Body>
 </soapenv:Envelope>

Cartwright, et al. Standards Track [Page 47] RFC 7878 SPP Protocol over SOAP August 2016

 The Registry returns a success response.
 <?xml version="1.0" encoding="UTF-8"?>
 <S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
  <S:Body>
   <ns3:spppAddResponse
    xmlns:ns2="urn:ietf:params:xml:ns:sppf:base:1"
    xmlns:ns3="urn:ietf:params:xml:ns:sppf:soap:1">
    <clientTransId>txn_1479</clientTransId>
    <serverTransId>tx_12345</serverTransId>
    <overallResult>
     <code>1000</code>
     <msg>Request Succeeded.</msg>
    </overallResult>
   </ns3:spppAddResponse>
  </S:Body>
 </S:Envelope>

Cartwright, et al. Standards Track [Page 48] RFC 7878 SPP Protocol over SOAP August 2016

10.4. Add SED Group

 SSP2 creates the grouping of SED Records (e.g., Ingress Routes) and
 chooses a higher precedence for SED_SSP2_SBE2 by setting a lower
 number for the "priority" attribute, a protocol agnostic precedence
 indicator.
 <?xml version="1.0" encoding="UTF-8"?>
 <soapenv:Envelope
  xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
  xmlns:urn="urn:ietf:params:xml:ns:sppf:soap:1"
  xmlns:urn1="urn:ietf:params:xml:ns:sppf:base:1"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <soapenv:Header/>
  <soapenv:Body>
   <urn:spppAddRequest>
    <clientTransId>txn_1479</clientTransId>
     <!--1 or more repetitions:-->
    <obj xsi:type="urn1:SedGrpType">
     <urn1:rant>iana-en:222</urn1:rant>
     <urn1:rar>iana-en:223</urn1:rar>
     <urn1:sedGrpName>SED_GRP_SSP2_1</urn1:sedGrpName>
     <urn1:sedRecRef>
      <urn1:sedKey xsi:type="urn:ObjKeyType">
       <rant>iana-en:222</rant>
       <name>SED_SSP2_SBE2</name>
       <type>SedRec</type>
      </urn1:sedKey>
      <urn1:priority>100</urn1:priority>
     </urn1:sedRecRef>
     <urn1:dgName>DEST_GRP_SSP2_1</urn1:dgName>
     <urn1:isInSvc>true</urn1:isInSvc>
     <urn1:priority>10</urn1:priority>
    </obj>
   </urn:spppAddRequest>
  </soapenv:Body>
 </soapenv:Envelope>

Cartwright, et al. Standards Track [Page 49] RFC 7878 SPP Protocol over SOAP August 2016

 To confirm successful processing of this request, the Registry
 returns a well-known result code "1000" to the SSP2 client.
 <?xml version="1.0" encoding="UTF-8"?>
 <S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
  <S:Body>
   <ns3:spppAddResponse
    xmlns:ns2="urn:ietf:params:xml:ns:sppf:base:1"
    xmlns:ns3="urn:ietf:params:xml:ns:sppf:soap:1">
    <clientTransId>txn_1479</clientTransId>
    <serverTransId>tx_12345</serverTransId>
    <overallResult>
     <code>1000</code>
     <msg>Request Succeeded.</msg>
    </overallResult>
   </ns3:spppAddResponse>
  </S:Body>
 </S:Envelope>

10.5. Add Public Identifier – Successful COR Claim

 SSP2 activates a TN Public Identifier by associating it with a valid
 Destination Group.  Further, SSP2 puts forth a claim that it is the
 carrier-of-record (COR) for the TN.
 <soapenv:Envelope
 xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
 xmlns:urn="urn:ietf:params:xml:ns:sppf:soap:1"
 xmlns:urn1="urn:ietf:params:xml:ns:sppf:base:1"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <soapenv:Header/>
  <soapenv:Body>
   <urn:spppAddRequest>
    <clientTransId>txn_1479</clientTransId>
     <!--1 or more repetitions:-->
    <obj xsi:type="urn1:TNType">
     <urn1:rant>iana-en:222</urn1:rant>
     <urn1:rar>iana-en:223</urn1:rar>
     <urn1:dgName>DEST_GRP_SSP2_1</urn1:dgName>
     <urn1:tn>+12025556666</urn1:tn>
     <urn1:corInfo>
      <urn1:corClaim>true</urn1:corClaim>
     </urn1:corInfo>
    </obj>
   </urn:spppAddRequest>
  </soapenv:Body>
 </soapenv:Envelope>

Cartwright, et al. Standards Track [Page 50] RFC 7878 SPP Protocol over SOAP August 2016

 Assuming that the Registry has access to TN authority data and it
 performs the required checks to verify that SSP2 is in fact the SP of
 record for the given TN, the request is processed successfully.  In
 the response message, the Registry sets the value of <cor> to "true"
 in order to confirm the SSP2 claim as the carrier-of-record, and the
 <corDate> reflects the time when the carrier-of-record claim is
 processed.
 <?xml version="1.0" encoding="UTF-8"?>
 <S:Envelope
  xmlns:S="http://schemas.xmlsoap.org/soap/envelope/"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <S:Body>
   <ns3:spppAddResponse
    xmlns:ns2="urn:ietf:params:xml:ns:sppf:base:1"
    xmlns:ns3="urn:ietf:params:xml:ns:sppf:soap:1">
    <clientTransId>txn_1479</clientTransId>
    <serverTransId>tx_12345</serverTransId>
    <overallResult>
     <code>1000</code>
     <msg>Request Succeeded.</msg>
    </overallResult>
    <detailResult>
     <code>1000</code>
     <msg>Request Succeeded.</msg>
     <obj xsi:type="ns2:TNType">
      <ns2:rant>iana-en:222</ns2:rant>
      <ns2:rar>iana-en:223</ns2:rar>
      <ns2:cDate>2010-05-30T09:30:10Z</ns2:cDate>
      <ns2:dgName>DEST_GRP_SSP2_1</ns2:dgName>
      <ns2:tn>+12025556666</ns2:tn>
      <ns2:corInfo>
       <ns2:corClaim>true</ns2:corClaim>
       <ns2:cor>true</ns2:cor>
       <ns2:corDate>2010-05-30T09:30:11Z</ns2:corDate>
      </ns2:corInfo>
     </obj>
    </detailResult>
   </ns3:spppAddResponse>
  </S:Body>
 </S:Envelope>

Cartwright, et al. Standards Track [Page 51] RFC 7878 SPP Protocol over SOAP August 2016

10.6. Add LRN

 If another entity that SSP2 shares SED (e.g., routes) with has access
 to Number Portability data, it may choose to perform route lookups by
 RN.  Therefore, SSP2 associates an RN to a Destination Group in order
 to facilitate Ingress Route discovery.
 <?xml version="1.0" encoding="UTF-8"?>
 <soapenv:Envelope
  xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
  xmlns:urn="urn:ietf:params:xml:ns:sppf:soap:1"
  xmlns:urn1="urn:ietf:params:xml:ns:sppf:base:1"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <soapenv:Header/>
  <soapenv:Body>
   <urn:spppAddRequest>
    <clientTransId>txn_1479</clientTransId>
     <!--1 or more repetitions:-->
    <obj xsi:type="urn1:RNType">
     <urn1:rant>iana-en:222</urn1:rant>
     <urn1:rar>iana-en:223</urn1:rar>
     <urn1:dgName>DEST_GRP_SSP2_1</urn1:dgName>
     <urn1:rn>2025550000</urn1:rn>
    </obj>
   </urn:spppAddRequest>
  </soapenv:Body>
 </soapenv:Envelope>

Cartwright, et al. Standards Track [Page 52] RFC 7878 SPP Protocol over SOAP August 2016

 The Registry completes the request successfully and returns a
 favorable response to the SPPF client.
 <?xml version="1.0" encoding="UTF-8"?>
 <S:Envelope
  xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
  <S:Body>
   <ns3:spppAddResponse
    xmlns:ns2="urn:ietf:params:xml:ns:sppf:base:1"
    xmlns:ns3="urn:ietf:params:xml:ns:sppf:soap:1">
    <clientTransId>txn_1479</clientTransId>
    <serverTransId>tx_12345</serverTransId>
    <overallResult>
     <code>1000</code>
     <msg>Request Succeeded.</msg>
    </overallResult>
   </ns3:spppAddResponse>
  </S:Body>
 </S:Envelope>

10.7. Add TN Range

 Next, SSP2 activates a block of ten thousand TNs and associates it to
 a Destination Group.
 <?xml version="1.0" encoding="UTF-8"?>
 <soapenv:Envelope
  xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
  xmlns:urn="urn:ietf:params:xml:ns:sppf:soap:1"
  xmlns:urn1="urn:ietf:params:xml:ns:sppf:base:1"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <soapenv:Header/>
  <soapenv:Body>
   <urn:spppAddRequest>
    <clientTransId>txn_1479</clientTransId>
     <!--1 or more repetitions:-->
    <obj xsi:type="urn1:TNRType">
     <urn1:rant>iana-en:222</urn1:rant>
     <urn1:rar>iana-en:223</urn1:rar>
     <urn1:dgName>DEST_GRP_SSP2_1</urn1:dgName>
     <urn1:range>
      <urn1:startTn>+12026660000</urn1:startTn>
      <urn1:endTn>+12026669999</urn1:endTn>
     </urn1:range>
    </obj>
   </urn:spppAddRequest>
  </soapenv:Body>
 </soapenv:Envelope>

Cartwright, et al. Standards Track [Page 53] RFC 7878 SPP Protocol over SOAP August 2016

 The Registry completes the request successfully and returns a
 favorable response.
 <?xml version="1.0" encoding="UTF-8"?>
 <S:Envelope
  xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
  <S:Body>
   <ns3:spppAddResponse
    xmlns:ns2="urn:ietf:params:xml:ns:sppf:base:1"
    xmlns:ns3="urn:ietf:params:xml:ns:sppf:soap:1">
    <clientTransId>txn_1479</clientTransId>
    <serverTransId>tx_12345</serverTransId>
    <overallResult>
     <code>1000</code>
     <msg>Request Succeeded.</msg>
    </overallResult>
   </ns3:spppAddResponse>
  </S:Body>
 </S:Envelope>

10.8. Add TN Prefix

 Next, SSP2 activates a block of ten thousand TNs by using the TNPType
 structure and identifying a TN prefix.
 <?xml version="1.0" encoding="UTF-8"?>
 <soapenv:Envelope
  xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
  xmlns:urn="urn:ietf:params:xml:ns:sppf:soap:1"
  xmlns:urn1="urn:ietf:params:xml:ns:sppf:base:1"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <soapenv:Header/>
  <soapenv:Body>
   <urn:spppAddRequest>
    <clientTransId>txn_1479</clientTransId>
     <!--1 or more repetitions:-->
    <obj xsi:type="urn1:TNPType">
     <urn1:rant>iana-en:222</urn1:rant>
     <urn1:rar>iana-en:223</urn1:rar>
     <urn1:dgName>DEST_GRP_SSP2_1</urn1:dgName>
     <urn1:tnPrefix>+1202777</urn1:tnPrefix>
    </obj>
   </urn:spppAddRequest>
  </soapenv:Body>
 </soapenv:Envelope>

Cartwright, et al. Standards Track [Page 54] RFC 7878 SPP Protocol over SOAP August 2016

 The Registry completes the request successfully and returns a
 favorable response.
 <?xml version="1.0" encoding="UTF-8"?>
 <S:Envelope
  xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
  <S:Body>
   <ns3:spppAddResponse
    xmlns:ns2="urn:ietf:params:xml:ns:sppf:base:1"
    xmlns:ns3="urn:ietf:params:xml:ns:sppf:soap:1">
    <clientTransId>txn_1479</clientTransId>
    <serverTransId>tx_12345</serverTransId>
    <overallResult>
     <code>1000</code>
     <msg>Request Succeeded.</msg>
    </overallResult>
   </ns3:spppAddResponse>
  </S:Body>
 </S:Envelope>

Cartwright, et al. Standards Track [Page 55] RFC 7878 SPP Protocol over SOAP August 2016

10.9. Enable Peering – SED Group Offer

 In order for SSP1 to complete session establishment for a destination
 TN where the target subscriber has a retail relationship with SSP2,
 it first requires an asynchronous bidirectional handshake to show
 mutual consent.  To start the process, SSP2 initiates the peering
 handshake by offering SSP1 access to its SED Group.
 <?xml version="1.0" encoding="UTF-8"?>
 <soapenv:Envelope
  xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
  xmlns:urn="urn:ietf:params:xml:ns:sppf:soap:1"
  xmlns:urn1="urn:ietf:params:xml:ns:sppf:base:1"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <soapenv:Header/>
  <soapenv:Body>
   <urn:spppAddRequest>
    <clientTransId>txn_1479</clientTransId>
     <!--1 or more repetitions:-->
    <obj xsi:type="urn1:SedGrpOfferType">
     <urn1:rant>iana-en:222</urn1:rant>
     <urn1:rar>iana-en:223</urn1:rar>
     <urn1:sedGrpOfferKey xsi:type="urn:SedGrpOfferKeyType">
      <sedGrpKey xsi:type="urn:ObjKeyType">
       <rant>iana-en:222</rant>
       <name>SED_GRP_SSP2_1</name>
       <type>SedGrp</type>
      </sedGrpKey>
      <offeredTo>iana-en:111</offeredTo>
     </urn1:sedGrpOfferKey>
     <urn1:status>offered</urn1:status>
     <urn1:offerDateTime>
       2006-05-04T18:13:51.0Z
     </urn1:offerDateTime>
    </obj>
   </urn:spppAddRequest>
  </soapenv:Body>
 </soapenv:Envelope>

Cartwright, et al. Standards Track [Page 56] RFC 7878 SPP Protocol over SOAP August 2016

 The Registry completes the request successfully and confirms that the
 SSP1 will now have the opportunity to weigh in on the offer and
 either accept or reject it.  The Registry may employ out-of-band
 notification mechanisms for quicker updates to SSP1 so they can act
 faster, though this topic is beyond the scope of this document.
 <?xml version="1.0" encoding="UTF-8"?>
 <S:Envelope
  xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
  <S:Body>
   <ns3:spppAddResponse
    xmlns:ns2="urn:ietf:params:xml:ns:sppf:base:1"
    xmlns:ns3="urn:ietf:params:xml:ns:sppf:soap:1">
    <clientTransId>txn_1479</clientTransId>
    <serverTransId>tx_12345</serverTransId>
    <overallResult>
     <code>1000</code>
     <msg>Request Succeeded.</msg>
    </overallResult>
   </ns3:spppAddResponse>
  </S:Body>
 </S:Envelope>

Cartwright, et al. Standards Track [Page 57] RFC 7878 SPP Protocol over SOAP August 2016

10.10. Enable Peering – SED Group Offer Accept

 SSP1 responds to the offer from SSP2 and agrees to have visibility to
 SSP2 SED (e.g., Ingress Routes).
 <?xml version="1.0" encoding="UTF-8"?>
 <soapenv:Envelope
  xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
  xmlns:urn="urn:ietf:params:xml:ns:sppf:soap:1">
  <soapenv:Header/>
  <soapenv:Body>
   <urn:spppAcceptRequest>
    <!--Optional:-->
    <clientTransId>txn_1479</clientTransId>
     <!--1 or more repetitions:-->
    <sedGrpOfferKey>
     <sedGrpKey>
      <rant>iana-en:222</rant>
      <name>SED_GRP_SSP2_1</name>
      <type>SedGrp</type>
     </sedGrpKey>
     <offeredTo>iana-en:111</offeredTo>
    </sedGrpOfferKey>
   </urn:spppAcceptRequest>
  </soapenv:Body>
 </soapenv:Envelope>

Cartwright, et al. Standards Track [Page 58] RFC 7878 SPP Protocol over SOAP August 2016

 The Registry confirms that the request has been processed
 successfully.  From this point forward, if SSP1 looks up a Public
 Identifier through the query resolution server, where the Public
 Identifier is part of the Destination Group by way of
 "SED_GRP_SSP2_1" SED association, SSP2 ingress SBE information will
 be shared with SSP1.
 <?xml version="1.0" encoding="UTF-8"?>
 <S:Envelope
  xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
  <S:Body>
   <ns3:spppAcceptResponse
    xmlns:ns2="urn:ietf:params:xml:ns:sppf:base:1"
    xmlns:ns3="urn:ietf:params:xml:ns:sppf:soap:1">
    <clientTransId>txn_1479</clientTransId>
    <serverTransId>tx_12350</serverTransId>
    <overallResult>
     <code>1000</code>
     <msg>Request Succeeded.</msg>
    </overallResult>
   </ns3:spppAcceptResponse>
  </S:Body>
 </S:Envelope>

Cartwright, et al. Standards Track [Page 59] RFC 7878 SPP Protocol over SOAP August 2016

10.11. Add Egress Route

 SSP1 wants to prioritize all outbound traffic to the Ingress Route
 associated with the "SED_GRP_SSP2_1" SED Group record, through
 "sbe1.ssp1.example.com".
 <?xml version="1.0" encoding="UTF-8"?>
 <soapenv:Envelope
  xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
  xmlns:urn="urn:ietf:params:xml:ns:sppf:soap:1"
  xmlns:urn1="urn:ietf:params:xml:ns:sppf:base:1"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <soapenv:Header/>
  <soapenv:Body>
   <urn:spppAddRequest>
    <clientTransId>txn_1479</clientTransId>
     <!--1 or more repetitions:-->
    <obj xsi:type="urn1:EgrRteType">
     <urn1:rant>iana-en:222</urn1:rant>
     <urn1:rar>iana-en:223</urn1:rar>
     <urn1:egrRteName>EGR_RTE_01</urn1:egrRteName>
     <urn1:pref>50</urn1:pref>
     <urn1:regxRewriteRule>
      <urn1:ere>^(.*@)(.*)$</urn1:ere>
      <urn1:repl>\1\2?route=sbe1.ssp1.example.com</urn1:repl>
     </urn1:regxRewriteRule>
     <urn1:ingrSedGrp xsi:type="urn:ObjKeyType">
      <rant>iana-en:222</rant>
      <name>SED_GRP_SSP2_1</name>
      <type>SedGrp</type>
     </urn1:ingrSedGrp>
    </obj>
   </urn:spppAddRequest>
  </soapenv:Body>
 </soapenv:Envelope>

Cartwright, et al. Standards Track [Page 60] RFC 7878 SPP Protocol over SOAP August 2016

 Since peering has already been established, the request to add the
 Egress Route has been successfully completed.
 <?xml version="1.0" encoding="UTF-8"?>
 <S:Envelope
  xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
  <S:Body>
   <ns3:spppAddResponse
    xmlns:ns2="urn:ietf:params:xml:ns:sppf:base:1"
    xmlns:ns3="urn:ietf:params:xml:ns:sppf:soap:1">
    <clientTransId>txn_1479</clientTransId>
    <serverTransId>tx_12345</serverTransId>
    <overallResult>
     <code>1000</code>
     <msg>Request Succeeded.</msg>
    </overallResult>
   </ns3:spppAddResponse>
  </S:Body>
 </S:Envelope>

10.12. Remove Peering – SED Group Offer Reject

 Earlier, SSP1 had accepted having visibility to SSP2 SED.  SSP1 now
 decides to no longer maintain this visibility; hence, it rejects the
 SED Group Offer.
 <?xml version="1.0" encoding="UTF-8"?>
 <soapenv:Envelope
  xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
  xmlns:urn="urn:ietf:params:xml:ns:sppf:soap:1">
  <soapenv:Header/>
  <soapenv:Body>
   <urn:spppRejectRequest>
    <!--Optional:-->
    <clientTransId>txn_1479</clientTransId>
     <!--1 or more repetitions:-->
    <sedGrpOfferKey>
     <sedGrpKey>
      <rant>iana-en:222</rant>
      <name>SED_GRP_SSP2_1</name>
      <type>SedGrp</type>
     </sedGrpKey>
     <offeredTo>iana-en:111</offeredTo>
    </sedGrpOfferKey>
   </urn:spppRejectRequest>
  </soapenv:Body>
 </soapenv:Envelope>

Cartwright, et al. Standards Track [Page 61] RFC 7878 SPP Protocol over SOAP August 2016

 The Registry confirms that the request has been processed
 successfully.  From this point forward, if SSP1 looks up a Public
 Identifier through the query resolution server, where the Public
 Identifier is part of the Destination Group by way of
 "SED_GRP_SSP2_1" SED association, SSP2 ingress SBE information will
 not be shared with SSP1; hence, an SSP2 ingress SBE will not be
 returned in the query response.
 <?xml version="1.0" encoding="UTF-8"?>
 <S:Envelope
  xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
  <S:Body>
   <ns3:spppRejectResponse
    xmlns:ns2="urn:ietf:params:xml:ns:sppf:base:1"
    xmlns:ns3="urn:ietf:params:xml:ns:sppf:soap:1">
    <clientTransId>txn_1479</clientTransId>
    <serverTransId>tx_12350</serverTransId>
    <overallResult>
     <code>1000</code>
     <msg>Request Succeeded.</msg>
    </overallResult>
   </ns3:spppRejectResponse>
  </S:Body>
 </S:Envelope>

10.13. Get Destination Group

 SSP2 uses the spppGetRequest operation to tally the last provisioned
 record for Destination Group DEST_GRP_SSP2_1.
 <?xml version="1.0" encoding="UTF-8"?>
 <soapenv:Envelope
  xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
  xmlns:urn="urn:ietf:params:xml:ns:sppf:soap:1"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <soapenv:Header/>
  <soapenv:Body>
   <urn:spppGetRequest>
    <!--1 or more repetitions:-->
    <objKey xsi:type="urn:ObjKeyType">
     <rant>iana-en:222</rant>
     <name>DEST_GRP_SSP2_1</name>
     <type>DestGrp</type>
    </objKey>
   </urn:spppGetRequest>
  </soapenv:Body>
 </soapenv:Envelope>

Cartwright, et al. Standards Track [Page 62] RFC 7878 SPP Protocol over SOAP August 2016

 The Registry completes the request successfully and returns a
 favorable response.
 <?xml version="1.0" encoding="UTF-8"?>
 <S:Envelope
  xmlns:S="http://schemas.xmlsoap.org/soap/envelope/"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <S:Body>
   <ns3:spppGetResponse
    xmlns:ns2="urn:ietf:params:xml:ns:sppf:base:1"
    xmlns:ns3="urn:ietf:params:xml:ns:sppf:soap:1">
    <overallResult>
     <code>1000</code>
     <msg>success</msg>
    </overallResult>
    <resultObj xsi:type="ns2:DestGrpType">
     <ns2:rant>iana-en:222</ns2:rant>
     <ns2:rar>iana-en:223</ns2:rar>
     <ns2:cDate>2012-10-22T09:30:10Z</ns2:cDate>
     <ns2:dgName>DEST_GRP_SSP2_1</ns2:dgName>
    </resultObj>
   </ns3:spppGetResponse>
  </S:Body>
 </S:Envelope>

Cartwright, et al. Standards Track [Page 63] RFC 7878 SPP Protocol over SOAP August 2016

10.14. Get Public Identifier

 SSP2 obtains the last provisioned record associated with a given TN.
 <?xml version="1.0" encoding="UTF-8"?>
 <soapenv:Envelope
  xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
  xmlns:urn="urn:ietf:params:xml:ns:sppf:soap:1"
  xmlns:urn1="urn:ietf:params:xml:ns:sppf:base:1"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <soapenv:Header/>
  <soapenv:Body>
   <urn:spppGetRequest>
    <!--1 or more repetitions:-->
    <objKey xsi:type="urn:PubIdKeyType">
     <rant>iana-en:222</rant>
     <number>
      <urn1:value>+12025556666</urn1:value>
      <urn1:type>TN</urn1:type>
     </number>
    </objKey>
   </urn:spppGetRequest>
  </soapenv:Body>
 </soapenv:Envelope>

Cartwright, et al. Standards Track [Page 64] RFC 7878 SPP Protocol over SOAP August 2016

 The Registry completes the request successfully and returns a
 favorable response.
 <S:Envelope
  xmlns:S="http://schemas.xmlsoap.org/soap/envelope/"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <S:Body>
   <ns3:spppGetResponse
    xmlns:ns2="urn:ietf:params:xml:ns:sppf:base:1"
    xmlns:ns3="urn:ietf:params:xml:ns:sppf:soap:1">
    <overallResult>
     <code>1000</code>
     <msg>success</msg>
    </overallResult>
    <resultObj xsi:type="ns2:TNType">
     <ns2:rant>iana-en:222</ns2:rant>
     <ns2:rar>iana-en:223</ns2:rar>
     <ns2:cDate>2012-10-22T09:30:10Z</ns2:cDate>
     <ns2:dgName>DEST_GRP_SSP2_1</ns2:dgName>
     <ns2:tn>+12025556666</ns2:tn>
     <ns2:corInfo>
      <ns2:corClaim>true</ns2:corClaim>
      <ns2:cor>true</ns2:cor>
      <ns2:corDate>2010-05-30T09:30:10Z</ns2:corDate>
     </ns2:corInfo>
    </resultObj>
   </ns3:spppGetResponse>
  </S:Body>
 </S:Envelope>

Cartwright, et al. Standards Track [Page 65] RFC 7878 SPP Protocol over SOAP August 2016

10.15. Get SED Group Request

 SSP2 obtains the last provisioned record for the SED Group
 SED_GRP_SSP2_1.
 <?xml version="1.0" encoding="UTF-8"?>
 <soapenv:Envelope
  xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
  xmlns:urn="urn:ietf:params:xml:ns:sppf:soap:1"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <soapenv:Header/>
  <soapenv:Body>
   <urn:spppGetRequest>
    <!--1 or more repetitions:-->
    <objKey xsi:type="urn:ObjKeyType">
     <rant>iana-en:222</rant>
     <name>SED_GRP_SSP2_1</name>
     <type>SedGrp</type>
    </objKey>
   </urn:spppGetRequest>
  </soapenv:Body>
 </soapenv:Envelope>

Cartwright, et al. Standards Track [Page 66] RFC 7878 SPP Protocol over SOAP August 2016

 The Registry completes the request successfully and returns a
 favorable response.
 <?xml version="1.0" encoding="UTF-8"?>
 <S:Envelope
  xmlns:S="http://schemas.xmlsoap.org/soap/envelope/"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <S:Body>
   <ns3:spppGetResponse
    xmlns:ns2="urn:ietf:params:xml:ns:sppf:base:1"
    xmlns:ns3="urn:ietf:params:xml:ns:sppf:soap:1">
    <overallResult>
     <code>1000</code>
     <msg>success</msg>
    </overallResult>
    <resultObj xsi:type="ns2:SedGrpType">
     <ns2:rant>iana-en:222</ns2:rant>
     <ns2:rar>iana-en:223</ns2:rar>
     <ns2:cDate>2012-10-22T09:30:10Z</ns2:cDate>
     <ns2:sedGrpName>SED_GRP_SSP2_1</ns2:sedGrpName>
     <ns2:sedRecRef>
      <ns2:sedKey xsi:type="ns3:ObjKeyType">
       <rant>iana-en:222</rant>
       <name>SED_SSP2_SBE2</name>
       <type>SedRec</type>
      </ns2:sedKey>
      <ns2:priority>100</ns2:priority>
     </ns2:sedRecRef>
     <ns2:sedRecRef>
      <ns2:sedKey xsi:type="ns3:ObjKeyType">
       <rant>iana-en:222</rant>
       <name>SED_SSP2_SBE4</name>
       <type>SedRec</type>
      </ns2:sedKey>
      <ns2:priority>101</ns2:priority>
     </ns2:sedRecRef>
     <ns2:dgName>DEST_GRP_SSP2_1</ns2:dgName>
     <ns2:isInSvc>true</ns2:isInSvc>
     <ns2:priority>10</ns2:priority>
    </resultObj>
   </ns3:spppGetResponse>
  </S:Body>
 </S:Envelope>

Cartwright, et al. Standards Track [Page 67] RFC 7878 SPP Protocol over SOAP August 2016

10.16. Get SED Group Offers Request

 SSP2 fetches the last provisioned SED Group Offer to the <peeringOrg>
 SSP1.
 <?xml version="1.0" encoding="UTF-8"?>
 <soapenv:Envelope
  xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
  xmlns:urn="urn:ietf:params:xml:ns:sppf:soap:1">
  <soapenv:Header/>
  <soapenv:Body>
   <urn:getSedGrpOffersRequest>
    <offeredTo>iana-en:111</offeredTo>
   </urn:getSedGrpOffersRequest>
  </soapenv:Body>
 </soapenv:Envelope>

Cartwright, et al. Standards Track [Page 68] RFC 7878 SPP Protocol over SOAP August 2016

 The Registry processes the request successfully and returns a
 favorable response.
 <?xml version="1.0" encoding="UTF-8"?>
 <S:Envelope
  xmlns:S="http://schemas.xmlsoap.org/soap/envelope/"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <S:Body>
   <ns3:spppGetResponse
    xmlns:ns2="urn:ietf:params:xml:ns:sppf:base:1"
    xmlns:ns3="urn:ietf:params:xml:ns:sppf:soap:1">
    <overallResult>
     <code>1000</code>
     <msg>success</msg>
    </overallResult>
    <resultObj xsi:type="ns2:SedGrpOfferType">
     <ns2:rant>iana-en:222</ns2:rant>
     <ns2:rar>iana-en:223</ns2:rar>
     <ns2:cDate>2012-10-22T09:30:10Z</ns2:cDate>
     <ns2:sedGrpOfferKey
      xsi:type="ns3:SedGrpOfferKeyType">
      <sedGrpKey>
       <rant>iana-en:222</rant>
       <name>SED_GRP_SSP2_1</name>
       <type>SedGrp</type>
      </sedGrpKey>
      <offeredTo>iana-en:111</offeredTo>
     </ns2:sedGrpOfferKey>
     <ns2:status>offered</ns2:status>
     <ns2:offerDateTime>
      2006-05-04T18:13:51.0Z
     </ns2:offerDateTime>
    </resultObj>
   </ns3:spppGetResponse>
  </S:Body>
 </S:Envelope>

Cartwright, et al. Standards Track [Page 69] RFC 7878 SPP Protocol over SOAP August 2016

10.17. Get Egress Route

 SSP1 wants to verify the last provisioned record for the Egress Route
 called EGR_RTE_01.
 <?xml version="1.0" encoding="UTF-8"?>
 <soapenv:Envelope
  xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
  xmlns:urn="urn:ietf:params:xml:ns:sppf:soap:1"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <soapenv:Header/>
  <soapenv:Body>
   <urn:spppGetRequest>
    <!--1 or more repetitions:-->
    <objKey xsi:type="urn:ObjKeyType">
     <rant>iana-en:111</rant>
     <name>EGR_RTE_01</name>
     <type>EgrRte</type>
    </objKey>
   </urn:spppGetRequest>
  </soapenv:Body>
 </soapenv:Envelope>

Cartwright, et al. Standards Track [Page 70] RFC 7878 SPP Protocol over SOAP August 2016

 The Registry completes the request successfully and returns a
 favorable response.
 <?xml version="1.0" encoding="UTF-8"?>
 <S:Envelope
  xmlns:S="http://schemas.xmlsoap.org/soap/envelope/"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <S:Body>
   <ns3:spppGetResponse
    xmlns:ns2="urn:ietf:params:xml:ns:sppf:base:1"
    xmlns:ns3="urn:ietf:params:xml:ns:sppf:soap:1">
    <overallResult>
     <code>1000</code>
     <msg>success</msg>
    </overallResult>
    <resultObj xsi:type="ns2:EgrRteType">
     <ns2:rant>iana-en:222</ns2:rant>
     <ns2:rar>iana-en:223</ns2:rar>
     <ns2:cDate>2012-10-22T09:30:10Z</ns2:cDate>
     <ns2:egrRteName>EGR_RTE_01</ns2:egrRteName>
     <ns2:pref>50</ns2:pref>
     <ns2:regxRewriteRule>
      <ns2:ere>^(.*)$</ns2:ere>
      <ns2:repl>sip:\1@sbe1.ssp1.example.com</ns2:repl>
     </ns2:regxRewriteRule>
     <ns2:ingrSedGrp xsi:type="ns3:ObjKeyType">
      <rant>iana-en:222</rant>
      <name>SED_GRP_SSP2_1</name>
      <type>SedRec</type>
     </ns2:ingrSedGrp>
    </resultObj>
   </ns3:spppGetResponse>
  </S:Body>
 </S:Envelope>

Cartwright, et al. Standards Track [Page 71] RFC 7878 SPP Protocol over SOAP August 2016

10.18. Delete Destination Group

 SSP2 initiates a request to delete the Destination Group
 DEST_GRP_SSP2_1.
 <?xml version="1.0" encoding="UTF-8"?>
 <soapenv:Envelope
  xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
  xmlns:urn="urn:ietf:params:xml:ns:sppf:soap:1"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <soapenv:Header/>
  <soapenv:Body>
   <urn:spppDelRequest>
     <!--1 or more repetitions:-->
    <objKey xsi:type="urn:ObjKeyType">
     <rant>iana-en:222</rant>
     <name>DEST_GRP_SSP2_1</name>
     <type>DestGrp</type>
    </objKey>
   </urn:spppDelRequest>
  </soapenv:Body>
 </soapenv:Envelope>
 The Registry completes the request successfully and returns a
 favorable response.
 <?xml version="1.0" encoding="UTF-8"?>
 <S:Envelope
  xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
  <S:Body>
   <ns3:spppDelResponse
    xmlns:ns2="urn:ietf:params:xml:ns:sppf:base:1"
    xmlns:ns3="urn:ietf:params:xml:ns:sppf:soap:1">
    <serverTransId>tx_12354</serverTransId>
    <overallResult>
     <code>1000</code>
     <msg>Request Succeeded.</msg>
    </overallResult>
   </ns3:spppDelResponse>
  </S:Body>
 </S:Envelope>

Cartwright, et al. Standards Track [Page 72] RFC 7878 SPP Protocol over SOAP August 2016

10.19. Delete Public Identifier

 SSP2 chooses to deactivate the TN and remove it from the Registry.
 <?xml version="1.0" encoding="UTF-8"?>
 <soapenv:Envelope
  xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
  xmlns:urn="urn:ietf:params:xml:ns:sppf:soap:1"
  xmlns:urn1="urn:ietf:params:xml:ns:sppf:base:1"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <soapenv:Header/>
  <soapenv:Body>
   <urn:spppDelRequest>
    <!--1 or more repetitions:-->
    <objKey xsi:type="urn:PubIdKeyType">
     <rant>iana-en:222</rant>
     <number>
      <urn1:value>+12025556666</urn1:value>
      <urn1:type>TN</urn1:type>
     </number>
    </objKey>
   </urn:spppDelRequest>
  </soapenv:Body>
 </soapenv:Envelope>
 The Registry completes the request successfully and returns a
 favorable response.
 <?xml version="1.0" encoding="UTF-8"?>
 <S:Envelope
  xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
  <S:Body>
   <ns3:spppDelResponse
    xmlns:ns2="urn:ietf:params:xml:ns:sppf:base:1"
    xmlns:ns3="urn:ietf:params:xml:ns:sppf:soap:1">
    <serverTransId>tx_12354</serverTransId>
    <overallResult>
     <code>1000</code>
     <msg>Request Succeeded.</msg>
    </overallResult>
   </ns3:spppDelResponse>
  </S:Body>
 </S:Envelope>

Cartwright, et al. Standards Track [Page 73] RFC 7878 SPP Protocol over SOAP August 2016

10.20. Delete SED Group Request

 SSP2 removes the SED Group called SED_GRP_SSP2_1.
 <?xml version="1.0" encoding="UTF-8"?>
 <soapenv:Envelope
  xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
  xmlns:urn="urn:ietf:params:xml:ns:sppf:soap:1"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <soapenv:Header/>
  <soapenv:Body>
   <urn:spppDelRequest>
     <!--1 or more repetitions:-->
    <objKey xsi:type="urn:ObjKeyType">
     <rant>iana-en:222</rant>
     <name>SED_GRP_SSP2_1</name>
     <type>SedGrp</type>
    </objKey>
   </urn:spppDelRequest>
  </soapenv:Body>
 </soapenv:Envelope>
 The Registry completes the request successfully and returns a
 favorable response.
 <?xml version="1.0" encoding="UTF-8"?>
 <S:Envelope
  xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
  <S:Body>
   <ns3:spppDelResponse
    xmlns:ns2="urn:ietf:params:xml:ns:sppf:base:1"
    xmlns:ns3="urn:ietf:params:xml:ns:sppf:soap:1">
    <serverTransId>tx_12354</serverTransId>
    <overallResult>
     <code>1000</code>
     <msg>Request Succeeded.</msg>
    </overallResult>
   </ns3:spppDelResponse>
  </S:Body>
 </S:Envelope>

Cartwright, et al. Standards Track [Page 74] RFC 7878 SPP Protocol over SOAP August 2016

10.21. Delete SED Group Offers Request

 SSP2 no longer wants to share SED Group SED_GRP_SSP2_1 with SSP1.
 <?xml version="1.0" encoding="UTF-8"?>
 <soapenv:Envelope
  xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
  xmlns:urn="urn:ietf:params:xml:ns:sppf:soap:1"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <soapenv:Header/>
  <soapenv:Body>
   <urn:spppDelRequest>
     <!--1 or more repetitions:-->
    <objKey xsi:type="urn:SedGrpOfferKeyType">
     <sedGrpKey>
      <rant>iana-en:222</rant>
      <name>SED_GRP_SSP2_1</name>
      <type>SedGrp</type>
     </sedGrpKey>
     <offeredTo>iana-en:111</offeredTo>
    </objKey>
   </urn:spppDelRequest>
  </soapenv:Body>
 </soapenv:Envelope>
 The Registry completes the request successfully and returns a
 favorable response.  Restoring this resource sharing will require a
 new SED Group Offer from SSP2 to SSP1 followed by a successful SED
 Group Accept request from SSP1.
 <?xml version="1.0" encoding="UTF-8"?>
 <S:Envelope
  xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
  <S:Body>
   <ns3:spppDelResponse
    xmlns:ns2="urn:ietf:params:xml:ns:sppf:base:1"
    xmlns:ns3="urn:ietf:params:xml:ns:sppf:soap:1">
    <serverTransId>tx_12354</serverTransId>
    <overallResult>
     <code>1000</code>
     <msg>Request Succeeded.</msg>
    </overallResult>
   </ns3:spppDelResponse>
  </S:Body>
 </S:Envelope>

Cartwright, et al. Standards Track [Page 75] RFC 7878 SPP Protocol over SOAP August 2016

10.22. Delete Egress Route

 SSP1 decides to remove the Egress Route with the label EGR_RTE_01.
 <?xml version="1.0" encoding="UTF-8"?>
 <soapenv:Envelope
  xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
  xmlns:urn="urn:ietf:params:xml:ns:sppf:soap:1"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <soapenv:Header/>
  <soapenv:Body>
   <urn:spppDelRequest>
    <!--1 or more repetitions:-->
    <objKey xsi:type="urn:ObjKeyType">
     <rant>iana-en:111</rant>
     <name>EGR_RTE_01</name>
     <type>EgrRte</type>
    </objKey>
   </urn:spppDelRequest>
  </soapenv:Body>
 </soapenv:Envelope>
 The Registry completes the request successfully and returns a
 favorable response.
 <?xml version="1.0" encoding="UTF-8"?>
 <S:Envelope
  xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
  <S:Body>
   <ns3:spppDelResponse
    xmlns:ns2="urn:ietf:params:xml:ns:sppf:base:1"
    xmlns:ns3="urn:ietf:params:xml:ns:sppf:soap:1">
    <serverTransId>tx_12354</serverTransId>
    <overallResult>
     <code>1000</code>
     <msg>Request Succeeded.</msg>
    </overallResult>
   </ns3:spppDelResponse>
  </S:Body>
 </S:Envelope>

Cartwright, et al. Standards Track [Page 76] RFC 7878 SPP Protocol over SOAP August 2016

10.23. Batch Request

 Following is an example of how some of the operations mentioned in
 previous sections MAY be performed by an SPPF client as a batch in
 one single SPPP over SOAP request.
 In the sample request below, SSP1 wants to accept a SED Group Offer
 from SSP3, add a Destination Group, add a Naming Authority Pointer
 (NAPTR) SED Record, add a SED Group, add a SED Group Offer, delete a
 previously provisioned TN type Public Identifier, delete a previously
 provisioned SED Group, and reject a SED Group Offer from SSP4.
 <?xml version="1.0" encoding="UTF-8"?>
 <soapenv:Envelope
  xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
  xmlns:urn="urn:ietf:params:xml:ns:sppf:soap:1"
  xmlns:urn1="urn:ietf:params:xml:ns:sppf:base:1"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <soapenv:Header/>
  <soapenv:Body>
   <urn:spppBatchRequest>
    <clientTransId>txn_1467</clientTransId>
    <minorVer>1</minorVer>
    <acceptSedGrpOffer>
     <sedGrpKey>
      <rant>iana-en:225</rant>
      <name>SED_SSP3_SBE1_Offered</name>
      <type>SedGrp</type>
     </sedGrpKey>
     <offeredTo>iana-en:222</offeredTo>
    </acceptSedGrpOffer>
    <addObj xsi:type="urn1:DestGrpType">
     <urn1:rant>iana-en:222</urn1:rant>
     <urn1:rar>iana-en:223</urn1:rar>
     <urn1:dgName>DEST_GRP_SSP2_1</urn1:dgName>
    </addObj>
    <addObj xsi:type="urn1:NAPTRType">
     <urn1:rant>iana-en:222</urn1:rant>
     <urn1:rar>iana-en:223</urn1:rar>
     <urn1:sedName>SED_SSP2_SBE2</urn1:sedName>
     <urn1:order>10</urn1:order>
     <urn1:flags>u</urn1:flags>
     <urn1:svcs>E2U+sip</urn1:svcs>

Cartwright, et al. Standards Track [Page 77] RFC 7878 SPP Protocol over SOAP August 2016

     <urn1:regx>
      <urn1:ere>^(.*)$</urn1:ere>
      <urn1:repl>sip:\1@sbe2.ssp2.example.com</urn1:repl>
     </urn1:regx>
    </addObj>
    <addObj xsi:type="urn1:SedGrpType">
     <urn1:rant>iana-en:222</urn1:rant>
     <urn1:rar>iana-en:223</urn1:rar>
     <urn1:sedGrpName>SED_GRP_SSP2_1</urn1:sedGrpName>
     <urn1:sedRecRef>
      <urn1:sedKey xsi:type="urn:ObjKeyType">
       <rant>iana-en:222</rant>
       <name>SED_SSP2_SBE2</name>
       <type>SedRec</type>
      </urn1:sedKey>
     <urn1:priority>100</urn1:priority>
     </urn1:sedRecRef>
      <urn1:dgName>DEST_GRP_SSP2_1</urn1:dgName>
      <urn1:isInSvc>true</urn1:isInSvc>
      <urn1:priority>10</urn1:priority>
    </addObj>
    <addObj xsi:type="urn1:SedGrpOfferType">
     <urn1:rant>iana-en:222</urn1:rant>
     <urn1:rar>iana-en:223</urn1:rar>
     <urn1:sedGrpOfferKey xsi:type="urn:SedGrpOfferKeyType">
      <sedGrpKey xsi:type="urn:ObjKeyType">
       <rant>iana-en:222</rant>
       <name>SED_GRP_SSP2_1</name>
       <type>SedGrp</type>
      </sedGrpKey>
      <offeredTo>iana-en:111</offeredTo>
     </urn1:sedGrpOfferKey>
     <urn1:status>offered</urn1:status>
     <urn1:offerDateTime>
      2006-05-04T18:13:51.0Z
     </urn1:offerDateTime>
    </addObj>
    <delObj xsi:type="urn:PubIdKeyType">
     <rant>iana-en:222</rant>
     <number>
      <urn1:value>+12025556666</urn1:value>
      <urn1:type>TN</urn1:type>
     </number>
    </delObj>

Cartwright, et al. Standards Track [Page 78] RFC 7878 SPP Protocol over SOAP August 2016

    <delObj xsi:type="urn:ObjKeyType">
     <rant>iana-en:222</rant>
     <name>SED_GRP_SSP2_Previous</name>
     <type>SedGrp</type>
    </delObj>
    <rejectSedGrpOffer>
     <sedGrpKey>
      <rant>iana-en:226</rant>
      <name>SED_SSP4_SBE1_Offered</name>
      <type>SedGrp</type>
     </sedGrpKey>
     <offeredTo>iana-en:222</offeredTo>
    </rejectSedGrpOffer>
   </urn:spppBatchRequest>
  </soapenv:Body>
 </soapenv:Envelope>
 The Registry completes the request successfully and returns a
 favorable response.
 <?xml version="1.0" encoding="UTF-8"?>
 <S:Envelope
  xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
  <S:Body>
   <ns3:spppBatchResponse
    xmlns:ns2="urn:ietf:params:xml:ns:sppf:base:1"
    xmlns:ns3="urn:ietf:params:xml:ns:sppf:soap:1">
    <serverTransId>tx_12354</serverTransId>
    <overallResult>
     <code>1000</code>
     <msg>Request Succeeded.</msg>
    </overallResult>
   </ns3:spppBatchResponse>
  </S:Body>
 </S:Envelope>

Cartwright, et al. Standards Track [Page 79] RFC 7878 SPP Protocol over SOAP August 2016

11. Security Considerations

 The base security considerations of SPPP outlined in Section 9 of
 [RFC7877] also apply to SPPP over SOAP implementations.
 Additionally, the following must be considered:
 SPPP over SOAP is used to query and update session peering data and
 addresses, so the ability to access this protocol should be limited
 to users and systems that are authorized to query and update this
 data.  Because this data is sent in both directions, it may not be
 sufficient for just the client or user to be authenticated with the
 server.  The identity of the server should also be authenticated by
 the client, which is often accomplished using the TLS certificate
 exchange and validation described in [RFC2818].

11.1. Vulnerabilities

 Section 5 describes the use of HTTP and TLS as the underlying
 substrate protocols for SPPP over SOAP.  These underlying protocols
 may have various vulnerabilities, and these may be inherited by SPPP
 over SOAP.  SPPP over SOAP itself may have vulnerabilities because an
 authorization model is not explicitly specified in this document.
 During a TLS handshake, TLS servers can optionally request a
 certificate from a TLS client; that option is not a requirement for
 this protocol.  This presents a denial-of-service risk in which
 unauthenticated clients can consume server CPU resources by creating
 TLS sessions.  The risk is increased if the server supports client-
 initiated renegotiation.  This risk can be mitigated by disabling
 client-initiated renegotiation on the server and by ensuring that
 other means (such as firewall access control lists) are used to
 restrict unauthenticated client access to servers.
 In conjunction with the above, it is important that SPPP over SOAP
 implementations implement an authorization model that considers the
 source of each query or update request and determines whether it is
 reasonable to authorize that source to perform that specific query or
 update.

Cartwright, et al. Standards Track [Page 80] RFC 7878 SPP Protocol over SOAP August 2016

12. IANA Considerations

 This document uses URNs to describe XML Namespaces and XML Schemas.
 According to [RFC3688], IANA has performed the following URN
 assignment:
    URN: urn:ietf:params:xml:ns:sppf:soap:1
    Registrant Contact: IESG
    XML: See Section 9 of [RFC7878]

13. References

13.1. Normative References

 [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
            Requirement Levels", BCP 14, RFC 2119,
            DOI 10.17487/RFC2119, March 1997,
            <http://www.rfc-editor.org/info/rfc2119>.
 [RFC3688]  Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
            DOI 10.17487/RFC3688, January 2004,
            <http://www.rfc-editor.org/info/rfc3688>.
 [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
            (TLS) Protocol Version 1.2", RFC 5246,
            DOI 10.17487/RFC5246, August 2008,
            <http://www.rfc-editor.org/info/rfc5246>.
 [RFC7230]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
            Protocol (HTTP/1.1): Message Syntax and Routing",
            RFC 7230, DOI 10.17487/RFC7230, June 2014,
            <http://www.rfc-editor.org/info/rfc7230>.
 [RFC7231]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
            Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
            DOI 10.17487/RFC7231, June 2014,
            <http://www.rfc-editor.org/info/rfc7231>.
 [RFC7235]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
            Protocol (HTTP/1.1): Authentication", RFC 7235,
            DOI 10.17487/RFC7235, June 2014,
            <http://www.rfc-editor.org/info/rfc7235>.

Cartwright, et al. Standards Track [Page 81] RFC 7878 SPP Protocol over SOAP August 2016

 [RFC7525]  Sheffer, Y., Holz, R., and P. Saint-Andre,
            "Recommendations for Secure Use of Transport Layer
            Security (TLS) and Datagram Transport Layer Security
            (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
            2015, <http://www.rfc-editor.org/info/rfc7525>.
 [RFC7877]  Cartwright, K., Bhatia, V., Ali, S., and D. Schwartz,
            "Session Peering Provisioning Framework (SPPF)", RFC 7877,
            DOI 10.17487/RFC7877, August 2016,
            <http://www.rfc-editor.org/info/rfc7877>.
 [SOAPREF]  Gudgin, M., Hadley, M., Moreau, J., and H. Nielsen, "SOAP
            Version 1.2 Part 1: Messaging Framework (Second Edition)",
            W3C Recommendation REC-SOAP12-part1-20070427, April 2007,
            <http://www.w3.org/TR/soap12-part1/>.

13.2. Informative References

 [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,
            DOI 10.17487/RFC5321, October 2008,
            <http://www.rfc-editor.org/info/rfc5321>.
 [W3C.REC-xml-20081126]
            Sperberg-McQueen, C., Yergeau, F., Bray, T., Maler, E.,
            and J. Paoli, "Extensible Markup Language (XML) 1.0 (Fifth
            Edition)", W3C Recommendation REC-xml-20081126, November
            2008, <http://www.w3.org/TR/2008/REC-xml-20081126>.
 [WSDLREF]  Christensen, E., Curbera, F., Meredith, G., and S.
            Weerawarana, "Web Services Description Language (WSDL)
            1.1", W3C Note NOTE-wsdl-20010315, March 2001,
            <http://www.w3.org/TR/2001/NOTE-wsdl-20010315>.

Acknowledgements

 This document is a result of various discussions held with the IETF
 DRINKS working group, specifically the protocol design team, with
 contributions from the following individuals, in alphabetical order:
 Syed Ali, Vikas Bhatia, Kenneth Cartwright, Sumanth Channabasappa,
 Lisa Dusseault, Deborah A.  Guyton, Scott Hollenbeck, Otmar Lendl,
 Manjul Maharishi, Mickael Marrache, Alexander Mayrhofer, Samuel
 Melloul, Jean-Francois Mule, Peter Saint-Andre, David Schwartz, and
 Richard Shockey.

Cartwright, et al. Standards Track [Page 82] RFC 7878 SPP Protocol over SOAP August 2016

Authors' Addresses

 Kenneth Cartwright
 TNS
 10740 Parkridge Boulevard
 Reston, VA  20191
 United States
 Email: kcartwright@tnsi.com
 Vikas Bhatia
 TNS
 10740 Parkridge Boulevard
 Reston, VA  20191
 United States
 Email: vbhatia@tnsi.com
 Jean-Francois Mule
 Apple Inc.
 1 Infinite Loop
 Cupertino, CA  95014
 United States
 Email: jfmule@apple.com
 Alexander Mayrhofer
 nic.at GmbH
 Karlsplatz 1/2/9
 Wien  A-1010
 Austria
 Email: alexander.mayrhofer@nic.at

Cartwright, et al. Standards Track [Page 83]

/data/webs/external/dokuwiki/data/pages/rfc/rfc7878.txt · Last modified: 2016/08/17 21:26 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki