Session Peering Provisioning (SPP) Protocol over SOAP
Extracted elements (29)
A 'Generic WSDL' design was chosen: one WSDL structure per operation type rather than per object type, reducing the number of WSDL operations while keeping each operation's input/output structures self-contained.
SOAP and HTTP(S) were chosen as the substrate for SPPF because SPPF clients integrate with back-office provisioning systems and communicate across organizational boundaries over the Internet; SOAP/HTTP(S) leverage existing expertise and ease migration of existing provisioning systems.
SOAP faults are explicitly not used by SPPP over SOAP; all success and error conditions are conveyed through the structured overallResult and detailResult elements, though client applications should still handle SOAP faults that may arise from lower-level SOAP library failures.
The 'Document/Literal Wrapped' WSDL style was chosen because it enhances maintainability, comprehension, portability, and performance; it uses soapAction binding style 'document', encoding 'literal', and wraps all inputs/outputs in a single data element.
HTTP 1.1 persistent connections SHOULD be used as an important performance optimization, particularly when connections are HTTPS where the TLS handshake overhead is significant; multiple request/response pairs can share a single connection.
Use of WSDL versions greater than 1.1 may introduce interoperability problems with implementations that use WSDL 1.1; implementations SHOULD use WSDL 1.1 and MUST NOT use earlier versions.
Any instance of PubIdKeyType MUST contain exactly one element from the set: 'number', 'range', or 'uri'; these are mutually exclusive choices for identifying a Public Identifier.
Conforming SPPP over SOAP clients and servers MUST support TLS as defined in RFC 5246, and use of TLS MUST follow the recommendations contained in RFC 7525.
Conforming SPPP SOAP servers MUST stop processing elements in any Add, Delete, Accept, Reject, or Batch request at the first error and roll back any elements already processed for that request ('stop and roll back').
Deployments MUST replace 'REPLACE_WITH_ACTUAL_URL' in the WSDL with the URI of the actual SPPF server instance.
Implementations compliant with this document MUST use HTTP 1.1 or higher. Implementations SHOULD use persistent connections to improve performance, particularly over TLS.
Implementations MUST use SOAP 1.2 or higher and MUST support SOAP 1.2. Implementations SHOULD use WSDL 1.1 and MUST NOT use earlier versions of WSDL.
The response message for result code 2001 ('Request too large') MUST use the parameterized form 'MaxSupported:[Maximum requests supported]' to indicate the server's maximum supported requests per operation.
The serverTransId element MUST be unique for a given SPPF server and must appear exactly once in every response to identify the request for tracking purposes.
The SPPF server MUST echo back the clientTransId value to the client in the corresponding response to each incoming request that includes it; the server will not check this value for uniqueness.
When conforming SPPP SOAP servers use language tagging, the XML 'lang' attribute (per W3C XML specification Section 2.12) MUST be used. Clients MAY use the HTTP Accept-Language header to indicate language preference.
When no objects match the query criteria in a Get request, the resultObj MUST be empty and the overallResult MUST indicate success; an empty result set is not an error condition.
SPPP over SOAP defines eight WSDL operations: submitAddRqst, submitDelRqst, submitAcceptRqst, submitRejectRqst, submitBatchRqst, submitGetRqst, submitGetSedGrpOffersRqst, and submitServerStatusRqst, each with a corresponding request and response message.
The Batch operation (spppBatchRequest/spppBatchResponse) allows an SPPF client to combine Add, Delete, Accept, and Reject operations in a single request, with per-operation result codes (addResult, delResult, acceptResult, rejectResult) in the response.
The Generic Object Key (ObjKeyType) uniquely identifies most SPPF objects using three fields: 'rant' (registrant organization ID), 'name' (object name string), and 'type' (enumeration: SedGrp, DestGrp, SedRec, or EgrRte).
The Get SED Group Offers operation (getSedGrpOffersRequest) allows flexible querying of SED Group Offer objects by filtering on offeredBy, offeredTo, status, and/or sedGrpOfferKey; if no criteria are passed, all offers belonging to the Registrant are returned.
The Get Server Details operation (spppServerStatusRequest/spppServerStatusResponse) returns the server status and the major/minor versions of SPPP over SOAP supported by the SPPF server via a SvcMenuType element.
The Public Identifier Object Key (PubIdKeyType) identifies TN, RN, TN Prefix, URI, or TN Range objects using a 'rant' field plus exactly one of: 'number' (NumberType), 'range' (NumberRangeType), or 'uri' (anyURI).
The SED Group Offer Key (SedGrpOfferKeyType) uniquely identifies a SED Group Offer using two fields: 'sedGrpKey' (an ObjKeyType identifying the SED Group) and 'offeredTo' (the organization ID of the offer recipient).
The protocol requires HTTP Digest Authentication for authentication, TLS (per RFC 5246 and RFC 7525 recommendations) for integrity and confidentiality, and notes that concerns regarding non-repudiation are beyond this document's scope and are addressed in the SPPF framework specification (RFC 7877).
Response codes follow a four-digit scheme: first digit 1 (positive) or 2 (negative); second digit indicates category: 0=Protocol Syntax, 1=Business Rule, 2=Security, 3=Server System; third and fourth digits identify the specific event within that category.
The minorVer element (type MinorVerType, zero or one occurrence) appears in all request structures; if absent, the server assumes the client is using the latest minor version it supports for the given major version.
The ObjKeyTypeEnum restricts the 'type' field of ObjKeyType to four enumerated token values: 'SedGrp', 'DestGrp', 'SedRec', and 'EgrRte', encoded as XML token type in the SOAP namespace 'urn:ietf:params:xml:ns:sppf:soap:1'.
The ResultCodeType structure contains a 'code' field (unsignedShort, enumerated values: 1000, 2000-2002, 2100-2103, 2300-2301) and a 'msg' field (token, 3-255 characters); this structure is used for both overallResult and within detail result types.