idnits 2.17.1 draft-ietf-drinks-spp-protocol-over-soap-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 30, 2012) is 4469 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-12) exists of draft-ietf-drinks-spp-framework-00 ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 2617 (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) -- Possible downref: Non-RFC (?) normative reference: ref. 'SOAPREF' -- Obsolete informational reference (is this intentional?): RFC 2818 (Obsoleted by RFC 9110) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DRINKS K. Cartwright 3 Internet-Draft V. Bhatia 4 Intended status: Standards Track TNS 5 Expires: August 2, 2012 January 30, 2012 7 Session Peering Provisioning (SPP) Protocol over SOAP 8 draft-ietf-drinks-spp-protocol-over-soap-00 10 Abstract 12 The Session Peering Provisioning Framework (SPPF) is an XML framework 13 that exists to enable the provisioning of session establishment data 14 into Session Data Registries or SIP Service Provider data stores. 15 Sending XML data structures over Simple Object Access Protocol (SOAP) 16 and HTTP(s) is a widely used, de-facto standard for messaging between 17 elements of provisioning systems. Therefore the combination of SOAP 18 and HTTP(s) as a transport protocol for SPPF is a natural fit. The 19 obvious benefits include leveraging existing industry expertise, 20 leveraging existing standards, and a higher probability that existing 21 provisioning systems can be more easily integrated with this 22 protocol. This document describes the specification for transporting 23 SPPF XML structures over SOAP and HTTP(s). 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on August 2, 2012. 42 Copyright Notice 44 Copyright (c) 2012 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 3. SOAP Features and Protocol Layering . . . . . . . . . . . . . 6 62 4. HTTP(s) Features and SPPF . . . . . . . . . . . . . . . . . . 9 63 5. Authentication and Session Management . . . . . . . . . . . . 10 64 6. SPP Protocol SOAP Data Structures . . . . . . . . . . . . . . 11 65 6.1. Concrete Object Key Types . . . . . . . . . . . . . . . . 11 66 6.1.1. Generic Object Key . . . . . . . . . . . . . . . . . . 11 67 6.1.2. Public Identity Object Key . . . . . . . . . . . . . . 12 68 6.1.3. Route Group Offer Key . . . . . . . . . . . . . . . . 13 69 6.2. Operation Request and Response Structures . . . . . . . . 13 70 6.2.1. Add Operation Structure . . . . . . . . . . . . . . . 14 71 6.2.2. Delete Operation Structure . . . . . . . . . . . . . . 17 72 6.2.3. Accept Operation Structure . . . . . . . . . . . . . . 20 73 6.2.4. Reject Operation Structure . . . . . . . . . . . . . . 23 74 6.2.5. Batch Operation Structure . . . . . . . . . . . . . . 26 75 6.2.6. Get Operation Structure . . . . . . . . . . . . . . . 29 76 6.2.7. Get Route Group Offers Operation Structure . . . . . . 31 77 6.2.8. Generic Query Response . . . . . . . . . . . . . . . . 32 78 6.2.9. Get Server Details Operation Structure . . . . . . . . 33 79 6.3. Response Codes and Messages . . . . . . . . . . . . . . . 35 80 7. Protocol Operations . . . . . . . . . . . . . . . . . . . . . 37 81 8. SPPF SOAP WSDL Definition . . . . . . . . . . . . . . . . . . 38 82 9. SPP Protocol over SOAP Examples . . . . . . . . . . . . . . . 49 83 9.1. Add Destination Group . . . . . . . . . . . . . . . . . . 49 84 9.2. Add Route Records . . . . . . . . . . . . . . . . . . . . 51 85 9.3. Add Route Records -- URIType . . . . . . . . . . . . . . . 52 86 9.4. Add Route Group . . . . . . . . . . . . . . . . . . . . . 53 87 9.5. Add Public Identity -- Successful COR claim . . . . . . . 55 88 9.6. Add LRN . . . . . . . . . . . . . . . . . . . . . . . . . 57 89 9.7. Add TN Range . . . . . . . . . . . . . . . . . . . . . . . 58 90 9.8. Add TN Prefix . . . . . . . . . . . . . . . . . . . . . . 59 91 9.9. Enable Peering -- Route Group Offer . . . . . . . . . . . 60 92 9.10. Enable Peering -- Route Group Offer Accept . . . . . . . . 62 93 9.11. Add Egress Route . . . . . . . . . . . . . . . . . . . . . 63 94 9.12. Remove Peering -- Route Group Offer Reject . . . . . . . . 65 95 9.13. Get Destination Group . . . . . . . . . . . . . . . . . . 66 96 9.14. Get Public Identity . . . . . . . . . . . . . . . . . . . 68 97 9.15. Get Route Group Request . . . . . . . . . . . . . . . . . 69 98 9.16. Get Route Group Offers Request . . . . . . . . . . . . . . 71 99 9.17. Get Egress Route . . . . . . . . . . . . . . . . . . . . . 73 100 9.18. Delete Destination Group . . . . . . . . . . . . . . . . . 74 101 9.19. Delete Public Identity . . . . . . . . . . . . . . . . . . 75 102 9.20. Delete Route Group Request . . . . . . . . . . . . . . . . 77 103 9.21. Delete Route Group Offers Request . . . . . . . . . . . . 78 104 9.22. Delete Egress Route . . . . . . . . . . . . . . . . . . . 79 105 9.23. Batch Request . . . . . . . . . . . . . . . . . . . . . . 80 106 10. Security Considerations . . . . . . . . . . . . . . . . . . . 83 107 10.1. Integrity, Privacy, and Authentication . . . . . . . . . . 83 108 10.2. Vulnerabilities . . . . . . . . . . . . . . . . . . . . . 83 109 10.3. Deployment Environment Specifics . . . . . . . . . . . . . 83 110 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 84 111 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 85 112 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 86 113 13.1. Normative References . . . . . . . . . . . . . . . . . . . 86 114 13.2. Informative References . . . . . . . . . . . . . . . . . . 86 115 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 87 117 1. Introduction 119 SPPF, defined in [I-D.draft-ietf-drinks-spp-framework], is best 120 supported by a transport and messaging infrastructure that is 121 connection oriented, request-response oriented, easily secured, 122 supports propagation through firewalls in a standard fashion, and 123 that is easily integrated into back-office systems. This is due to 124 the fact that the client side of SPPF is likely to be integrated with 125 organizations' operational support systems that facilitate 126 transactional provisioning of user addresses and their associated 127 session establishment data. While the server side of SPPF is likely 128 to reside in a separate organization's network, resulting the SPPF 129 provisioning transactions traversing the Internet as they are 130 propagated from the SPPF client to the SPPF server. Given the 131 current state of industry practice and technologies, SOAP and HTTP(s) 132 are well suited for this type of environment. This document 133 describes the specification for transporting SPPF XML structures over 134 SOAP and HTTP(s). 136 The specification in this document for transporting SPPF XML 137 structures over SOAP and HTTP(s) is primarily comprised of five 138 subjects: (1) a description of any applicable SOAP features, (2) any 139 applicable HTTP features, (3) security considerations, and perhaps 140 most importantly, (4) the Web Services Description Language (WSDL) 141 definition for SPP Protocol over SOAP, and (5) "transport" specific 142 XML schema type definitions 144 2. Terminology 146 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 147 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 148 document are to be interpreted as described in [RFC2119]. 150 3. SOAP Features and Protocol Layering 152 The list of SOAP features that are explicitly used and required for 153 SPP Protocol over SOAP are limited. Most SOAP features are not 154 necessary for SPPF. SPP Protocol over SOAP primarily uses SOAP 155 simply as a standard message envelope technology. The SOAP message 156 envelope is comprised of the SOAP header and body. As described in 157 the SOAP specifications, the SOAP header can contain optional, 158 application specific, information about the message. The SOAP body 159 contains the SPPF message itself, whose structure is defined by the 160 combination of one of the WSDL operations defined in this document 161 and the SPPF XML data structures defined in this document and the 162 SPPF document. SPPF does not rely on any data elements in the SOAP 163 header. All relevant data elements are defined in the SPPF XML 164 schema described in [I-D.draft-ietf-drinks-spp-framework] and the 165 SPPF WSDL types specification described in this document. 167 WSDL is a widely standardized and adopted technology for defining the 168 top-level structures of the messages that are transported within the 169 body of a SOAP message. The WSDL definition for the SPPF SOAP 170 messages is defined later in this document, which imports by 171 reference the XML data types contained in the SPPF schema. The IANA 172 registry where the SPPF schema resides is described in The IETF XML 173 Registry [RFC3688]. 175 There are multiple structural styles that SOAP WSDL allows. But the 176 best practice for this type of application is what is sometimes 177 referred to as the Document Literal Wrapped style of designing SOAP 178 WSDL. This style is generally regarded as an optimal approach that 179 enhances maintainability, comprehension, portability, and, to a 180 certain extent, performance. It is characterized by setting the 181 soapAction binding style as _document_, the soapAction encoding style 182 as _literal_, and then defining the SOAP messages to simply contain a 183 single data element that _wraps_ a data structure containing all the 184 required input or output data elements. The figure below illustrates 185 this high level technical structure as conceptual layers 3 through 6. 187 +-------------+ 188 (1) | Transport |Example: 189 | Protocol | TCP, TLS, BEEP, etc. 190 +-------------+ 191 | 192 V 193 +-------------+ 194 (2) | Message |Example: 195 | Envelope | HTTP, SOAP, None, etc. 196 +-------------+ 197 | 198 V 199 +--------------+ 200 +------| SOAP |-----+ 201 | (3) | Operation | | 202 Contains | +--------------+ | Contains 203 | Example: | 204 V submitAddRqst V 205 +--------------+ +-------------+ 206 |SOAP Request | |SOAP Response| 207 Example:| Message | (4) | Message | Example: 208 spppAdd | (Operation | | (Operation | spppAdd 209 RequestMsg | Input) | | Output) | ResponseMsg 210 +--------------+ +-------------+ 211 | | 212 Contains | | Contains 213 | | 214 V V 215 +---------------+ +---------------+ 216 Example:| Wrapped | (5) | Wrapped | Example: 217 spppAdd |Request Object | |Response Object| spppAdd 218 Request +---------------+ +---------------+ Response 219 | | 220 Contains | | Contains 221 | | 222 V V 223 +-------------+ +---------------+ 224 | SPPF | | SPPF | 225 |XML Types | (6) | XML Types | 226 +-------------+ +---------------+ 228 Figure 1: Layering and Technical Structure of the SPP Protocol over 229 SOAP Messages 231 The operations supported by SPP Protocol over SOAP are normatively 232 defined later in this document. Each SOAP operation defines a 233 request/input message and a response/output message. Each such 234 request and response message then contains a single object that wraps 235 the SPPF XML data types that comprise the inputs and the outputs, 236 respectively, of the SOAP operation. 238 SOAP faults are not used by the SPP Protocol over SOAP. All success 239 and error responses are specified in the "Response Codes and 240 Messages" section of this document. However, if a SOAP fault were to 241 occur, perhaps due to failures in the SOAP message handling layer of 242 a SOAP library, the client application should capture and handle the 243 fault. Specifics on how to handle such SOAP faults, if they should 244 occur, will be specific to the chosen SOAP implementation. 246 SOAP 1.2 [SOAPREF] or higher and WSDL 1.1 [WSDLREF] or higher SHOULD 247 be used. 249 SPPF is a request/reply framework that allows a client application to 250 submit provisioning data and query requests to a server. The SPPF 251 data structures are designed to be protocol agnostic. Concerns 252 regarding encryption, non-repudiation, and authentication are beyond 253 the scope of this document. For more details, please refer to the 254 "Transport Protocol Requirements" section in the framework document. 256 As illustrated in the previous diagram, SPPF can be viewed as a set 257 of layers that collectively define the structure of an SPPF request 258 and response. Layers 1 and 2 represent the transport, envelope, and 259 authentication technologies. This document defines layers 3, 4, 5, 260 and 6 below for SPP Protocol over SOAP. 262 1. Layer 1: The transport protocol layer represents the 263 communication mechanism between the client and server. SPPF can 264 be layered over any transport protocol that provides a set of 265 basic requirements defined in the Transport Protocol Requirements 266 section. But this document specifies the required mechanism. 268 2. Layer 2: The message envelope layer is optional, but can provide 269 features that are above the transport technology layer but below 270 the application messaging layer. Technologies such as HTTP and 271 SOAP are examples of messaging envelope technologies. This 272 document specifies the required envelope technology. 274 3. Layers 3,4,5,6: The operation and message layers provides an 275 envelope-independent and transport-independent wrapper for the 276 SPPF data model objects that are being acted on (created, 277 modified, queried). 279 4. HTTP(s) Features and SPPF 281 SOAP is not tied to HTTP(s), however, for reasons described in the 282 introduction, HTTP(s) is a good choice as the transport mechanism for 283 the SPP Protocol SOAP messages. HTTP 1.1 includes the "persistent 284 connection" feature, which allows multiple HTTP request/response 285 pairs to be transported across a single HTTP connection. This is an 286 important performance optimization feature, particularly when the 287 connections is an HTTPS connection where the relatively time 288 consuming SSL handshake has occurred. Persistent connections SHOULD 289 be used for the SPPF HTTP connections. 291 HTTP 1.1 [RFC2616] or higher SHOULD be used. 293 5. Authentication and Session Management 295 To achieve integrity and privacy, conforming SPP Protocol SOAP 296 Clients and Servers MUST support SOAP over HTTP over TLS [RFC5246] as 297 the secure transport mechanism. This combination of HTTP and TLS is 298 referred to as HTTPS. And to accomplish authentication, conforming 299 SOAP SPPF Clients and Servers MUST use HTTP Digest Authentication as 300 defined in [RFC2617]. As a result, the communication session is 301 established through the initial HTTP connection setup, the digest 302 authentication, and the TLS handshake. When the HTTP connection is 303 broken down, the communication session ends. 305 6. SPP Protocol SOAP Data Structures 307 SPP Protocol over SOAP uses a set of XML based data structures for 308 all the supported operations and any parameters that those operations 309 are applied to. As also mentioned earlier in this document, these 310 XML structures are envelope-independent and transport-independent. 311 Refer the "Protocol Operations" section of this document for a 312 description of all the operations that MUST be supported. 314 The following sections describe the definition all the XML data 315 structures. 317 6.1. Concrete Object Key Types 319 Certain operations in SPPF require an object key that uniquely 320 identifies the object(s) on which a given operation needs to be 321 performed. SPPF defines the XML structure of the any such object key 322 in an abstact manner and delegates the concrete represenation to any 323 conforming transport protocol. The following sub-sections define the 324 various types of concrete object key types used in various operations 325 in SPP Protocol over SOAP: 327 6.1.1. Generic Object Key 329 Most objects in SPP Protocol over SOAP are unqiuely identified by the 330 attributes in the concrete ObjKeyType. The XML representation of 331 ObjKeyType is as below: 333 334 335 336 337 338 339 340 341 342 343 345 The ObjKeyType has the data elements as described below: 347 o rant: The identifier of the registrant organization that owns 348 the object. 350 o name: The character string that contains the name of the object. 352 o type: The enumeration vaue that represents the type of SPPF 353 object. 355 6.1.2. Public Identity Object Key 357 Public Identity type objects can further be of various sub-types like 358 a TN, RN, TN Prefix, or a TN Range and cannot be cleanly identified 359 with the attributes in the generic ObjKeyType. The definition of 360 PubIdKeyType is as below: 362 363 364 365 366 367 368 369 371 373 374 375 376 377 379 The PubIdKeyType has the data elements as described below: 381 o rant: The identifier of the registrant organization that owns 382 the object. 384 o dgName: The name of the Destination Group that a Public 385 Identifier is member of. Note that this is an optional 386 attribute of the key as Public Identifiers may or may not be 387 provisioned as members of a Destination Group. 389 o number: An element of type NumberType (refer framework document) 390 that contains the value and type of a the number . 392 o range: An element of type NumberRangeType (refer framework 393 document) that contains a rage of numbers. 395 It is MUST that only one of the "number" and "range" elements appears 396 in a PubIdKeyType instance. 398 6.1.3. Route Group Offer Key 400 In addition to the attributes in the generic ObjKeyType, a Route 401 Group Offer object is uniquely identified by the organization ID of 402 the organization to whom an Route Group has been offered. The 403 definition of RteGrpOfferKeyType is as below: 405 406 407 408 409 410 411 412 413 414 416 The RteGrpOfferKeyType has the data elements as described below: 418 o rteGrpKey: Identifies the Route Group that was offered. 420 o offeredTo: The organization ID of the organization that was 421 offered the Route Group object identified by the rteGrpKey. 423 6.2. Operation Request and Response Structures 425 An SPPF client interacts with an SPPF server by using one of the 426 supported transport mechanisms to send one or more requests to the 427 server and receive corresponding replies from the server. The basic 428 set of operations that an SPPF client can submit to an SPPF server 429 and the semantics of those operations are defined in the "Framework 430 Operations" section of the framework document. The following sub- 431 sections describe the XML data structures that are used for each of 432 those types of operations for a SPP Protocol over SOAP 433 implementation. 435 6.2.1. Add Operation Structure 437 In order to add (or modify) an object in the registry, an authorized 438 entity can send the spppAddRequest to the registry. 440 An SPP Protocol over SOAP Add request is wrapped within the 441 element while an SPPF Add response is wrapped within 442 an element. The following sub-sections describe 443 the spppAddRequest and spppAddResponse elements. Refer the "SPPF 444 SOAP Examples" section of this document for an example of Add 445 operation on each type of SPPF object. 447 6.2.1.1. Add Request 449 An SPP Protocol over SOAP Add request definition is contained within 450 the generic element. 452 453 454 455 457 459 461 462 463 465 466 467 469 470 471 473 The data elements within the element are described 474 as follows: 476 o clientTransId: Zero or one client-generated transaction ID that, 477 within the context of the SPPF client, identifies this request. 478 This value can be used at the discretion of the SPPF client to 479 track, log or correlate requests and their responses. SPPF 480 server MUST echo back this value to the client in the 481 corresponding response to the incoming request. SPPF server 482 will not check this value for uniqueness. 484 o minorVer: Zero or one minor version identifier, indicating the 485 minor version of the SPPF API that the client is attempting to 486 use. This is used in conjunction with the major version 487 identifier in the XML namespace to identify the version of SPPF 488 that the client is using. If the element is not present, the 489 server assumes that the client is using the latest minor version 490 supported by the SPPF server for the given major version. The 491 versions supported by a given SPPF server can be retrieved by 492 the client using the SPPF server menu operation described later 493 in the document. 495 o obj: One or more elements of abstract type BasicObjType (defined 496 in the framework document). Each element contains all the 497 attributes of an SPPF object that that the client is requesting 498 the SPPF server to add. Refer the "Framework Data Model 499 Objects" section of the framework document for the XML structure 500 of all concrete types, for various SPPF objects, that extend 501 from abstract BasicObjType and hence are eligible to be passed 502 into this element. The elements are processed by the SPPF 503 server in the order in which they are included in the request. 504 With respect to handling of error conditions, it is a matter of 505 policy whether the objects are processed in a "stop and 506 rollback" fashion or in a "stop and commit" fashion. In the 507 "stop and rollback" scenario, the SPPF server would stop 508 processing BasicObjType elements in the request at the first 509 error and roll back any BasicObjType elements that had already 510 been processed for that add request. In the "stop and commit" 511 scenario the SPPF server would stop processing BasicObjType 512 elements in the request at the first error but commit any 513 BasicObjType elements that had already been processed for that 514 add request. 516 6.2.1.2. Add Response 518 An SPP Protocol over SOAP add response object is contained within the 519 generic element. This response structure is used 520 for all types of SPPF objects that are provisioned by the SPPF 521 client. 523 524 525 526 528 529 530 532 533 534 536 537 538 539 540 541 543 544 545 546 547 548 549 550 551 553 An contains the elements necessary for the SPPF 554 client to precisely determine the overall result of the request, and 555 if an error occurred, it provides information about the specific 556 object(s) that caused the error. 558 The data elements within the SPPF Add response are described as 559 follows: 561 o clientTransId: Zero or one client transaction ID. This value is 562 simply an echo of the client transaction ID that SPPF client 563 passed into the SPPF update request. When included in the 564 request, the SPPF server MUST return it in the corresponding 565 response message. 567 o serverTransId: Exactly one server transaction ID that identifies 568 this request for tracking purposes. This value MUST be unique 569 for a given SPPF server. 571 o overallResult: Exactly one response code and message pair that 572 explicitly identifies the result of the request. See the 573 Response Code section for further details. 575 o dtlResult: An optional response code, response message, and 576 BasicObjType (as defined in the framework document) triplet. 577 This element will be present only if an object level error has 578 occurred. It indicates the error condition and the exact 579 request object that contributed to the error. The response code 580 will reflect the exact error. See the Response Code section for 581 further details. 583 6.2.2. Delete Operation Structure 585 In order to remove an object from the registry, an authorized entity 586 can send the spppDelRequest into the registry. An SPP Protocol over 587 SOAP Del request is wrapped within the element while 588 a SPPF Del response is wrapped within the generic 589 element. The following sub-sections describe the spppDelRequest and 590 spppDelResponse elements. Refer the "SPPF SOAP Examples" section of 591 this document for an example of Delete operation on each type of SPPF 592 object. 594 6.2.2.1. Delete Request 596 An SPP Protocol over SOAP Del request definition is contained within 597 the generic element. 599 600 601 602 604 606 608 609 610 612 The data elements within the element are described 613 as follows: 615 o clientTransId: Zero or one client-generated transaction ID that, 616 within the context of the SPPF client, identifies this request. 617 This value can be used at the discretion of the SPPF client to 618 track, log or correlate requests and their responses. SPPF 619 server MUST echo back this value to the client in the 620 corresponding response to the incoming request. SPPF server 621 will not check this value for uniqueness. 623 o minorVer: Zero or one minor version identifier, indicating the 624 minor version of the SPPF API that the client is attempting to 625 use. This is used in conjunction with the major version 626 identifier in the XML namespace to identify the version of SPPF 627 that the client is using. If the element is not present, the 628 server assumes that the client is using the latest minor version 629 supported by the SPPF server for the given major version. The 630 versions supported by a given SPPF server can be retrieved by 631 the client using the SPPF server menu operation described later 632 in the document. 634 o objKey: One or more elements of abstract type ObjKeyType (as 635 defined in the framework document). Each element contains 636 attributes that uniquely identify the object that the client is 637 requesting the server to delete. Refer the "Concrete Object 638 Keys" section of this document for a description of all concrete 639 object key types, for various SPPF objects, which are eligible 640 to be passed into this element. The elements are processed by 641 the SPPF server in the order in which they are included in the 642 request. With respect to handling of error conditions, it is a 643 matter of policy whether the objects are processed in a "stop 644 and rollback" fashion or in a "stop and commit" fashion. In the 645 "stop and rollback" scenario, the SPPF server would stop 646 processing ObjKeyType elements in the request at the first error 647 and roll back any ObjKeyType elements that had already been 648 processed for that delete request. In the "stop and commit" 649 scenario the SPPF server would stop processing ObjKeyType 650 elements in the request at the first error but commit any 651 KeyParamType elements that had already been processed for that 652 delete request. 654 6.2.2.2. Delete Response 656 An SPP Protocol over SOAP delete response object is contained within 657 the generic element. This response structure is 658 used for a delete request on all types of SPPF objects that are 659 provisioned by the SPPF client. 661 662 663 664 666 667 668 670 671 672 674 675 676 677 678 679 681 682 683 684 685 686 687 688 689 691 An contains the elements necessary for the SPPF 692 client to precisely determine the overall result of the request, and 693 if an error occurred, it provides information about the specific 694 object key(s) that caused the error. 696 The data elements within the SPPF Delete response are described as 697 follows: 699 o clientTransId: Zero or one client transaction ID. This value is 700 simply an echo of the client transaction ID that SPPF client 701 passed into the SPPF update request. When included in the 702 request, the SPPF server MUST return it in the corresponding 703 response message. 705 o serverTransId: Exactly one server transaction ID that identifies 706 this request for tracking purposes. This value MUST be unique 707 for a given SPPF server. 709 o overallResult: Exactly one response code and message pair that 710 explicitly identifies the result of the request. See the 711 Response Code section for further details. 713 o dtlResult: An optional response code, response message, and 714 ObjKeyType (as defined in the framework document) triplet. This 715 element will be present only if an specific object key level 716 error has occurred. It indicates the error condition and the 717 exact request object key that contributed to the error. The 718 response code will reflect the exact error. See the Response 719 Code section for further details. 721 6.2.3. Accept Operation Structure 723 In SPPF, a Route Group Offer can be accepted or rejected by, or on 724 behalf of, the registrant to whom the Route Group has been offered 725 (refer "Framework Data Model Objects" section of the framework 726 document for a description of the Route Group Offer object). The 727 Accept operation is used to accept such Route Group Offers by, or on 728 behalf of, the Registrant. The request structure for an SPPF Accept 729 operation is wrapped within the element while an 730 SPPF Accept response is wrapped within the generic 731 element. The following sub-sections describe 732 the spppAcceptRequest and spppAcceptResponse elements. Refer the 733 "SPPF SOAP Examples" section of this document for an example of 734 Accept operation on a Route Group Offer. 736 6.2.3.1. Accept Request Structure 738 An SPP Protocol over SOAP Accept request definition is contained 739 within the generic element. 741 742 743 744 746 748 751 753 754 756 The data elements within the element are 757 described as follows: 759 o clientTransId: Zero or one client-generated transaction ID that, 760 within the context of the SPPF client, identifies this request. 761 This value can be used at the discretion of the SPPF client to 762 track, log or correlate requests and their responses. SPPF 763 server MUST echo back this value to the client in the 764 corresponding response to the incoming request. SPPF server 765 will not check this value for uniqueness. 767 o minorVer: Zero or one minor version identifier, indicating the 768 minor version of the SPPF API that the client is attempting to 769 use. This is used in conjunction with the major version 770 identifier in the XML namespace to identify the version of SPPF 771 that the client is using. If the element is not present, the 772 server assumes that the client is using the latest minor version 773 supported by the SPPF server for the given major version. The 774 versions supported by a given SPPF server can be retrieved by 775 the client using the SPPF server menu operation described later 776 in the document. 778 o rteGrpOfferKey: One or more elements of type RteGrpOfferKeyType 779 (as defined in this document). Each element contains attributes 780 that uniquely identify a Route Group Offer that the client is 781 requesting the server to accept. The elements are processed by 782 the SPPF server in the order in which they are included in the 783 request. With respect to handling of error conditions, it is a 784 matter of policy whether the objects are processed in a "stop 785 and rollback" fashion or in a "stop and commit" fashion. In the 786 "stop and rollback" scenario, the SPPF server would stop 787 processing RteGrpOfferKeyType elements in the request at the 788 first error and roll back any RteGrpOfferKeyType elements that 789 had already been processed for that accept request. In the 790 "stop and commit" scenario the SPPF server would stop processing 791 RteGrpOfferKeyType elements in the request at the first error 792 but commit any RteGrpOfferKeyType elements that had already been 793 processed for that accept request. 795 6.2.3.2. Accept Response 797 An SPP Protocol over SOAP accept response structure is contained 798 within the generic element. This response 799 structure is used for an Accept request on a Route Group Offer. 801 802 803 804 806 807 808 811 812 813 815 816 817 818 819 820 822 823 824 825 826 827 828 829 830 832 An contains the elements necessary for the SPPF 833 client to precisely determine the overall result of the request, and 834 if an error occurred, it provides information about the specific 835 Route Group Offer key(s) that caused the error. 837 The data elements within the SPPF Accept response are described as 838 follows: 840 o clientTransId: Zero or one client transaction ID. This value is 841 simply an echo of the client transaction ID that SPPF client 842 passed into the SPPF update request. When included in the 843 request, the SPPF server MUST return it in the corresponding 844 response message. 846 o serverTransId: Exactly one server transaction ID that identifies 847 this request for tracking purposes. This value MUST be unique 848 for a given SPPF server. 850 o overallResult: Exactly one response code and message pair that 851 explicitly identifies the result of the request. See the 852 Response Code section for further details. 854 o dtlResult: An optional response code, response message, and 855 RteGrpOfferKeyType (as defined in this document) triplet. This 856 element will be present only if any specific Route Group Offer 857 key level error has occurred. It indicates the error condition 858 and the exact request Route Group Offer key that contributed to 859 the error. The response code will reflect the exact error. See 860 the Response Code section for further details. 862 6.2.4. Reject Operation Structure 864 In SPPF, Route Group Offer can be accepted or rejected by, or on 865 behalf of, the registrant to whom the Route Group has been offered 866 (refer "Framework Data Model Objects" section of this document for a 867 description of the Route Group Offer object). The Reject operation 868 is used to reject such Route Group Offers by, or on behalf of, the 869 Registrant. The request structure for an SPPF Reject operation is 870 wrapped within the element while an SPPF Reject 871 response is wrapped within the generic element. 872 The following sub-sections describe the spppRejectRequest and 873 spppRejecResponse elements. Refer the "SPPF SOAP Examples" section 874 of this document for an example of Reject operation on a Route Group 875 Offer. 877 6.2.4.1. Reject Request 879 An SPP Protocol over SOAP Reject request definition is contained 880 within the generic element. 882 883 884 885 887 889 892 893 895 The data elements within the element are 896 described as follows: 898 o clientTransId: Zero or one client-generated transaction ID that, 899 within the context of the SPPF client, identifies this request. 900 This value can be used at the discretion of the SPPF client to 901 track, log or correlate requests and their responses. SPPF 902 server MUST echo back this value to the client in the 903 corresponding response to the incoming request. SPPF server 904 will not check this value for uniqueness. 906 o minorVer: Zero or one minor version identifier, indicating the 907 minor version of the SPPF API that the client is attempting to 908 use. This is used in conjunction with the major version 909 identifier in the XML namespace to identify the version of SPPF 910 that the client is using. If the element is not present, the 911 server assumes that the client is using the latest minor version 912 supported by the SPPF server for the given major version. The 913 versions supported by a given SPPF server can be retrieved by 914 the client using the SPPF server menu operation described later 915 in the document. 917 o rteGrpOfferKey: One or more elements of type RteGrpOfferKeyType 918 (as defined in this document). Each element contains attributes 919 that uniquely identify a Route Group Offer that the client is 920 requesting the server to reject. The elements are processed by 921 the SPPF server in the order in which they are included in the 922 request. With respect to handling of error conditions, it is a 923 matter of policy whether the objects are processed in a "stop 924 and rollback" fashion or in a "stop and commit" fashion. In the 925 "stop and rollback" scenario, the SPPF server would stop 926 processing RteGrpOfferKeyType elements in the request at the 927 first error and roll back any RteGrpOfferKeyType elements that 928 had already been processed for that reject request. In the 929 "stop and commit" scenario the SPPF server would stop processing 930 RteGrpOfferKeyType elements in the request at the first error 931 but commit any RteGrpOfferKeyType elements that had already been 932 processed for that reject request. 934 6.2.4.2. Reject Response 936 An SPP Protocol over SOAP reject response structure is contained 937 within the generic element. This response 938 structure is used for an Reject request on a Route Group Offer. 940 941 942 943 945 946 947 950 951 952 954 955 956 957 958 959 961 962 963 964 965 966 967 968 969 971 An contains the elements necessary for the SPPF 972 client to precisely determine the overall result of the request, and 973 if an error occurred, it provides information about the specific 974 Route Group Offer key(s) that caused the error. 976 The data elements within the SPPF Reject response are described as 977 follows: 979 o clientTransId: Zero or one client transaction ID. This value is 980 simply an echo of the client transaction ID that SPPF client 981 passed into the SPPF update request. When included in the 982 request, the SPPF server MUST return it in the corresponding 983 response message. 985 o serverTransId: Exactly one server transaction ID that identifies 986 this request for tracking purposes. This value MUST be unique 987 for a given SPPF server. 989 o overallResult: Exactly one response code and message pair that 990 explicitly identifies the result of the request. See the 991 Response Code section for further details. 993 o dtlResult: An optional response code, response message, and 994 RteGrpOfferKeyType (as defined in this document) triplet. This 995 element will be present only if any specific Route Group Offer 996 key level error has occurred. It indicates the error condition 997 and the exact request Route Group Offer key that contributed to 998 the error. The response code will reflect the exact error. See 999 the Response Code section for further details. 1001 6.2.5. Batch Operation Structure 1003 An SPP Protocol over SOAP Batch request XML structure allows the SPPF 1004 client to send any of of Add, Del, Accept or Reject operations 1005 together in one single request. This gives an SPPF Client the 1006 flexibility to use one single request structure to perform more than 1007 operations (verbs). The batch request structure is wrapped within 1008 the element while a SPPF Batch response is wrapped 1009 within the element. This following sub-sections 1010 describe the spppBatchRequest and spppBatchResponse elements. Refer 1011 the "SPPF SOAP Examples" section of this document for an example of a 1012 batch operation. 1014 6.2.5.1. Batch Request Structure 1016 An SPP Protocol over SOAP Batch request definition is contained 1017 within the generic element. 1019 1020 1021 1022 1024 1026 1027 1028 1029 1031 1033 1034 1035 1036 1038 The data elements within the element are described 1039 as follows: 1041 o clientTransId: Zero or one client-generated transaction ID that, 1042 within the context of the SPPF client, identifies this request. 1043 This value can be used at the discretion of the SPPF client to 1044 track, log or correlate requests and their responses. SPPF 1045 server MUST echo back this value to the client in the 1046 corresponding response to the incoming request. SPPF server 1047 will not check this value for uniqueness. 1049 o minorVer: Zero or one minor version identifier, indicating the 1050 minor version of the SPPF API that the client is attempting to 1051 use. This is used in conjunction with the major version 1052 identifier in the XML namespace to identify the version of SPPF 1053 that the client is using. If the element is not present, the 1054 server assumes that the client is using the latest minor version 1055 supported by the SPPF server for the given major version. The 1056 versions supported by a given SPPF server can be retrieved by 1057 the client using the SPPF server menu operation described later 1058 in the document. 1060 o addObj: One or more elements of abstract type BasicObjType where 1061 each element identifies an object that needs to be added. 1063 o delObj: One or more elements of abstract type ObjKeyType where 1064 each element identifies a key for the object that needs to be 1065 deleted . 1067 o acceptRteGrpOffer: One or more elements of type 1068 RteGrpOfferKeyType where each element identifies a Route Group 1069 Offer that needs to be accepted. 1071 o rejectRteGrpOffer: One or more elements of type 1072 RteGrpOfferKeyType where each element identifies a Route Group 1073 Offer that needs to be rejected. 1075 With respect to handling of error conditions, it is a matter of 1076 policy whether the batch operation processed in a "stop and rollback" 1077 fashion or in a "stop and commit" fashion. In the "stop and 1078 rollback" scenario, the SPPF server would stop processing elements in 1079 the request at the first error and roll back any elements that had 1080 already been processed for that batch request. In the "stop and 1081 commit" scenario the SPPF server would stop processing elements in 1082 the request at the first error but commit any elements that had 1083 already been processed for that batch request. 1085 6.2.5.2. Batch Response 1087 An SPP Protocol over SOAP batch response structure is contained 1088 within the generic element. This response 1089 structure is used for an Batch request that contains many different 1090 types of SPPF operations. 1092 1093 1094 1095 1097 1098 1099 1100 1102 1104 1106 1108 1109 1110 1111 1113 An contains the elements necessary for an SPPF 1114 client to precisely determine the overall result of various 1115 operations in the request, and if an error occurred, it provides 1116 information about the specific objects or keys in the request that 1117 caused the error. 1119 The data elements within the SPPF Batch response are described as 1120 follows: 1122 o clientTransId: Zero or one client transaction ID. This value is 1123 simply an echo of the client transaction ID that SPPF client 1124 passed into the SPPF update request. When included in the 1125 request, the SPPF server MUST return it in the corresponding 1126 response message. 1128 o serverTransId: Exactly one server transaction ID that identifies 1129 this request for tracking purposes. This value MUST be unique 1130 for a given SPPF server. 1132 o overallResult: Exactly one response code and message pair that 1133 explicitly identifies the result of the request. See the 1134 Response Code section for further details. 1136 o addResult: One or more elements of type ObjResultCodeType where 1137 each element identifies the result code, result message and the 1138 specific object that the result relates to. 1140 o delResult: One or more elements of type ObjKeyResultCodeType 1141 where each element identifies the result code, result message 1142 and the specific object key that the result relates to. 1144 o acceptResult: One or more elements of type 1145 RteGrpOfferKeyResultCodeType where each element identifies the 1146 result code, result message and the specific Route Group Offer 1147 key that the result relates to. 1149 o rejectResult: One or more elements of type 1150 RteGrpOfferKeyResultCodeType where each element identifies the 1151 result code, result message and the specific Route Group Offer 1152 key that the result relates to. 1154 6.2.6. Get Operation Structure 1156 In order to query the details of an object from the Registry, an 1157 authorized entity can send the spppGetRequest to the registry with a 1158 GetRqstType XML data structure containing one or more object keys 1159 that uniquely identify the object whose details are being queried. 1160 The request strcuture for an SPPF Get operation is contained within 1161 the generic element while an SPPF Get response is 1162 wrapped within the generic element. The following 1163 sub-sections describe the spppGetRequest and spppGetResponse element. 1164 Refer the examples section for an example of Get operation on each 1165 type of SPPF object 1167 6.2.6.1. Get Request 1169 1170 1171 1172 1174 1177 1178 1179 1181 The data elements within the element are described 1182 as follows: 1184 o minorVer: Zero or one minor version identifier, indicating the 1185 minor version of the SPPF API that the client is attempting to 1186 use. This is used in conjunction with the major version 1187 identifier in the XML namespace to identify the version of SPPF 1188 that the client is using. If the element is not present, the 1189 server assumes that the client is using the latest minor version 1190 supported by the SPPF server for the given major version. The 1191 versions supported by a given SPPF server can be retrieved by 1192 the client using the SPPF server menu operation described later 1193 in the document. 1195 o objKey: One or more elements of abstract type ObjKeyType (as 1196 defined in the framework document). Each element contains 1197 attributes that uniquely identify the object that the client is 1198 requesting the server to query. Refer the "Concrete Object 1199 Keys" section of this document for a description of all concrete 1200 object key types, for various SPPF objects, which are eligible 1201 to be passed into this element. 1203 6.2.6.2. Get Response 1205 The spppGetResponse element is described later in section titled 1206 "Generic Query Response". 1208 6.2.7. Get Route Group Offers Operation Structure 1210 In addition to the ability to query the details of one or more Route 1211 Group offers using an a Route Group Offer key in the spppGetRequest, 1212 this operation also provides an additonal, more flexible, structure 1213 to query for Route Group Offer objects. This additional structure is 1214 contained within the element while the 1215 response is wrapped within the generic element. 1216 The following sub-sections describe the getRteGrpOffersRequest and 1217 spppGetResponse elements. 1219 6.2.7.1. Get Route Group Offers Request 1221 Using the details passed into this structure, the server will attempt 1222 to find Route Group Offer objects that satisfy all the criteria 1223 passed into the request. If no criteria is passed in then the server 1224 will return the list of Route Group Offer objects that belongs to the 1225 registrant. If there are no matching Route Group Offers found then 1226 an empty result set will be returned. 1228 1229 1230 1231 1233 1235 1237 1239 1241 1242 1243 1245 The data elements within the element are 1246 described as follows: 1248 o minorVer: Zero or one minor version identifier, indicating the 1249 minor version of the SPPF API that the client is attempting to 1250 use. This is used in conjunction with the major version 1251 identifier in the XML namespace to identify the version of SPPF 1252 that the client is using. If the element is not present, the 1253 server assumes that the client is using the latest minor version 1254 supported by the SPPF server for the given major version. The 1255 versions supported by a given SPPF server can be retrieved by 1256 the client using the SPPF server menu operation described later 1257 in the document. 1259 o offeredBy: Zero or more organization IDs. Only offers that are 1260 offered to the organization IDs in this list should be included 1261 in the result set. The result set is also subject to other 1262 query criteria in the request. 1264 o offeredTo: Zero or more organization IDs. Only offers that are 1265 offered by the organization IDs in this list should be included 1266 in the result set. The result set is also subject to other 1267 query criteria in the request. 1269 o status: The status of the offer, offered or accepted. Only 1270 offers in the specified status should be included in the result 1271 set. If this element is not present then the status of the 1272 offer should not be considered in the query. The result set is 1273 also subject to other query criteria in the request. 1275 o rteGrpOfferKey: Zero or more Route Group Offer Keys. Only 1276 offers having one of these keys should be included in the result 1277 set. The result set is also subject to other query criteria in 1278 the request. 1280 6.2.7.2. Get Route Group Offers Response 1282 The spppGetResponse element is described later in section titled 1283 "Generic Query Response". 1285 6.2.8. Generic Query Response 1287 An SPP Protocol over SOAP query response object is contained within 1288 the generic element. 1290 1291 1292 1293 1295 1298 1299 1300 1302 An contains the elements necessary for the SPPF 1303 client to precisely determine the overall result of the query, and 1304 details of any SPPF objects that matched the criteria in the request. 1306 The data elements within the SPPF query response are described as 1307 follows: 1309 o overallResult: Exactly one response code and message pair that 1310 explicitly identifies the result of the request. See the 1311 Response Code section for further details. 1313 o resultObj: The set of zero or more objects that matched the 1314 query criteria. If no objects matched the query criteria then 1315 the result object(s) MUST be empty and the overallResult value 1316 MUST indicate success (if no matches are found for the query 1317 criteria, the response is considered a success). 1319 6.2.9. Get Server Details Operation Structure 1321 In order to query certain details of the SPPF server, like the SPPF 1322 server's status and the major/minor version supported by the server, 1323 the Server Details operation structure SHOULD be used. This 1324 structure is contained within the element 1325 while a SPPF server status response is wrapped within the 1326 element. This following sub-sections 1327 describe the spppServerStatusRequest and spppServerStatusResponse 1328 elements. 1330 6.2.9.1. Get Server Details Request 1331 1332 1333 1334 1336 1337 1338 1340 The data elements within the element are 1341 described as follows: 1343 o minorVer: Zero or one minor version identifier, indicating the 1344 minor version of the SPPF API that the client is attempting to 1345 use. This is used in conjunction with the major version 1346 identifier in the XML namespace to identify the version of SPPF 1347 that the client is using. If the element is not present, the 1348 server assumes that the client is using the latest minor version 1349 supported by the SPPF server for the given major version. The 1350 versions supported by a given SPPF server can be retrieved by 1351 the client using this same spppServerStatusRequest without 1352 passing in the minorVer element. 1354 6.2.9.2. Get Server Details Response 1356 An SPP Protocol over SOAP server details response structure is 1357 contained within the generic element. 1359 1360 1361 1362 1363 1364 1365 1366 1368 The data elements within the element are 1369 described as follows: 1371 o overallResult: Exactly one response code and message pair that 1372 explicitly identifies the result of the request. See the 1373 Response Code section for further details. 1375 o svcMenu: Exactly one element of type SvcMenuType which in turn 1376 contains the elements to return the server status and major/ 1377 minor version of the SPPF supported by the SPPF server (refer 1378 framework document for definition of SvcMenuType) . 1380 6.3. Response Codes and Messages 1382 This section contains the listing of response codes and their 1383 corresponding human-readable text. These response codes are in 1384 conformance with the response types defined in the section "Response 1385 Message Types" of the framework document. 1387 The response code numbering scheme generally adheres to the theory 1388 formalized in section 4.2.1 of [RFC5321]: 1390 o The first digit of the response code can only be 1 or 2: 1 = a 1391 positive result, 2 = a negative result. 1393 o The second digit of the response code indicates the category: 0 1394 = Protocol Syntax, 1 = Implementation Specific Business Rule, 2 1395 = Security, 3 = Server System. 1397 o The third and fourth digits of the response code indicate the 1398 individual message event within the category defines by the 1399 first two digits. 1401 The response codes are also categorized as to whether they are 1402 overall response codes that may only be returned in the 1403 "overallResult" data element in SPPF responses, or object level 1404 response codes that may only be returned in the "dtlResult" element 1405 of the SPPF responses. 1407 +--------+--------------------------+-------------------------------+ 1408 | Result | Result Message | Overall or Object Level | 1409 | Code | | | 1410 +--------+--------------------------+-------------------------------+ 1411 | 1000 | Request Succeeded. | Overall Response Code | 1412 | | | | 1413 | 2001 | Request syntax invalid. | Overall Response Code | 1414 | | | | 1415 | 2002 | Request too large. | Overall Response Code | 1416 | | | | 1417 | 2003 | Version not supported. | Overall Response Code | 1418 | | | | 1419 | 2103 | Command invalid. | Overall Response Code | 1420 | | | | 1421 | 2301 | System temporarily | Overall Response Code | 1422 | | unavailable. | | 1423 | | | | 1424 | 2302 | Unexpected internal | Overall Response Code | 1425 | | system or server error. | | 1426 | | | | 1427 | 2104 | Attribute value invalid. | Object Level Response Code | 1428 | | | | 1429 | | AttrName:[AttributeName] | | 1430 | | AttrVal:[AttributeValue] | | 1431 | | | | 1432 | 2105 | Object does not exist. | Object Level Response Code | 1433 | | AttrName:[AttributeName] | | 1434 | | AttrVal:[AttributeValue] | | 1435 | | | | 1436 | 2106 | Object status or | Object Level Response Code | 1437 | | ownership does not allow | | 1438 | | for operation. | | 1439 | | AttrName:[AttributeName] | | 1440 | | AttrVal:[AttributeValue] | | 1441 +--------+--------------------------+-------------------------------+ 1443 Table 1: Response Codes Numbering Scheme and Messages 1445 Each of the object level response messages are "parameterized" with 1446 the following parameters: "AttributeName" and "AttributeValue". 1448 The use of these parameters MUST adhere to the rules defined in 1449 "Response Message Types" section of the framework document. 1451 7. Protocol Operations 1453 Refer the "Framework Operations" section of the framework document 1454 for a description of all SPPF operations, and any necessary semantics 1455 that MUST be adhered to in order to conform with the SPPF 1456 specification. 1458 8. SPPF SOAP WSDL Definition 1460 The SPPF WSDL and data types are defined below. The WSDL design 1461 approach is commonly referred to as _Generic WSDL_. It is generic in 1462 the sense that there is not a specific WSDL operation defined for 1463 each object type that is supported by the SPPF protocol. There is a 1464 single WSDL structure for each type of SPPF operation. Each such 1465 WSDL structure contains exactly one input structure and one output 1466 structure that wraps any data elements that are part of the incoming 1467 request and the outgoing response respectively. The spppSOAPBinding 1468 in the WSDL defines the binding style as _document_ and the encoding 1469 as _literal_. It is this combination of _wrapped_ input and output 1470 data structures, _document_ binding style, and _literal_ encoding 1471 that characterize the Document Literal Wrapped style of WSDL 1472 specifications. 1474 Note: The following WSDL has been formatted (e.g., tabs, spaces) to 1475 meet I-D requirements. 1477 1478 1485 1486 1489 1490 1491 ---- Import base schema ---- 1492 1493 1494 1496 1497 1498 ---- Key type(s) extended 1499 from base schema. ---- 1500 1501 1502 1503 1504 1505 1506 1507 1508 1509 1510 1511 1512 1513 1514 1515 1516 1517 1519 1521 1522 1523 1524 1525 1526 1527 1528 1529 1530 1532 1533 1535 1537 1538 1539 1540 1541 1543 1544 1545 ---- Generic Request and 1546 Response Definitions ---- 1547 1548 1549 1550 1551 1552 1554 1556 1558 1559 1560 1561 1562 1563 1564 1566 1568 1570 1571 1572 1573 1574 1575 1576 1578 1580 1583 1584 1585 1586 1587 1588 1589 1591 1593 1596 1597 1598 1599 1600 1601 1602 1604 1607 1608 1609 1610 1611 1612 1613 1615 1617 1618 1619 1620 1622 1624 1625 1626 1627 1628 1629 1630 1631 1633 1634 1635 1636 1637 1638 1639 1641 1644 1646 1648 1651 1652 1653 1654 1655 1656 1657 1659 1661 1663 1666 1667 1668 1669 1670 1671 1672 1674 1676 1678 1681 1682 1683 1684 1685 1686 1687 1689 1691 1693 1697 1698 1699 1700 1701 1702 1703 1705 1707 1709 1712 1713 1714 1715 1716 1717 1718 1720 1722 1724 1725 1727 1729 1731 1733 1734 1735 1736 1737 1738 1739 1740 1742 1746 1747 1748 1749 1750 1751 1752 1754 1756 1757 1758 1759 1760 1761 ---- Operation Result Type 1762 Definitions ---- 1763 1764 1765 1766 1767 1768 1769 1770 1771 1772 1773 1774 1775 1776 1777 1778 1779 1780 1781 1782 1783 1784 1785 1786 1787 1788 1789 1790 1791 1792 1793 1795 1796 1797 1798 1799 1800 1801 1802 1803 1804 1805 1806 1807 1808 1809 1810 1811 1812 1813 1814 1815 1816 1817 1818 1819 1820 1821 1822 1823 1824 1825 1826 1827 1828 1829 1830 1831 1832 1833 1834 1835 1836 1837 1838 1839 1840 1841 1843 1844 1845 1846 1847 1848 1849 1850 1851 1852 1853 1854 1855 1856 1857 1858 1859 1860 1861 1862 1863 1864 1865 1866 1867 1868 1869 1870 1871 1872 1873 1874 1875 1876 1877 1878 1879 1880 1881 1882 1884 1885 1886 1887 1888 1889 1890 1892 1893 1894 1895 1896 1897 1898 1899 1900 1901 1902 1903 1904 1905 1906 1907 1908 1909 1910 1911 1912 1913 1914 1915 1916 1917 1918 1919 1920 1921 1922 1923 1924 1925 1926 1927 1928 1929 1930 1931 1932 1933 1934 1935 1936 1937 1938 1939 1940 1942 1943 1944 1945 1946 1947 1948 1949 1950 1952 1953 1954 1955 1956 1957 1958 1959 1960 1961 1962 1963 1964 1965 1967 Figure 2: WSDL 1969 9. SPP Protocol over SOAP Examples 1971 This section shows XML message exchange between two SIP Service 1972 Providers (SSP) and a registry. The messages in this section are 1973 valid XML instances that conform to the SPP Protocol over SOAP schema 1974 version within this document. This section relies on the XML data 1975 structures defined in the base SPPF specification 1976 [I-D.draft-ietf-drinks-spp-framework]. So refer to that document to 1977 understand XML object types embedded in these example messages. 1979 In this sample use case scenario, SSP1 and SSP2 provision resource 1980 data in the registry and use SPPF constructs to selectively share the 1981 route groups. In the figure below, SSP2 has two ingress SBE 1982 instances that are associated with the public identities that SSP2 1983 has the retail relationship with. Also, the two SBE instances for 1984 SSP1 are used to show how to use SPPF to associate route preferences 1985 for the destination ingress routes and exercise greater control on 1986 outbound traffic to the peer's ingress SBEs. 1988 ---------------+ +------------------ 1989 | | 1990 +------+ +------+ 1991 | sbe1 | | sbe2 | 1992 +------+ +------+ 1993 SSP1 | | SSP2 1994 +------+ +------+ 1995 | sbe3 | | sbe4 | 1996 +------+ +------+ 1997 iana-en:111 | | iana-en:222 1998 ---------------+ +------------------ 1999 | | 2000 | | 2001 | SPPF +------------------+ SPPF | 2002 +------->| Registry |<--------+ 2003 +------------------+ 2005 9.1. Add Destination Group 2007 SSP2 adds a destination group to the registry for use later. The 2008 SSP2 SPPF client sets a unique transaction identifier 'txn_1479' for 2009 tracking purposes. The name of the destination group is set to 2010 DEST_GRP_SSP2_1 2011 2012 2017 2018 2019 2020 2021 txn_1479 2022 2023 2024 iana-en:222 2025 iana-en:223 2026 DEST_GRP_SSP2_1 2027 2028 2029 2030 2032 The registry processes the request and return a favorable response 2033 confirming successful creation of the named destination group. Also, 2034 besides returning a unique server transaction identifier, Registry 2035 also returns the matching client transaction identifier from the 2036 request message back to the SPPF client. 2038 2039 2041 2042 2045 txn_1479 2046 tx_12345 2047 2048 1000 2049 Request Succeeded. 2050 2051 2052 2053 2055 9.2. Add Route Records 2057 SSP2 adds an ingress routes in the registry. 2059 2060 2065 2066 2067 2068 2069 txn_1479 2070 2071 2072 iana-en:222 2073 iana-en:223 2074 RTE_SSP2_SBE2 2075 10 2076 u 2077 E2U+sip 2078 2079 ^(.*)$ 2080 sip:\1@sbe2.ssp2.example.com 2081 2082 2083 2084 2085 2087 The registry returns a success response. 2089 2090 2092 2093 2096 txn_1479 2097 tx_12345 2098 2099 1000 2100 Request Succeeded. 2101 2102 2103 2104 2106 9.3. Add Route Records -- URIType 2108 SSP2 adds another ingress routes in the registry and makes use of 2109 URIType 2111 2112 2117 2118 2119 2120 txn_1479 2121 2122 2123 iana-en:222 2124 iana-en:223 2125 RTE_SSP2_SBE4 2126 ^(.*)$ 2127 sip:\1;npdi@sbe4.ssp2.example.com 2128 2129 2130 2131 2132 The registry returns a success response. 2134 2135 2136 2137 2140 txn_1479 2141 tx_12345 2142 2143 1000 2144 Request Succeeded. 2145 2146 2147 2148 2150 9.4. Add Route Group 2152 SSP2 creates the grouping of the ingress routes and choses higher 2153 precedence for RTE_SSP2_SBE2 by setting a lower number for the 2154 "priority" attribute, a protocol agnostic precedence indicator. 2156 2157 2162 2163 2164 2165 txn_1479 2166 2167 2168 iana-en:222 2169 iana-en:223 2170 RTE_GRP_SSP2_1 2171 2172 2173 iana-en:222 2174 RTE_SSP2_SBE2 2175 RteRec 2176 2177 100 2178 2179 DEST_GRP_SSP2_1 2180 true 2181 10 2182 2183 2184 2185 2187 To confirm successful processing of this request, registry returns a 2188 well-known result code '1000' to the SSP2 client. 2190 2191 2192 2193 2196 txn_1479 2197 tx_12345 2198 2199 1000 2200 Request Succeeded. 2201 2202 2203 2204 2206 9.5. Add Public Identity -- Successful COR claim 2208 SSP2 activates a TN public identity by associating it with a valid 2209 destination group. Further, SSP2 puts forth a claim that it is the 2210 carrier-of-record for the TN. 2212 2217 2218 2219 2220 txn_1479 2221 2222 2223 iana-en:222 2224 iana-en:223 2225 DEST_GRP_SSP2_1 2226 +12025556666 2227 2228 true 2229 2230 2231 2232 2233 2234 Assuming that the registry has access to TN authority data and it 2235 performs the required checks to verify that SSP2 is in fact the 2236 service provider of record for the given TN, the request is processed 2237 successfully. In the response message, the registry sets the value 2238 of to "true" in order to confirm SSP2 claim as the carrier of 2239 record and the reflects the time when the carrier of record 2240 claim is processed. 2242 2243 2246 2247 2250 txn_1479 2251 tx_12345 2252 2253 1000 2254 Request Succeeded. 2255 2256 2257 1000 2258 Request Succeeded. 2259 2260 iana-en:222 2261 iana-en:223 2262 2010-05-30T09:30:10Z 2263 DEST_GRP_SSP2_1 2264 +12025556666 2265 2266 true 2267 true 2268 2010-05-30T09:30:11Z 2269 2270 2271 2272 2273 2274 2276 9.6. Add LRN 2278 If another entity that SSP2 shares the routes with has access to 2279 Number Portability data, it may choose to perform route lookups by 2280 routing number. Therefore, SSP2 associates a routing number to a 2281 destination group in order to facilitate ingress route discovery. 2283 2284 2289 2290 2291 2292 txn_1479 2293 2294 2295 iana-en:222 2296 iana-en:223 2297 DEST_GRP_SSP2_1 2298 2025550000 2299 2300 2301 2302 2304 Registry completes the request successfully and returns a favorable 2305 response to the SPPF client. 2307 2308 2310 2311 2314 txn_1479 2315 tx_12345 2316 2317 1000 2318 Request Succeeded. 2319 2320 2321 2322 2324 9.7. Add TN Range 2326 Next, SSP2 activates a block of ten thousand TNs and associate it to 2327 a destination group. 2329 2330 2335 2336 2337 2338 txn_1479 2339 2340 2341 iana-en:222 2342 iana-en:223 2343 DEST_GRP_SSP2_1 2344 2345 +12026660000 2346 +12026669999 2347 2348 2349 2350 2351 2352 Registry completes the request successfully and returns a favorable 2353 response. 2355 2356 2358 2359 2362 txn_1479 2363 tx_12345 2364 2365 1000 2366 Request Succeeded. 2367 2368 2369 2370 2372 9.8. Add TN Prefix 2374 Next, SSP2 activates a block of ten thousand TNs using the TNPType 2375 structure and identifying a TN prefix. 2377 2378 2383 2384 2385 2386 txn_1479 2387 2388 2389 iana-en:222 2390 iana-en:223 2391 DEST_GRP_SSP2_1 2392 +1202777 2393 2394 2396 2397 2399 Registry completes the request successfully and returns a favorable 2400 response. 2402 2403 2405 2406 2409 txn_1479 2410 tx_12345 2411 2412 1000 2413 Request Succeeded. 2414 2415 2416 2417 2419 9.9. Enable Peering -- Route Group Offer 2421 In order for SSP1 to complete session establishment for a destination 2422 TN where the target subscriber has a retail relationship with SSP2, 2423 it first requires an asynchronous bi-directional handshake to show 2424 mutual consent. To start the process, SSP2 initiates the peering 2425 handshake by offering SSP1 access to its route group. 2427 2428 2433 2434 2435 2436 txn_1479 2437 2438 2439 iana-en:222 2440 iana-en:223 2441 2442 2443 iana-en:222 2444 RTE_GRP_SSP2_1 2445 RteGrp 2446 2447 iana-en:111 2448 2449 offered 2450 2451 2006-05-04T18:13:51.0Z 2452 2453 2454 2455 2456 2458 Registry completes the request successfully and confirms that the 2459 SSP1 will now have the opportunity to weigh in on the offer and 2460 either accept or reject it. The registry may employ out-of-band 2461 notification mechanisms for quicker updates to SSP1 so they can act 2462 faster, though this topic is beyond the scope of this document. 2464 2465 2467 2468 2471 txn_1479 2472 tx_12345 2473 2474 1000 2475 Request Succeeded. 2476 2477 2478 2479 2481 9.10. Enable Peering -- Route Group Offer Accept 2483 SSP1 responds to the offer from SSP2 and agrees to have visibility to 2484 SSP2 ingress routes. 2486 2487 2490 2491 2492 2493 2494 txn_1479 2495 2496 2497 2498 iana-en:222 2499 RTE_GRP_SSP2_1 2500 RteGrp 2501 2502 iana-en:111 2503 2504 2505 2506 2507 Registry confirms that the request has been processed successfully. 2508 From this point forward, if SSP1 looks up a public identity through 2509 the query resolution server, where the public identity is part of the 2510 destination group by way of "RTE_GRP_SSP2_1" route association, SSP2 2511 ingress SBE information will be shared with SSP1. 2513 2514 2516 2517 2520 txn_1479 2521 tx_12350 2522 2523 1000 2524 Request Succeeded. 2525 2526 2527 2528 2530 9.11. Add Egress Route 2532 SSP1 wants to prioritize all outbound traffic to routes associated 2533 with "RTE_GRP_SSP2_1" route group through "sbe1.ssp1.example.com". 2535 2536 2541 2542 2543 2544 txn_1479 2545 2546 2547 iana-en:222 2548 iana-en:223 2549 EGR_RTE_01 2550 50 2551 2552 ^(.*@)(.*)$ 2553 \1\2?route=sbe1.ssp1.example.com 2554 2555 2556 iana-en:222 2557 SSP2_RTE_REC_3 2558 RteRec 2559 2560 2561 2562 2563 2565 Since peering has already been established, the request to add the 2566 egress route has been successfully completed. 2568 2569 2571 2572 2575 txn_1479 2576 tx_12345 2577 2578 1000 2579 Request Succeeded. 2580 2581 2582 2583 2585 9.12. Remove Peering -- Route Group Offer Reject 2587 SSP1 had earlier accepted to have visibility to SSP2 ingress routes. 2588 SSP1 now decides to no more maintain this visiblity and hence rejects 2589 the Route Group Offer. 2591 2592 2595 2596 2597 2598 2599 txn_1479 2600 2601 2602 2603 iana-en:222 2604 RTE_GRP_SSP2_1 2605 RteGrp 2606 2607 iana-en:111 2608 2609 2610 2611 2612 Registry confirms that the request has been processed successfully. 2613 From this point forward, if SSP1 looks up a public identity through 2614 the query resolution server, where the public identity is part of the 2615 destination group by way of "RTE_GRP_SSP2_1" route association, SSP2 2616 ingress SBE information will NOT be shared with SSP1 and hence SSP2 2617 ingress SBE will NOT be returned in the query response. 2619 2620 2622 2623 2626 txn_1479 2627 tx_12350 2628 2629 1000 2630 Request Succeeded. 2631 2632 2633 2634 2636 9.13. Get Destination Group 2638 SSP2 uses the 'spppGetRequest' operation to tally the last 2639 provisioned record for destination group DEST_GRP_SSP2_1. 2641 2642 2646 2647 2648 2649 2650 2651 iana-en:222 2652 DEST_GRP_SSP2_1 2653 DestGrp 2654 2655 2656 2657 2659 Registry completes the request successfully and returns a favorable 2660 response. 2662 2663 2666 2667 2670 2671 1000 2672 success 2673 2674 2675 iana-en:222 2676 iana-en:223 2677 DEST_GRP_SSP2_1 2678 2679 2680 2681 2683 9.14. Get Public Identity 2685 SSP2 obtains the last provisioned record associated with a given TN. 2687 2688 2693 2694 2695 2696 2697 2698 iana-en:222 2699 2700 +12025556666 2701 TN 2702 2703 2704 2705 2706 2708 Registry completes the request successfully and returns a favorable 2709 response. 2711 2714 2715 2718 2719 1000 2720 success 2721 2722 2723 iana-en:222 2724 iana-en:223 2725 DEST_GRP_SSP2_1 2726 +12025556666 2727 2728 true 2729 true 2730 2010-05-30T09:30:10Z 2731 2732 2733 2734 2735 2737 9.15. Get Route Group Request 2739 SSP2 obtains the last provisioned record for the route group 2740 RTE_GRP_SSP2_1. 2742 2743 2747 2748 2749 2750 2751 2752 iana-en:222 2753 RTE_GRP_SSP2_1 2754 RteGrp 2755 2756 2757 2758 2760 Registry completes the request successfully and returns a favorable 2761 response. 2763 2764 2767 2768 2771 2772 1000 2773 success 2774 2775 2776 iana-en:222 2777 iana-en:223 2778 RTE_GRP_SSP2_1 2779 2780 2781 iana-en:222 2782 RTE_SSP2_SBE2 2783 RteRec 2784 2785 100 2786 2787 2788 2789 iana-en:222 2790 RTE_SSP2_SBE4 2791 RteRec 2792 2793 101 2794 2795 DEST_GRP_SSP2_1 2796 true 2797 10 2798 2799 2800 2801 2803 9.16. Get Route Group Offers Request 2805 SSP2 fetches the last provisioned route group offer to the 2806 SSP1. 2808 2809 2812 2813 2814 2815 iana-en:111 2816 2817 2818 2820 Registry processes the request successfully and returns a favorable 2821 response. 2823 2824 2827 2828 2831 2832 1000 2833 success 2834 2835 2836 iana-en:222 2837 iana-en:223 2838 2840 2841 iana-en:222 2842 RTE_GRP_SSP2_1 2843 RteGrp 2844 2845 iana-en:111 2846 2847 offered 2848 2849 2006-05-04T18:13:51.0Z 2850 2851 2852 2854 2855 2857 9.17. Get Egress Route 2859 SSP1 wants to verify the last provisioned record for the egress route 2860 called EGR_RTE_01. 2862 2863 2867 2868 2869 2870 2871 2872 iana-en:111 2873 EGR_RTE_01 2874 EgrRte 2875 2876 2877 2878 2880 Registry completes the request successfully and returns a favorable 2881 response. 2883 2884 2887 2888 2891 2892 1000 2893 success 2894 2895 2896 iana-en:222 2897 iana-en:223 2898 EGR_RTE_01 2899 50 2900 2901 ^(.*)$ 2902 sip:\1@sbe1.ssp1.example.com 2903 2904 2905 iana-en:222 2906 RTE_GRP_SSP2_1 2907 RteRec 2908 2909 2910 2911 2912 2914 9.18. Delete Destination Group 2916 SSP2 initiates a request to delete the destination group 2917 DEST_GRP_SSP2_1. 2919 2920 2924 2925 2926 2927 2928 2929 iana-en:222 2930 DEST_GRP_SSP2_1 2931 DestGrp 2932 2933 2934 2935 2937 Registry completes the request successfully and returns a favorable 2938 response. 2940 2941 2943 2944 2947 tx_12354 2948 2949 1000 2950 Request Succeeded. 2951 2952 2953 2954 2956 9.19. Delete Public Identity 2958 SSP2 choses to de-activate the TN and remove it from the registry. 2960 2961 2966 2967 2968 2969 2970 2971 iana-en:222 2972 DEST_GRP_SSP2_1 2973 2974 +12025556666 2975 TN 2976 2977 2978 2979 2980 2982 Registry completes the request successfully and returns a favorable 2983 response. 2985 2986 2988 2989 2992 tx_12354 2993 2994 1000 2995 Request Succeeded. 2996 2997 2998 2999 3001 9.20. Delete Route Group Request 3003 SSP2 removes the route group called RTE_GRP_SSP2_1. 3005 3006 3010 3011 3012 3013 3014 3015 iana-en:222 3016 RTE_GRP_SSP2_1 3017 RteGrp 3018 3019 3020 3021 3023 Registry completes the request successfully and returns a favorable 3024 response. 3026 3027 3029 3030 3033 tx_12354 3034 3035 1000 3036 Request Succeeded. 3037 3038 3039 3040 3042 9.21. Delete Route Group Offers Request 3044 SSP2 no longer wants to share route group RTE_GRP_SSP2_1 with SSP1. 3046 3047 3051 3052 3053 3054 3055 3056 3057 iana-en:222 3058 RTE_GRP_SSP2_1 3059 RteGrp 3060 3061 iana-en:111 3062 3063 3064 3065 3067 Registry completes the request successfully and returns a favorable 3068 response. Restoring this resource sharing will require a new route 3069 group offer from SSP2 to SSP1 followed by a successful route group 3070 accept request from SSP1. 3072 3073 3075 3076 3079 tx_12354 3080 3081 1000 3082 Request Succeeded. 3083 3084 3086 3087 3089 9.22. Delete Egress Route 3091 SSP1 decides to remove the egress route with the label EGR_RTE_01. 3093 3094 3098 3099 3100 3101 3102 3103 iana-en:111 3104 EGR_RTE_01 3105 EgrRte 3106 3107 3108 3109 3111 Registry completes the request successfully and returns a favorable 3112 response. 3114 3115 3117 3118 3121 tx_12354 3122 3123 1000 3124 Request Succeeded. 3125 3126 3127 3129 3131 9.23. Batch Request 3133 Following is an example of how some of the operations mentioned in 3134 previous sections MAY be performed by an SPPF client as a batch in 3135 one single SPP Protocol over SOAP request. 3137 In the sample request below SSP1 wants to accept a Route Group Offer 3138 from SSP3, add a Destination Group, add a NAPTR Route Rec, add a 3139 Route Group, add a Route Group Offer, delete a previously provisioned 3140 TN type Public Identifier, delete a previously provisioned Route 3141 Group, and reject a Route Group Offer from SSP4. 3143 3144 3149 3150 3151 3152 txn_1467 3153 1 3155 3156 3157 iana-en:225 3158 RTE_SSP3_SBE1_Offered 3159 RteGrp 3160 3161 iana-en:222 3162 3164 3165 iana-en:222 3166 iana-en:223 3167 DEST_GRP_SSP2_1 3168 3170 3171 iana-en:222 3172 iana-en:223 3173 RTE_SSP2_SBE2 3174 10 3175 u 3176 E2U+sip 3177 3178 ^(.*)$ 3179 sip:\1@sbe2.ssp2.example.com 3180 3181 3183 3184 iana-en:222 3185 iana-en:223 3186 RTE_GRP_SSP2_1 3187 3188 3189 iana-en:222 3190 RTE_SSP2_SBE2 3191 RteRec 3192 3193 100 3194 3195 DEST_GRP_SSP2_1 3196 true 3197 10 3198 3200 3201 iana-en:222 3202 iana-en:223 3203 3204 3205 iana-en:222 3206 RTE_GRP_SSP2_1 3207 RteGrp 3208 3209 iana-en:111 3210 3211 offered 3212 3213 2006-05-04T18:13:51.0Z 3214 3215 3217 3218 iana-en:222 3219 DEST_GRP_SSP2_Previous 3220 3221 +12025556666 3222 TN 3223 3224 3226 3227 iana-en:222 3228 RTE_GRP_SSP2_Previous 3229 RteGrp 3230 3232 3233 3234 iana-en:226 3235 RTE_SSP4_SBE1_Offered 3236 RteGrp 3237 3238 iana-en:222 3239 3241 3242 3243 3245 Registry completes the request successfully and returns a favorable 3246 response. 3248 3249 3251 3252 3255 tx_12354 3256 3257 1000 3258 Request Succeeded. 3259 3260 3261 3262 3264 10. Security Considerations 3266 SPPF is used to query and update session peering data and addresses, 3267 so the ability to access this protocol should be limited to users and 3268 systems that are authorized to query and update this data. Because 3269 this data is sent in both directions, it may not be sufficient for 3270 just the client or user to be authenticated with the server. The 3271 identity of the server should also be authenticated by the client, 3272 which is often accomplished using the TLS certificate exchange and 3273 validation described in [RFC2818]. SPPF data may include sensitive 3274 information, routing data, lists of resolvable addresses, etc. So 3275 when used in a production setting and across non-secure networks, 3276 SPPF should only be used over communications channels that provide 3277 strong encryption for data privacy. 3279 10.1. Integrity, Privacy, and Authentication 3281 The SPPF SOAP binding relies on an underlying secure transport for 3282 integrity and privacy. Such transports are expected to include TLS/ 3283 HTTPS. In addition to the application level authentication imposed 3284 by an SPPF server, there are a number of options for authentication 3285 within the transport layer and the messaging envelope. These include 3286 TLS client certificates, HTTP Digest Access Authentication, and 3287 digital signatures within SOAP headers. 3289 At a miniumum, all conforming SPP Protocol over SOAP implementations 3290 MUST support HTTPS. 3292 10.2. Vulnerabilities 3294 The above protocols may have various vulnerabilities, and these may 3295 be inherited by SPP Protocol over SOAP. And SPPF itself may have 3296 vulnerabilities because an authorization model is not explicitly 3297 specified in the current specification. 3299 It is important that SPPF implementations implement an authorization 3300 model that considers the source of each SPPF query or update request 3301 and determines whether it is reasonable to authorize that source to 3302 perform that specific query or update. 3304 10.3. Deployment Environment Specifics 3306 Some deployments of SPP Protocol over SOAP could choose to use 3307 transports without encryption. This presents vulnerabilities but 3308 could be selected for deployments involving closed networks or 3309 debugging scenarios. However, the vulnerabilities of such a 3310 deployment could be a lack of integrity and privacy of the data 3311 transported over SPPF messages in this type of deployment. 3313 11. IANA Considerations 3315 This document uses URNs to describe XML namespaces and XML schemas 3316 conforming to a registry mechanism described in [RFC3688]. 3318 URN assignments are requested: urn:ietf:params:xml:ns:sppf:soap 3320 12. Acknowledgements 3322 This document is a result of various discussions held by the DRINKS 3323 design team, which is comprised of the following individuals, in 3324 alphabetical order: Alexander Mayrhofer, David Schwartz, Deborah A 3325 Guyton, Jean-Francois Mule Kenneth Cartwright, Lisa Dusseault, Manjul 3326 Maharishi, Mickael Marrache, Otmar Lendl, Peter Saint-Andre, Richard 3327 Shockey, Samuel Melloul, Sumanth Channabasappa, Syed Ali, and Vikas 3328 Bhatia . 3330 13. References 3332 13.1. Normative References 3334 [I-D.draft-ietf-drinks-spp-framework] 3335 Mule, J-F., Cartwright, K., Ali, S., Mayrhofer, A., and V. 3336 Bhatia, "Session Peering Provisioning Framework", 3337 draft-ietf-drinks-spp-framework-00 (work in progress), 3338 January 2012. 3340 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3341 Requirement Levels", BCP 14, RFC 2119, March 1997. 3343 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 3344 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 3345 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 3347 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 3348 Leach, P., Luotonen, A., and L. Stewart, "HTTP 3349 Authentication: Basic and Digest Access Authentication", 3350 RFC 2617, June 1999. 3352 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 3353 January 2004. 3355 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 3356 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 3358 [SOAPREF] Gudgin, M., Hadley, M., Moreau, J., and H. Nielsen, "SOAP 3359 Version 1.2 Part 1: Messaging Framework", W3C 3360 Recommendation REC-SOAP12-part1-20030624, June 2002. 3362 13.2. Informative References 3364 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 3366 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 3367 October 2008. 3369 [WSDLREF] Christensen, E., Curbera, F., Meredith, G., and S. 3370 Weerawarana, "Web Services Description Language (WSDL) 3371 1.1", W3C Note NOTE-wsdl-20010315, March 2001. 3373 Authors' Addresses 3375 Kenneth Cartwright 3376 TNS 3377 1939 Roland Clarke Place 3378 Reston, VA 20191 3379 USA 3381 Email: kcartwright@tnsi.com 3383 Vikas Bhatia 3384 TNS 3385 1939 Roland Clarke Place 3386 Reston, VA 20191 3387 USA 3389 Email: vbhatia@tnsi.com