tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search     info

RFC 7878

Proposed STD
Pages: 83
Top     in Index     Prev     Next
in Group Index     Prev in Group     No Next: Highest Number in Group     Group: DRINKS

Session Peering Provisioning (SPP) Protocol over SOAP

Part 1 of 4, p. 1 to 22
None       Next Section

 


Top       ToC       Page 1 
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.

[Page 2] 
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

Top      ToC       Page 3 
     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

Top      ToC       Page 4 
   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.

Top      ToC       Page 5 
                                 +-------------+
                             (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

Top      ToC       Page 6 
   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).

Top      ToC       Page 7 
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.

Top      ToC       Page 8 
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".

Top      ToC       Page 9 
   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.

Top      ToC       Page 10 
   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.

Top      ToC       Page 11 
   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

Top      ToC       Page 12 
      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.

Top      ToC       Page 13 
   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.

Top      ToC       Page 14 
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").

Top      ToC       Page 15 
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.

Top      ToC       Page 16 
   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.

Top      ToC       Page 17 
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").

Top      ToC       Page 18 
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.

Top      ToC       Page 19 
   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.

Top      ToC       Page 20 
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").

Top      ToC       Page 21 
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.

Top      ToC       Page 22 
   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.



(page 22 continued on part 2)

Next Section