idnits 2.17.1 draft-ietf-drinks-spp-protocol-over-soap-09.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 (April 3, 2016) is 2945 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) == Missing Reference: 'THISDOCUMENT' is mentioned on line 3318, but not defined == Outdated reference: A later version (-12) exists of draft-ietf-drinks-spp-framework-08 ** Obsolete normative reference: RFC 2617 (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) ** Obsolete normative reference: RFC 7231 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 7525 (Obsoleted by RFC 9325) -- Possible downref: Non-RFC (?) normative reference: ref. 'SOAPREF' -- Obsolete informational reference (is this intentional?): RFC 2818 (Obsoleted by RFC 9110) Summary: 5 errors (**), 0 flaws (~~), 3 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: October 5, 2016 J-F. Mule 6 CableLabs 7 A. Mayrhofer 8 nic.at GmbH 9 April 3, 2016 11 Session Peering Provisioning (SPP) Protocol over SOAP 12 draft-ietf-drinks-spp-protocol-over-soap-09 14 Abstract 16 The Session Peering Provisioning Framework (SPPF) specifies the data 17 model and the overall structure to provision session establishment 18 data into Session Data Registries and SIP Service Provider data 19 stores. To utilize this framework one needs a substrate protocol. 20 Given that Simple Object Access Protocol (SOAP) is currently widely 21 used for messaging between elements of such provisioning systems, 22 this document specifies the usage of SOAP (via HTTPS) as the 23 substrate protocol for SPPF. The benefits include leveraging 24 prevalent expertise, and a higher probability that existing 25 provisioning systems will be able to easily migrate to using an SPPF 26 based protocol. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on October 5, 2016. 45 Copyright Notice 47 Copyright (c) 2016 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 3. SOAP Features and Protocol Layering . . . . . . . . . . . . . 4 65 4. HTTP(s) Features and SPP Protocol over SOAP . . . . . . . . . 7 66 5. Authentication, Integrity and Confidentiality . . . . . . . . 7 67 6. Language Identification . . . . . . . . . . . . . . . . . . . 7 68 7. SPP Protocol SOAP Data Structures . . . . . . . . . . . . . . 7 69 7.1. Concrete Object Key Types . . . . . . . . . . . . . . . . 8 70 7.1.1. Generic Object Key . . . . . . . . . . . . . . . . . 8 71 7.1.2. Public Identifier Object Key . . . . . . . . . . . . 9 72 7.1.3. SED Group Offer Key . . . . . . . . . . . . . . . . . 10 73 7.2. Operation Request and Response Structures . . . . . . . . 11 74 7.2.1. Add Operation Structure . . . . . . . . . . . . . . . 11 75 7.2.2. Delete Operation Structure . . . . . . . . . . . . . 14 76 7.2.3. Accept Operation Structure . . . . . . . . . . . . . 17 77 7.2.4. Reject Operation Structure . . . . . . . . . . . . . 20 78 7.2.5. Batch Operation Structure . . . . . . . . . . . . . . 23 79 7.2.6. Get Operation Structure . . . . . . . . . . . . . . . 26 80 7.2.7. Get SED Group Offers Operation Structure . . . . . . 27 81 7.2.8. Generic Query Response . . . . . . . . . . . . . . . 29 82 7.2.9. Get Server Details Operation Structure . . . . . . . 29 83 7.3. Response Codes and Messages . . . . . . . . . . . . . . . 31 84 7.4. Minor Version Identifier . . . . . . . . . . . . . . . . 33 85 8. Protocol Operations . . . . . . . . . . . . . . . . . . . . . 33 86 9. SPP Protocol over SOAP WSDL Definition . . . . . . . . . . . 33 87 10. SPP Protocol over SOAP Examples . . . . . . . . . . . . . . . 45 88 10.1. Add Destination Group . . . . . . . . . . . . . . . . . 45 89 10.2. Add SED Records . . . . . . . . . . . . . . . . . . . . 47 90 10.3. Add SED Records -- URIType . . . . . . . . . . . . . . . 48 91 10.4. Add SED Group . . . . . . . . . . . . . . . . . . . . . 49 92 10.5. Add Public Identifier -- Successful COR claim . . . . . 51 93 10.6. Add LRN . . . . . . . . . . . . . . . . . . . . . . . . 53 94 10.7. Add TN Range . . . . . . . . . . . . . . . . . . . . . . 54 95 10.8. Add TN Prefix . . . . . . . . . . . . . . . . . . . . . 55 96 10.9. Enable Peering -- SED Group Offer . . . . . . . . . . . 57 97 10.10. Enable Peering -- SED Group Offer Accept . . . . . . . . 58 98 10.11. Add Egress Route . . . . . . . . . . . . . . . . . . . . 59 99 10.12. Remove Peering -- SED Group Offer Reject . . . . . . . . 61 100 10.13. Get Destination Group . . . . . . . . . . . . . . . . . 62 101 10.14. Get Public Identifier . . . . . . . . . . . . . . . . . 64 102 10.15. Get SED Group Request . . . . . . . . . . . . . . . . . 65 103 10.16. Get SED Group Offers Request . . . . . . . . . . . . . . 67 104 10.17. Get Egress Route . . . . . . . . . . . . . . . . . . . . 69 105 10.18. Delete Destination Group . . . . . . . . . . . . . . . . 71 106 10.19. Delete Public Identifier . . . . . . . . . . . . . . . . 72 107 10.20. Delete SED Group Request . . . . . . . . . . . . . . . . 73 108 10.21. Delete SED Group Offers Request . . . . . . . . . . . . 74 109 10.22. Delete Egress Route . . . . . . . . . . . . . . . . . . 76 110 10.23. Batch Request . . . . . . . . . . . . . . . . . . . . . 77 111 11. Security Considerations . . . . . . . . . . . . . . . . . . . 79 112 11.1. Vulnerabilities . . . . . . . . . . . . . . . . . . . . 80 113 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 80 114 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 81 115 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 81 116 14.1. Normative References . . . . . . . . . . . . . . . . . . 81 117 14.2. Informative References . . . . . . . . . . . . . . . . . 82 118 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 82 120 1. Introduction 122 SPPF, defined in [I-D.draft-ietf-drinks-spp-framework], is best 123 supported by a transport and messaging infrastructure that is 124 connection oriented, request-response oriented, easily secured, 125 supports propagation through firewalls in a standard fashion, and 126 that is easily integrated into back-office systems. This is due to 127 the fact that the client side of SPPF is likely to be integrated with 128 organizations' operational support systems that facilitate 129 transactional provisioning of user addresses and their associated 130 session establishment data. While the server side of SPPF is likely 131 to reside in a separate organization's network, resulting in the SPPF 132 provisioning transactions traversing the Internet as they are 133 propagated from the SPPF client to the SPPF server. Given the 134 current state of industry practice and technologies, SOAP and HTTP(S) 135 are well suited for this type of environment. This document 136 describes the specification for transporting SPPF XML structures, 137 using SOAP and HTTP(S) as substrates. 139 The specification in this document for transporting SPPF XML 140 structures over SOAP and HTTP(s) is primarily comprised of five 141 subjects: (1) a description of any applicable SOAP features, (2) any 142 applicable HTTP features, (3) security considerations, and perhaps 143 most importantly, (4) the Web Services Description Language (WSDL) 144 definition for SPP Protocol over SOAP, and (5) "substrate" specific 145 XML Schema type definitions 147 2. Terminology 149 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 150 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 151 document are to be interpreted as described in [RFC2119]. 153 3. SOAP Features and Protocol Layering 155 The list of SOAP features that are explicitly used and required for 156 SPP Protocol over SOAP are limited. Most SOAP features are not 157 necessary for SPPF. SPP Protocol over SOAP primarily uses SOAP 158 simply as a standard message envelope technology. The SOAP message 159 envelope is comprised of the SOAP header and body. As described in 160 the SOAP specifications [SOAPREF], the SOAP header can contain 161 optional, application specific, information about the message. The 162 SOAP body contains the SPPF message itself, whose structure is 163 defined by the combination of one of the WSDL operations defined in 164 this document and the SPPF XML data structures defined in this 165 document and the SPPF document. SPPF does not rely on any data 166 elements in the SOAP header. All relevant data elements are defined 167 in the SPPF XML schema described in 168 [I-D.draft-ietf-drinks-spp-framework] and the SPPF WSDL types 169 specification described in this document and in 170 [I-D.draft-ietf-drinks-spp-framework]. 172 WSDL is a widely standardized and adopted technology for defining the 173 top-level structures of the messages that are transported within the 174 body of a SOAP message. The WSDL definition for the SPPF SOAP 175 messages is defined later in this document, which imports by 176 reference the XML data types contained in the SPPF schema. The IANA 177 registry where the SPPF schema resides is described in the IETF XML 178 Registry [RFC3688]. 180 There are multiple structural styles that WSDL allows. The best 181 practice for this type of application is what is sometimes referred 182 to as the "document/literal wrapped style". This style is generally 183 regarded as an optimal approach that enhances maintainability, 184 comprehension, portability, and, to a certain extent, performance. 185 It is characterized by setting the soapAction binding style as 186 "document", the soapAction encoding style as "literal", and then 187 defining the SOAP messages to simply contain a single data element 188 that "wraps" a data structure containing all the required input or 189 output data elements. The figure below illustrates this high level 190 technical structure as conceptual layers 3 through 6. 192 +-------------+ 193 (1) | Transport |Example: 194 | Protocol | TCP, TLS, BEEP, etc. 195 +-------------+ 196 | 197 V 198 +-------------+ 199 (2) | Message |Example: 200 | Envelope | HTTP, SOAP, None, etc. 201 +-------------+ 202 | 203 V 204 +--------------+ 205 +----| SOAP |---+ 206 |(3) | Operation | | 207 Contains | +--------------+ | Contains 208 | Example: | 209 V submitAddRqst V 210 +--------------+ +-------------+ 211 |SOAP Request | |SOAP Response| 212 Example: | Message | (4) | Message | Example: 213 spppAdd | (Operation | | (Operation | spppAdd 214 RequestMsg | Input) | | Output) | ResponseMsg 215 +--------------+ +-------------+ 216 | | 217 Contains | | Contains 218 | | 219 V V 220 +---------------+ +---------------+ 221 Example: | Wrapped | (5) | Wrapped | Example: 222 spppAdd |Request Object | |Response Object| spppAdd 223 Request +---------------+ +---------------+ Response 224 | | 225 Contains | | Contains 226 | | 227 V V 228 +-------------+ +---------------+ 229 | SPPF | | SPPF | 230 |XML Types | (6) | XML Types | 231 +-------------+ +---------------+ 233 Figure 1: Layering and Technical Structure of the SPP Protocol over 234 SOAP Messages 236 The operations supported by SPP Protocol over SOAP are normatively 237 defined later in this document. Each SOAP operation defines a 238 request/input message and a response/output message. Each such 239 request and response message then contains a single object that wraps 240 the SPPF XML data types that comprise the inputs and the outputs, 241 respectively, of the SOAP operation. 243 SOAP faults are not used by the SPP Protocol over SOAP. All success 244 and error responses are specified in Section 7.3 of this document. 245 However, if a SOAP fault were to occur, perhaps due to failures in 246 the SOAP message handling layer of a SOAP library, the client 247 application should capture and handle the fault. Specifics on how to 248 handle such SOAP faults, if they should occur, will be specific to 249 the chosen SOAP implementation. 251 Implementations MUST use SOAP 1.2 [SOAPREF] or higher, and MUST 252 support SOAP 1.2. Implementations SHOULD use WSDL 1.1 [WSDLREF], and 253 MUST NOT use earlier versions. Use of WSDL versions greater than 1.1 254 may introduce interopability problems with implementations that use 255 1.1. 257 SPPF is a request/reply framework that allows a client application to 258 submit provisioning data and query requests to a server. The SPPF 259 data structures are designed to be protocol agnostic. Concerns 260 regarding encryption, non-repudiation, and authentication are beyond 261 the scope of this document. For more details, please refer to 262 Section 4 ("Substrate Protocol Requirements") of 263 [I-D.draft-ietf-drinks-spp-framework]. 265 As illustrated in the previous diagram, SPPF can be viewed as a set 266 of layers that collectively define the structure of an SPPF request 267 and response. Layers 1 and 2 represent the transport, envelope, and 268 authentication technologies. This document defines layers 3, 4, 5, 269 and 6 for SPP Protocol over SOAP. 271 1. Layer 1: The transport protocol layer represents the 272 communication mechanism between the client and server. SPPF can 273 be layered over any substrate protocol that provides a set of 274 basic requirements defined in Section 4 of 275 [I-D.draft-ietf-drinks-spp-framework]. 277 2. Layer 2: The message envelope layer is optional, but can provide 278 features that are above the transport technology layer but below 279 the application messaging layer. Technologies such as HTTP and 280 SOAP are examples of messaging envelope technologies. 282 3. Layers 3,4,5,6: The operation and message layers provide an 283 envelope-independent and substrate-independent wrapper for the 284 SPPF data model objects that are being acted on (created, 285 modified, queried). 287 4. HTTP(s) Features and SPP Protocol over SOAP 289 While SOAP is not tied to HTTP(S), for reasons described in the 290 introduction, HTTP(S) is a good choice as the substrate protocol for 291 the SPP Protocol SOAP messages. HTTP 1.1 includes the "persistent 292 connection" feature, which allows multiple HTTP request/response 293 pairs to be transported across a single HTTP connection. This is an 294 important performance optimization feature, particularly when the 295 connections is an HTTPS connection where the relatively time 296 consuming TLS handshake has occurred. 298 Implementations compliant with this document MUST use HTTP 1.1 299 [RFC7230] or higher. Also, implementations SHOULD use persistent 300 connections. 302 5. Authentication, Integrity and Confidentiality 304 To accomplish authentication, conforming SPP Protocol over SOAP 305 Clients and Servers MUST use HTTP Digest Authentication as defined in 306 [RFC2617]. 308 To achieve integrity and privacy, conforming SPP Protocol over SOAP 309 Clients and Servers MUST support Transport Layer Security (TLS) as 310 defined in [RFC5246] as the secure transport mechanism. Use of TLS 311 MUST follow the recommendations contained in [RFC7525] 313 6. Language Identification 315 Section 9 of [I-D.draft-ietf-drinks-spp-framework] requires protocols 316 to provide a mechanism to transmit language tags together with human- 317 readable messages. When conforming SPP Protocol SOAP servers use 318 such tagging, the XML "lang" attribute ([W3C.REC-xml-20081126], 319 Section 2.12) MUST be used. Clients MAY use the HTTP "Accept- 320 Language" header field (see Section 5.3.5 of [RFC7231]) in order to 321 indicate their language preference. 323 7. SPP Protocol SOAP Data Structures 325 SPP Protocol over SOAP uses a set of XML based data structures for 326 all the supported operations and any parameters that those operations 327 are applied to. As also mentioned earlier in this document, these 328 XML structures are envelope-independent and substrate-independent. 329 Refer the "Protocol Operations" (Section 8) of this document for a 330 description of all the operations that MUST be supported. 332 The following sections describe the definition all the XML data 333 structures. 335 7.1. Concrete Object Key Types 337 Certain operations in SPPF require an object key that uniquely 338 identifies the object(s) on which a given operation needs to be 339 performed. SPPF defines the XML structure of the any such object key 340 in an abstract manner and delegates the concrete representation to 341 any conforming substrate protocol. The following sub-sections define 342 the various types of concrete object key types used in various 343 operations in SPP Protocol over SOAP. 345 7.1.1. Generic Object Key 347 Most objects in SPP Protocol over SOAP are uniquely identified by the 348 attributes in the generic object key (Refer Section 5.2.1 "Generic 349 Object Key Type" of [I-D.draft-ietf-drinks-spp-framework] for 350 details). The concrete XML representation of ObjKeyType is as below: 352 353 354 355 356 357 358 359 360 361 362 364 The ObjKeyType has the data elements as described below: 366 o rant: The identifier of the registrant organization that owns the 367 object. 369 o name: The character string that contains the name of the object. 371 o type: The enumeration value that represents the type of SPPF 372 object. For example, both a Destination Group and a SED Group can 373 have the same name "TestObj" and be associated with same 374 Registrant Id. Hence, to uniquely identify the object that 375 represents a Destination Group with the name "TestObj", the type 376 "DestGrp" must be specified when using this concrete ObjKeyType 377 structure to identify the Destination Group "TestObj". 379 The object types in SPP Protocol over SOAP MUST adhere to the above 380 definition of generic object key, and are defined as an enumeration 381 in the XML data structure as follows: 383 384 385 386 387 388 389 390 392 7.1.2. Public Identifier Object Key 394 Public Identifier type objects can further be of various sub-types 395 like a Telephone Number (TN), Routing Number (RN), TN Prefix, URI, or 396 a TN Range and cannot be cleanly identified with the attributes in 397 the generic ObjKeyType. The definition of PubIdKeyType is as below: 399 400 401 402 403 404 405 407 409 411 412 413 414 415 417 The PubIdKeyType has data elements, as described below: 419 o rant: The identifier of the registrant organization that owns the 420 object. 422 o number: An element of type NumberType (refer Section 12 of 423 [I-D.draft-ietf-drinks-spp-framework]) that contains the value and 424 type of a number . 426 o range: An element of type NumberRangeType (refer Section 12 of 427 [I-D.draft-ietf-drinks-spp-framework]) that contains a range of 428 numbers. 430 o uri: A value that represents a Public Identifier. 432 Any instance of PubIdKeyType MUST contain exactly one element from 433 the following set of elements: "number", "range", "uri". 435 7.1.3. SED Group Offer Key 437 In addition to the attributes in the generic ObjKeyType, a SED Group 438 Offer object is uniquely identified by the organization ID of the 439 organization to whom an SED Group has been offered. The definition 440 of SedGrpOfferKeyType is as below: 442 443 444 445 446 447 448 449 450 451 453 The SedGrpOfferKeyType has the data elements as described below: 455 o sedGrpKey: Identifies the SED Group that was offered. 457 o offeredTo: The organization ID of the organization that was 458 offered the SED Group object identified by the sedGrpKey. 460 7.2. Operation Request and Response Structures 462 An SPPF client interacts with an SPPF server by sending one or more 463 requests to the server, and by receiving corresponding responses from 464 the server. The basic set of operations that an SPPF client can 465 submit to an SPPF server and the semantics of those operations are 466 defined in Section 7 ("Framework Operations") of 467 [I-D.draft-ietf-drinks-spp-framework]. The following sub-sections 468 describe the XML data structures that are used for each of those 469 types of operations for a SPP Protocol over SOAP implementation. 471 7.2.1. Add Operation Structure 473 In order to add (or modify) an object in the registry, an authorized 474 entity can send the spppAddRequest to the registry. 476 An SPP Protocol over SOAP Add request is wrapped within the 477 element while an SPP Protocol over SOAP Add response 478 is wrapped within an element. The following sub- 479 sections describe the spppAddRequest and spppAddResponse elements. 480 Refer to Section 10 for an example of Add operation on each type of 481 SPPF object. 483 7.2.1.1. Add Request 485 An SPP Protocol over SOAP Add request definition is contained within 486 the generic element. 488 489 490 491 493 495 497 498 499 501 The data elements within the element are described 502 as follows: 504 o clientTransId: Zero or one client-generated transaction ID that, 505 within the context of the SPPF client, identifies this request. 506 This value can be used at the discretion of the SPPF client to 507 track, log or correlate requests and their responses. SPPF server 508 MUST echo back this value to the client in the corresponding 509 response to the incoming request. SPPF server will not check this 510 value for uniqueness. 512 o minorVer: Zero or one minor version identifier, as defined in 513 Section 7.4. 515 o obj: One or more elements of abstract type BasicObjType (defined 516 in [I-D.draft-ietf-drinks-spp-framework]). Each element contains 517 all the attributes of an SPPF object that that the client is 518 requesting the SPPF server to add. Refer to section 3.1 of 519 [I-D.draft-ietf-drinks-spp-framework] for the XML structure of all 520 concrete types, for various SPPF objects, that extend from 521 abstract BasicObjType and hence are eligible to be passed into 522 this element. The elements are processed by the SPPF server in 523 the order in which they are included in the request. With respect 524 to handling of error conditions, conforming SPPP SOAP servers MUST 525 stop processing BasicObjType elements in the request at the first 526 error, and roll back any BasicObjType elements that had already 527 been processed for that add request ("stop and rollback"). 529 7.2.1.2. Add Response 531 An SPP Protocol over SOAP add response object is contained within the 532 generic element. This response structure is used 533 for all types of SPPF objects that are provisioned by the SPPF 534 client. 536 537 538 539 541 542 543 545 546 547 549 550 551 552 553 554 556 557 558 559 560 561 562 563 564 566 An contains the elements necessary for the SPPF 567 client to precisely determine the overall result of the request, and 568 if an error occurred, it provides information about the specific 569 object(s) that caused the error. 571 The data elements within the SPP Protocol over SOAP Add response are 572 described as follows: 574 o clientTransId: Zero or one client transaction ID. This value is 575 simply an echo of the client transaction ID that SPPF client 576 passed into the SPPF update request. When included in the 577 request, the SPPF server MUST return it in the corresponding 578 response message. 580 o serverTransId: Exactly one server transaction ID that identifies 581 this request for tracking purposes. This value MUST be unique for 582 a given SPPF server. 584 o overallResult: Exactly one response code and message pair that 585 explicitly identifies the result of the request. See Section 7.3 586 for further details. 588 o detailResult: An optional response code, response message, and 589 BasicObjType (as defined in [I-D.draft-ietf-drinks-spp-framework]) 590 triplet. This element will be present only if an object level 591 error has occurred. It indicates the error condition and the 592 exact request object that contributed to the error. The response 593 code will reflect the exact error. See Section 7.3 for further 594 details. 596 7.2.2. Delete Operation Structure 598 In order to remove an object from the registry, an authorized entity 599 can send the spppDelRequest into the registry. An SPP Protocol over 600 SOAP Delete request is wrapped within the element 601 while a SPP Protocol over SOAP Delete response is wrapped within the 602 generic element. The following sub-sections 603 describe the spppDelRequest and spppDelResponse elements. Refer to 604 Section 10 for an example of Delete operation on each type of SPPF 605 object. 607 7.2.2.1. Delete Request 609 An SPP Protocol over SOAP Delete request definition is contained 610 within the generic element. 612 613 614 615 617 619 621 622 623 625 The data elements within the element are described 626 as follows: 628 o clientTransId: Zero or one client-generated transaction ID that, 629 within the context of the SPPF client, identifies this request. 630 This value can be used at the discretion of the SPPF client to 631 track, log or correlate requests and their responses. SPPF server 632 MUST echo back this value to the client in the corresponding 633 response to the incoming request. SPPF server will not check this 634 value for uniqueness. 636 o minorVer: Zero or one minor version identifier, as defined in 637 Section 7.4. 639 o objKey: One or more elements of abstract type ObjKeyType (as 640 defined in [I-D.draft-ietf-drinks-spp-framework]). Each element 641 contains attributes that uniquely identify the object that the 642 client is requesting the server to delete. Refer to Section 7.1 643 for a description of all concrete object key types, for various 644 SPPF objects, which are eligible to be passed into this element. 645 The elements are processed by the SPPF server in the order in 646 which they are included in the request. With respect to handling 647 of error conditions, conforming SPPP SOAP servers MUST stop 648 processing ObjKeyType elements in the request at the first error, 649 and roll back any ObjKeyType elements that had already been 650 processed for that delete request ("stop and rollback"). 652 7.2.2.2. Delete Response 654 An SPP Protocol over SOAP delete response object is contained within 655 the generic element. This response structure is 656 used for a delete request on all types of SPPF objects that are 657 provisioned by the SPPF client. 659 660 661 662 664 665 666 668 669 670 672 673 674 675 676 677 679 680 681 682 683 684 685 686 687 689 An contains the elements necessary for the SPPF 690 client to precisely determine the overall result of the request, and 691 if an error occurred, it provides information about the specific 692 object key(s) that caused the error. 694 The data elements within the SPP Protocol over SOAP Delete response 695 are described as follows: 697 o clientTransId: Zero or one client transaction ID. This value is 698 simply an echo of the client transaction ID that SPPF client 699 passed into the SPPF update request. When included in the 700 request, the SPPF server MUST return it in the corresponding 701 response message. 703 o serverTransId: Exactly one server transaction ID that identifies 704 this request for tracking purposes. This value MUST be unique for 705 a given SPPF server. 707 o overallResult: Exactly one response code and message pair that 708 explicitly identifies the result of the request. See Section 7.3 709 for further details. 711 o detailResult: An optional response code, response message, and 712 ObjKeyType (as defined in [I-D.draft-ietf-drinks-spp-framework]) 713 triplet. This element will be present only if an specific object 714 key level error has occurred. It indicates the error condition 715 and the exact request object key that contributed to the error. 716 The response code will reflect the exact error. See Section 7.3 717 for further details. 719 7.2.3. Accept Operation Structure 721 In SPPF, a SED Group Offer can be accepted or rejected by, or on 722 behalf of, the registrant to whom the SED Group has been offered 723 (refer Section 3.1 of [I-D.draft-ietf-drinks-spp-framework] for a 724 description of the SED Group Offer object). The Accept operation is 725 used to accept such SED Group Offers by, or on behalf of, the 726 Registrant. The request structure for an SPP Protocol over SOAP 727 Accept operation is wrapped within the element 728 while an SPP Protocol over SOAP Accept response is wrapped within the 729 generic element. The following sub-sections 730 describe the spppAcceptRequest and spppAcceptResponse elements. 731 Refer to Section 10 for an example of Accept operation on a SED Group 732 Offer. 734 7.2.3.1. Accept Request Structure 736 An SPP Protocol over SOAP Accept request definition is contained 737 within the generic element. 739 740 741 742 744 746 749 750 751 753 The data elements within the element are 754 described as follows: 756 o clientTransId: Zero or one client-generated transaction ID that, 757 within the context of the SPPF client, identifies this request. 758 This value can be used at the discretion of the SPPF client to 759 track, log or correlate requests and their responses. SPPF server 760 MUST echo back this value to the client in the corresponding 761 response to the incoming request. SPPF server will not check this 762 value for uniqueness. 764 o minorVer: Zero or one minor version identifier, as defined in 765 Section 7.4. 767 o sedGrpOfferKey: One or more elements of type SedGrpOfferKeyType 768 (as defined in this document). Each element contains attributes 769 that uniquely identify a SED Group Offer that the client is 770 requesting the server to accept. The elements are processed by 771 the SPPF server in the order in which they are included in the 772 request. With respect to handling of error conditions, conforming 773 SPPP SOAP servers MUST stop processing SedGrpOfferKeyType elements 774 in the request at the first error, and roll back any 775 SedGrpOfferKeyType elements that had already been processed for 776 that accept request ("stop and rollback"). 778 7.2.3.2. Accept Response 780 An SPP Protocol over SOAP accept response structure is contained 781 within the generic element. This response 782 structure is used for an Accept request on a SED Group Offer. 784 785 786 787 789 790 791 794 795 796 798 799 800 801 802 803 805 806 807 808 809 810 811 812 813 815 An contains the elements necessary for the SPPF 816 client to precisely determine the overall result of the request, and 817 if an error occurred, it provides information about the specific SED 818 Group Offer key(s) that caused the error. 820 The data elements within the SPP Protocol over SOAP Accept response 821 are described as follows: 823 o clientTransId: Zero or one client transaction ID. This value is 824 simply an echo of the client transaction ID that SPPF client 825 passed into the SPPF update request. When included in the 826 request, the SPPF server MUST return it in the corresponding 827 response message. 829 o serverTransId: Exactly one server transaction ID that identifies 830 this request for tracking purposes. This value MUST be unique for 831 a given SPPF server. 833 o overallResult: Exactly one response code and message pair that 834 explicitly identifies the result of the request. See Section 7.3 835 for further details. 837 o detailResult: An optional response code, response message, and 838 SedGrpOfferKeyType (as defined in this document) triplet. This 839 element will be present only if any specific SED Group Offer key 840 level error has occurred. It indicates the error condition and 841 the exact request SED Group Offer key that contributed to the 842 error. The response code will reflect the exact error. See 843 Section 7.3 for further details. 845 7.2.4. Reject Operation Structure 847 In SPPF, SED Group Offer can be accepted or rejected by, or on behalf 848 of, the registrant to whom the SED Group has been offered (refer 849 "Framework Data Model Objects" section of 850 [I-D.draft-ietf-drinks-spp-framework] for a description of the SED 851 Group Offer object). The Reject operation is used to reject such SED 852 Group Offers by, or on behalf of, the Registrant. The request 853 structure for an SPP Protocol over SOAP Reject operation is wrapped 854 within the element while an SPP Protocol over 855 SOAP Reject response is wrapped within the generic 856 element. The following sub-sections describe the 857 spppRejectRequest and spppRejecResponse elements. Refer to 858 Section 10 for an example of Reject operation on a SED Group Offer. 860 7.2.4.1. Reject Request 862 An SPP Protocol over SOAP Reject request definition is contained 863 within the generic element. 865 866 867 868 870 872 875 876 878 The data elements within the element are 879 described as follows: 881 o clientTransId: Zero or one client-generated transaction ID that, 882 within the context of the SPPF client, identifies this request. 883 This value can be used at the discretion of the SPPF client to 884 track, log or correlate requests and their responses. SPPF server 885 MUST echo back this value to the client in the corresponding 886 response to the incoming request. SPPF server will not check this 887 value for uniqueness. 889 o minorVer: Zero or one minor version identifier, as defined in 890 Section 7.4. 892 o sedGrpOfferKey: One or more elements of type SedGrpOfferKeyType 893 (as defined in this document). Each element contains attributes 894 that uniquely identify a SED Group Offer that the client is 895 requesting the server to reject. The elements are processed by 896 the SPPF server in the order in which they are included in the 897 request. With respect to handling of error conditions, conforming 898 SPPF servers MUST stop processing SedGrpOfferKeyType elements in 899 the request at the first error, and roll back any 900 SedGrpOfferKeyType elements that had already been processed for 901 that reject request ("stop and rollback"). 903 7.2.4.2. Reject Response 905 An SPP Protocol over SOAP reject response structure is contained 906 within the generic element. This response 907 structure is used for an Reject request on a SED Group Offer. 909 910 911 912 914 915 916 919 920 921 923 924 925 926 927 928 930 931 932 933 934 935 936 937 938 940 An contains the elements necessary for the SPPF 941 client to precisely determine the overall result of the request, and 942 if an error occurred, it provides information about the specific SED 943 Group Offer key(s) that caused the error. 945 The data elements within the SPP Protocol over SOAP Reject response 946 are described as follows: 948 o clientTransId: Zero or one client transaction ID. This value is 949 simply an echo of the client transaction ID that SPPF client 950 passed into the SPPF update request. When included in the 951 request, the SPPF server MUST return it in the corresponding 952 response message. 954 o serverTransId: Exactly one server transaction ID that identifies 955 this request for tracking purposes. This value MUST be unique for 956 a given SPPF server. 958 o overallResult: Exactly one response code and message pair that 959 explicitly identifies the result of the request. See Section 7.3 960 for further details. 962 o detailResult: An optional response code, response message, and 963 SedGrpOfferKeyType (as defined in this document) triplet. This 964 element will be present only if any specific SED Group Offer key 965 level error has occurred. It indicates the error condition and 966 the exact request SED Group Offer key that contributed to the 967 error. The response code will reflect the exact error. See 968 Section 7.3 for further details. 970 7.2.5. Batch Operation Structure 972 An SPP Protocol over SOAP Batch request XML structure allows the SPPF 973 client to send any of of Add, Del, Accept or Reject operations 974 together in one single request. This gives an SPPF Client the 975 flexibility to use one single request structure to perform more than 976 operations (verbs). The batch request structure is wrapped within 977 the element while a SPPF Batch response is wrapped 978 within the element. This following sub-sections 979 describe the spppBatchRequest and spppBatchResponse elements. Refer 980 to Section 10 for an example of a batch operation. 982 7.2.5.1. Batch Request Structure 984 An SPP Protocol over SOAP Batch request definition is contained 985 within the generic element. 987 988 989 990 992 994 995 996 997 999 1001 1002 1003 1004 1006 The data elements within the element are described 1007 as follows: 1009 o clientTransId: Zero or one client-generated transaction ID that, 1010 within the context of the SPPF Client, identifies this request. 1011 This value can be used at the discretion of the SPPF client to 1012 track, log or correlate requests and their responses. SPPF Server 1013 MUST echo back this value to the Client in the corresponding 1014 response to the incoming request. SPPF Server will not check this 1015 value for uniqueness. 1017 o minorVer: Zero or one minor version identifier, as defined in 1018 Section 7.4. 1020 o addObj: One or more elements of abstract type BasicObjType where 1021 each element identifies an object that needs to be added. 1023 o delObj: One or more elements of abstract type ObjKeyType where 1024 each element identifies a key for the object that needs to be 1025 deleted . 1027 o acceptSedGrpOffer: One or more elements of type SedGrpOfferKeyType 1028 where each element identifies a SED Group Offer that needs to be 1029 accepted. 1031 o rejectSedGrpOffer: One or more elements of type SedGrpOfferKeyType 1032 where each element identifies a SED Group Offer that needs to be 1033 rejected. 1035 With respect to handling of error conditions, conforming SPPP SOAP 1036 servers MUST stop processing elements in the request at the first 1037 error, and roll back any elements that had already been processed for 1038 that batch request ("stop and rollback"). 1040 7.2.5.2. Batch Response 1042 An SPP Protocol over SOAP batch response structure is contained 1043 within the generic element. This response 1044 structure is used for an Batch request that contains many different 1045 types of SPPF operations. 1047 1048 1049 1050 1052 1053 1054 1055 1057 1059 1061 1063 1064 1065 1066 1068 An contains the elements necessary for an SPPF 1069 client to precisely determine the overall result of various 1070 operations in the request, and if an error occurred, it provides 1071 information about the specific objects or keys in the request that 1072 caused the error. 1074 The data elements within the SPP Protocol over SOAP Batch response 1075 are described as follows: 1077 o clientTransId: Zero or one client transaction ID. This value is 1078 simply an echo of the client transaction ID that SPPF client 1079 passed into the SPPF update request. When included in the 1080 request, the SPPF server MUST return it in the corresponding 1081 response message. 1083 o serverTransId: Exactly one server transaction ID that identifies 1084 this request for tracking purposes. This value MUST be unique for 1085 a given SPPF server. 1087 o overallResult: Exactly one response code and message pair that 1088 explicitly identifies the result of the request. See Section 7.3 1089 for further details. 1091 o addResult: One or more elements of type ObjResultCodeType where 1092 each element identifies the result code, result message and the 1093 specific object that the result relates to. 1095 o delResult: One or more elements of type ObjKeyResultCodeType where 1096 each element identifies the result code, result message and the 1097 specific object key that the result relates to. 1099 o acceptResult: One or more elements of type 1100 SedGrpOfferKeyResultCodeType where each element identifies the 1101 result code, result message and the specific SED Group Offer key 1102 that the result relates to. 1104 o rejectResult: One or more elements of type 1105 SedGrpOfferKeyResultCodeType where each element identifies the 1106 result code, result message and the specific SED Group Offer key 1107 that the result relates to. 1109 7.2.6. Get Operation Structure 1111 In order to query the details of an object from the Registry, an 1112 authorized entity can send the spppGetRequest to the registry with a 1113 GetRqstType XML data structure containing one or more object keys 1114 that uniquely identify the object whose details are being queried. 1115 The request structure for an SPP Protocol over SOAP Get operation is 1116 contained within the generic element while an SPP 1117 Protocol over SOAP Get response is wrapped within the generic 1118 element. The following sub-sections describe the 1119 spppGetRequest and spppGetResponse element. Refer to Section 10 for 1120 an example of SPP Protocol over SOAP Get operation on each type of 1121 SPPF object 1123 7.2.6.1. Get Request 1124 1125 1126 1127 1129 1132 1133 1134 1136 The data elements within the element are described 1137 as follows: 1139 o minorVer: Zero or one minor version identifier, as defined in 1140 Section 7.4. 1142 o objKey: One or more elements of abstract type ObjKeyType (as 1143 defined in [I-D.draft-ietf-drinks-spp-framework]). Each element 1144 contains attributes that uniquely identify the object that the 1145 client is requesting the server to query. Refer to Section 7.1 of 1146 this document for a description of all concrete object key types, 1147 for various SPPF objects, which are eligible to be passed into 1148 this element. 1150 7.2.6.2. Get Response 1152 The spppGetResponse element is described in Section 7.2.8. 1154 7.2.7. Get SED Group Offers Operation Structure 1156 In addition to the ability to query the details of one or more SED 1157 Group offers using an a SED Group Offer key in the spppGetRequest, 1158 this operation also provides an additional, more flexible, structure 1159 to query for SED Group Offer objects. This additional structure is 1160 contained within the element while the 1161 response is wrapped within the generic element. 1162 The following sub-sections describe the getSedGrpOffersRequest and 1163 spppGetResponse elements. 1165 7.2.7.1. Get SED Group Offers Request 1167 Using the details passed into this structure, the server will attempt 1168 to find SED Group Offer objects that satisfy all the criteria passed 1169 into the request. If no criteria is passed in then the SPPF Server 1170 will return the list of SED Group Offer objects that belongs to the 1171 registrant. If there are no matching SED Group Offers found then an 1172 empty result set will be returned. 1174 1175 1176 1177 1179 1181 1183 1185 1187 1188 1189 1191 The data elements within the element are 1192 described as follows: 1194 o minorVer: Zero or one minor version identifier, as defined in 1195 Section 7.4. 1197 o offeredBy: Zero or more organization IDs. Only offers that are 1198 offered to the organization IDs in this list should be included in 1199 the result set. The result set is also subject to other query 1200 criteria in the request. 1202 o offeredTo: Zero or more organization IDs. Only offers that are 1203 offered by the organization IDs in this list should be included in 1204 the result set. The result set is also subject to other query 1205 criteria in the request. 1207 o status: The status of the offer, offered or accepted. Only offers 1208 in the specified status should be included in the result set. If 1209 this element is not present then the status of the offer should 1210 not be considered in the query. The result set is also subject to 1211 other query criteria in the request. 1213 o sedGrpOfferKey: Zero or more SED Group Offer Keys. Only offers 1214 having one of these keys should be included in the result set. 1215 The result set is also subject to other query criteria in the 1216 request. 1218 7.2.7.2. Get SED Group Offers Response 1220 The spppGetResponse element is described in Section 7.2.8. 1222 7.2.8. Generic Query Response 1224 An SPP Protocol over SOAP query response object is contained within 1225 the generic element. 1227 1228 1229 1230 1232 1235 1236 1237 1239 An contains the elements necessary for the SPPF 1240 client to precisely determine the overall result of the query, and 1241 details of any SPPF objects that matched the criteria in the request. 1243 The data elements within the SPP Protocol over SOAP query response 1244 are described as follows: 1246 o overallResult: Exactly one response code and message pair that 1247 explicitly identifies the result of the request. See Section 7.3 1248 for further details. 1250 o resultObj: The set of zero or more objects that matched the query 1251 criteria. If no objects matched the query criteria then the 1252 result object(s) MUST be empty and the overallResult value MUST 1253 indicate success (if no matches are found for the query criteria, 1254 the response is considered a success). 1256 7.2.9. Get Server Details Operation Structure 1258 In order to query certain details of the SPPF server, such as the 1259 SPPF server's status and the major/minor version supported by the 1260 server, the Server Details operation structure SHOULD be used. This 1261 structure is contained within the element 1262 whereas a SPPF server status response is wrapped within the 1263 element. The following sub-sections 1264 describe the spppServerStatusRequest and spppServerStatusResponse 1265 elements. 1267 7.2.9.1. Get Server Details Request 1269 1270 1271 1272 1274 1275 1276 1278 The data elements within the element are 1279 described as follows: 1281 o minorVer: Zero or one minor version identifier, as defined in 1282 Section 7.4. 1284 7.2.9.2. Get Server Details Response 1286 An SPP Protocol over SOAP server details response structure is 1287 contained within the generic element. 1289 1290 1291 1292 1293 1294 1295 1296 1298 The data elements within the element are 1299 described as follows: 1301 o overallResult: Exactly one response code and message pair that 1302 explicitly identifies the result of the request. See Section 7.3 1303 for further details. 1305 o svcMenu: Exactly one element of type SvcMenuType which in turn 1306 contains the elements to return the server status, the major and 1307 minor versions of the SPP Protocol over SOAP supported by the SPPF 1308 server (refer Section 12 of [I-D.draft-ietf-drinks-spp-framework] 1309 for definition of SvcMenuType). 1311 7.3. Response Codes and Messages 1313 This section contains the listing of response codes and their 1314 corresponding human-readable text. These response codes are in 1315 conformance with the response types defined in Section 5.3 of 1316 [I-D.draft-ietf-drinks-spp-framework]. 1318 The response code numbering scheme generally adheres to the theory 1319 formalized in section 4.2.1 of [RFC5321]: 1321 o The first digit of the response code can only be 1 or 2: 1 = a 1322 positive result, 2 = a negative result. 1324 o The second digit of the response code indicates the category: 0 = 1325 Protocol Syntax, 1 = Implementation Specific Business Rule, 2 = 1326 Security, 3 = Server System. 1328 o The third and fourth digits of the response code indicate the 1329 individual message event within the category defines by the first 1330 two digits. 1332 The response codes are also categorized as to whether they are 1333 overall response codes that may only be returned in the 1334 "overallResult" data element in SPPF responses, or object level 1335 response codes that may only be returned in the "detailResult" 1336 element of the SPPF responses. 1338 +--------+--------------------------+-------------------------------+ 1339 | Result | Result Message | Overall or Object Level | 1340 | Code | | | 1341 +--------+--------------------------+-------------------------------+ 1342 | 1000 | Request Succeeded. | Overall Response Code | 1343 | | | | 1344 | 2000 | Request syntax invalid. | Overall Response Code | 1345 | | | | 1346 | 2001 | Request too large. | Overall Response Code | 1347 | | MaxSupported:[Maximum | | 1348 | | requests supported] | | 1349 | | | | 1350 | 2002 | Version not supported. | Overall Response Code | 1351 | | | | 1352 | 2100 | Command invalid. | Overall Response Code | 1353 | | | | 1354 | 2300 | System temporarily | Overall Response Code | 1355 | | unavailable. | | 1356 | | | | 1357 | 2301 | Unexpected internal | Overall Response Code | 1358 | | system or server error. | | 1359 | | | | 1360 | 2101 | Attribute value invalid. | Object Level Response Code | 1361 | | AttrName:[AttributeName] | | 1362 | | AttrVal:[AttributeValue] | | 1363 | | | | 1364 | 2102 | Object does not exist. | Object Level Response Code | 1365 | | AttrName:[AttributeName] | | 1366 | | AttrVal:[AttributeValue] | | 1367 | | | | 1368 | 2103 | Object status or | Object Level Response Code | 1369 | | ownership does not allow | | 1370 | | for operation. | | 1371 | | AttrName:[AttributeName] | | 1372 | | AttrVal:[AttributeValue] | | 1373 +--------+--------------------------+-------------------------------+ 1375 Table 1: Response Codes Numbering Scheme and Messages 1377 Response message for response code 2001 is "parameterized" with the 1378 following parameter: "[Maximum requests supported]". When the 1379 request is too large, this parameter MUST be used to indicate the 1380 maximum number of requests supported by the server in a single 1381 protocol operation. 1383 Response code 2000 SHOULD be used when the XML Schema validation of 1384 requests fails. 1386 Each of the object level response messages are "parameterized" with 1387 the following parameters: "AttributeName" and "AttributeValue". 1389 For example, if an SPPF client sends a request to delete a 1390 Destination Group with a name "TestDG", and it does not already 1391 exist, then the error message returned should be: "Attribute value 1392 invalid. AttrName:dgName AttrVal:TestDG". 1394 The use of these parameters MUST adhere to the rules defined in 1395 Section 5.3 of [I-D.draft-ietf-drinks-spp-framework]. 1397 7.4. Minor Version Identifier 1399 The minor version identifier element is defined as follows: 1401 o minorVer: Zero or one minor version identifier, indicating the 1402 minor version of the SPP Protocol over SOAP API that the client is 1403 attempting to use. This is used in conjunction with the major 1404 version identifier in the XML namespace to identify the version of 1405 SPP Protocol over SOAP that the client is using. If the element 1406 is not present, the server assumes that the client is using the 1407 latest minor version of SPP Protocol over SOAP supported by the 1408 SPPF server for the given major version. The versions of SPP 1409 Protocol over SOAP supported by a given SPPF server can be 1410 retrieved by the client using this same spppServerStatusRequest 1411 without passing in the minorVer element. 1413 8. Protocol Operations 1415 Refer to Section 7 of [I-D.draft-ietf-drinks-spp-framework] for a 1416 description of all SPPF operations, and any necessary semantics that 1417 MUST be adhered to in order to conform with SPPF. 1419 9. SPP Protocol over SOAP WSDL Definition 1421 The SPP Protocol over SOAP WSDL and data types are defined below. 1422 The WSDL design approach is commonly referred to as "Generic WSDL". 1423 It is generic in the sense that there is not a specific WSDL 1424 operation defined for each object type that is supported by the SPPF 1425 protocol. There is a single WSDL structure for each type of SPPF 1426 operation. Each such WSDL structure contains exactly one input 1427 structure and one output structure that wraps any data elements that 1428 are part of the incoming request and the outgoing response 1429 respectively. The spppSOAPBinding in the WSDL defines the binding 1430 style as "document" and the encoding as "literal". It is this 1431 combination of "wrapped" input and output data structures, "document" 1432 binding style, and "literal" encoding that characterize the Document 1433 Literal Wrapped style of WSDL specifications. 1435 Notes: The following WSDL has been formatted (e.g. tabs, spaces) to 1436 meet IETF document requirements. Deployments MUST replace 1437 "REPLACE_WITH_ACTUAL_URL" in the WSDL below with the URI of the SPPF 1438 Server instance. 1440 1441 1448 1449 1452 1453 1454 ---- Import base schema ---- 1455 1456 1457 1459 1460 1461 ---- Key type(s) extended 1462 from base schema. ---- 1463 1464 1465 1466 1467 1468 1469 1470 1471 1472 1473 1474 1475 1476 1477 1478 1479 1480 1481 1482 1484 1486 1487 1488 1489 1490 1492 1494 1495 1496 1497 1499 1500 1501 1502 1503 1504 1505 1507 1509 1510 1511 1512 1513 1515 1516 1517 ---- Generic Request and 1518 Response Definitions ---- 1519 1520 1521 1522 1523 1524 1526 1528 1530 1531 1533 1534 1535 1536 1537 1539 1541 1543 1544 1545 1546 1547 1548 1549 1551 1553 1556 1557 1558 1559 1560 1561 1562 1564 1566 1569 1570 1571 1572 1573 1574 1575 1577 1580 1582 1583 1584 1585 1586 1587 1589 1591 1592 1593 1594 1596 1598 1599 1600 1601 1602 1603 1604 1605 1607 1608 1609 1610 1611 1612 1613 1615 1618 1620 1622 1625 1626 1627 1628 1629 1630 1631 1633 1635 1637 1640 1641 1642 1643 1644 1645 1646 1648 1650 1652 1655 1656 1657 1658 1659 1660 1661 1663 1665 1667 1670 1671 1672 1673 1674 1675 1676 1678 1680 1682 1685 1686 1687 1688 1689 1690 1691 1693 1695 1697 1698 1700 1702 1704 1706 1707 1708 1709 1710 1711 1712 1713 1715 1718 1719 1720 1721 1722 1723 1724 1726 1728 1729 1730 1731 1732 1733 ---- Operation Result Type 1734 Definitions ---- 1735 1736 1737 1738 1739 1740 1741 1742 1744 1745 1746 1747 1748 1749 1750 1751 1752 1753 1754 1755 1756 1757 1759 1760 1761 1762 1763 1764 1766 1767 1768 1769 1770 1771 1772 1773 1775 1776 1777 1778 1779 1780 1781 1782 1783 1784 1785 1786 1787 1788 1789 1791 1792 1793 1794 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 1824 1825 1826 1827 1828 1829 1830 1831 1832 1833 1834 1835 1836 1837 1838 1839 1840 1841 1842 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 1880 1881 1882 1883 1884 1885 1886 1887 1888 1889 1890 1891 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 1921 1922 1923 1924 1925 1926 1927 1928 1929 1930 1931 1932 1933 1934 1935 1936 1938 1939 1940 1941 1942 1943 1944 1945 1946 1948 1949 1950 1951 1952 1953 1954 1955 1956 1957 1958 1959 1960 1961 1963 Figure 2: WSDL 1965 10. SPP Protocol over SOAP Examples 1967 This section shows XML message exchange between two SIP Service 1968 Providers (SSP) and a registry. The messages in this section are 1969 valid XML instances that conform to the SPP Protocol over SOAP schema 1970 version within this document. This section also relies on the XML 1971 data structures defined in the SPPF specification 1972 [I-D.draft-ietf-drinks-spp-framework]. Which should also be 1973 referenced to understand XML object types embedded in these example 1974 messages. 1976 In this sample use case scenario, SSP1 and SSP2 provision resource 1977 data in the registry and use SPPF constructs to selectively share the 1978 SED groups. In the figure below, SSP2 has two ingress SBE instances 1979 that are associated with the public identities that SSP2 has the 1980 retail relationship with. Also, the two Session Border Element 1981 instances for SSP1 are used to show how to use SPPF to associate 1982 route preferences for the destination ingress routes and exercise 1983 greater control on outbound traffic to the peer's ingress SBEs. 1985 ---------------+ +------------------ 1986 | | 1987 +------+ +------+ 1988 | sbe1 | | sbe2 | 1989 +------+ +------+ 1990 SSP1 | | SSP2 1991 +------+ +------+ 1992 | sbe3 | | sbe4 | 1993 +------+ +------+ 1994 iana-en:111 | | iana-en:222 1995 ---------------+ +------------------ 1996 | | 1997 | | 1998 | SPPF +------------------+ SPPF | 1999 +------->| Registry |<--------+ 2000 +------------------+ 2002 10.1. Add Destination Group 2004 SSP2 adds a destination group to the registry for use later. The 2005 SSP2 SPPF client sets a unique transaction identifier 'txn_1479' for 2006 tracking purposes. The name of the destination group is set to 2007 DEST_GRP_SSP2_1 2008 2009 2014 2015 2016 2017 2018 txn_1479 2019 2020 2021 iana-en:222 2022 iana-en:223 2023 DEST_GRP_SSP2_1 2024 2025 2026 2027 2029 The registry processes the request and return a favorable response 2030 confirming successful creation of the named destination group. Also, 2031 besides returning a unique server transaction identifier, Registry 2032 also returns the matching client transaction identifier from the 2033 request message back to the SPPF client. 2035 2036 2038 2039 2042 txn_1479 2043 tx_12345 2044 2045 1000 2046 Request Succeeded. 2047 2048 2049 2050 2052 10.2. Add SED Records 2054 SSP2 adds SED records in the form of ingress routes to the registry. 2056 2057 2062 2063 2064 2065 2066 txn_1479 2067 2068 2069 iana-en:222 2070 iana-en:223 2071 SED_SSP2_SBE2 2072 true 2073 10 2074 u 2075 E2U+sip 2076 2077 ^(.*)$ 2078 sip:\1@sbe2.ssp2.example.com 2079 2080 2081 2082 2083 2085 The registry returns a success response. 2087 2088 2090 2091 2094 txn_1479 2095 tx_12345 2096 2097 1000 2098 Request Succeeded. 2099 2100 2101 2102 2104 10.3. Add SED Records -- URIType 2106 SSP2 adds another SED record to the registry and makes use of URIType 2108 2109 2114 2115 2116 2117 txn_1479 2118 2119 2120 iana-en:222 2121 iana-en:223 2122 SED_SSP2_SBE4 2123 true 2124 ^(.*)$ 2125 sip:\1;npdi@sbe4.ssp2.example.com 2126 2127 2128 2129 2131 The registry returns a success response. 2133 2134 2135 2136 2139 txn_1479 2140 tx_12345 2141 2142 1000 2143 Request Succeeded. 2144 2145 2146 2147 2149 10.4. Add SED Group 2151 SSP2 creates the grouping of SED records (e.g. ingress routes) and 2152 chooses higher precedence for SED_SSP2_SBE2 by setting a lower number 2153 for the "priority" attribute, a protocol agnostic precedence 2154 indicator. 2156 2157 2162 2163 2164 2165 txn_1479 2166 2167 2168 iana-en:222 2169 iana-en:223 2170 SED_GRP_SSP2_1 2171 2172 2173 iana-en:222 2174 SED_SSP2_SBE2 2175 SedRec 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 10.5. Add Public Identifier -- Successful COR claim 2208 SSP2 activates a TN public identifier 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 10.6. Add LRN 2278 If another entity that SSP2 shares session establishment information 2279 (e.g. routes) with has access to Number Portability data, it may 2280 choose to perform route lookups by routing number. Therefore, SSP2 2281 associates a routing number to a destination group in order to 2282 facilitate ingress route discovery. 2284 2285 2290 2291 2292 2293 txn_1479 2294 2295 2296 iana-en:222 2297 iana-en:223 2298 DEST_GRP_SSP2_1 2299 2025550000 2300 2301 2302 2303 2305 Registry completes the request successfully and returns a favorable 2306 response to the SPPF client. 2308 2309 2311 2312 2315 txn_1479 2316 tx_12345 2317 2318 1000 2319 Request Succeeded. 2320 2321 2322 2323 2325 10.7. Add TN Range 2327 Next, SSP2 activates a block of ten thousand TNs and associate it to 2328 a destination group. 2330 2331 2336 2337 2338 2339 txn_1479 2340 2341 2342 iana-en:222 2343 iana-en:223 2344 DEST_GRP_SSP2_1 2345 2346 +12026660000 2347 +12026669999 2348 2349 2350 2351 2352 2353 Registry completes the request successfully and returns a favorable 2354 response. 2356 2357 2359 2360 2363 txn_1479 2364 tx_12345 2365 2366 1000 2367 Request Succeeded. 2368 2369 2370 2371 2373 10.8. Add TN Prefix 2375 Next, SSP2 activates a block of ten thousand TNs using the TNPType 2376 structure and identifying a TN prefix. 2378 2379 2384 2385 2386 2387 txn_1479 2388 2389 2390 iana-en:222 2391 iana-en:223 2392 DEST_GRP_SSP2_1 2393 +1202777 2394 2395 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 10.9. Enable Peering -- SED 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 SED 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 SED_GRP_SSP2_1 2445 SedGrp 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 10.10. Enable Peering -- SED Group Offer Accept 2483 SSP1 responds to the offer from SSP2 and agrees to have visibility to 2484 SSP2 session establishment information (e.g. ingress routes). 2486 2487 2490 2491 2492 2493 2494 txn_1479 2495 2496 2497 2498 iana-en:222 2499 SED_GRP_SSP2_1 2500 SedGrp 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 identifier through 2509 the query resolution server, where the public identifier is part of 2510 the destination group by way of "SED_GRP_SSP2_1" session 2511 establishment data association, SSP2 ingress SBE information will be 2512 shared with SSP1. 2514 2515 2517 2518 2521 txn_1479 2522 tx_12350 2523 2524 1000 2525 Request Succeeded. 2526 2527 2528 2529 2531 10.11. Add Egress Route 2533 SSP1 wants to prioritize all outbound traffic to the ingress route 2534 associated with the "SED_GRP_SSP2_1" SED Group record, through 2535 "sbe1.ssp1.example.com". 2537 2538 2543 2544 2545 2546 txn_1479 2547 2548 2549 iana-en:222 2550 iana-en:223 2551 EGR_RTE_01 2552 50 2553 2554 ^(.*@)(.*)$ 2555 \1\2?route=sbe1.ssp1.example.com 2556 2557 2558 iana-en:222 2559 SED_GRP_SSP2_1 2560 SedGrp 2561 2562 2563 2564 2565 2567 Since peering has already been established, the request to add the 2568 egress route has been successfully completed. 2570 2571 2573 2574 2577 txn_1479 2578 tx_12345 2579 2580 1000 2581 Request Succeeded. 2582 2583 2584 2585 2587 10.12. Remove Peering -- SED Group Offer Reject 2589 SSP1 had earlier accepted to have visibility to SSP2 session 2590 establishment data. SSP1 now decides to no longer maintain this 2591 visibility and hence rejects the SED Group Offer. 2593 2594 2597 2598 2599 2600 2601 txn_1479 2602 2603 2604 2605 iana-en:222 2606 SED_GRP_SSP2_1 2607 SedGrp 2608 2609 iana-en:111 2610 2611 2612 2613 2614 Registry confirms that the request has been processed successfully. 2615 From this point forward, if SSP1 looks up a public identifier through 2616 the query resolution server, where the public identifier is part of 2617 the destination group by way of "SED_GRP_SSP2_1" session 2618 establishment data association, SSP2 ingress SBE information will not 2619 be shared with SSP1 and hence SSP2 ingress SBE will not be returned 2620 in the query response. 2622 2623 2625 2626 2629 txn_1479 2630 tx_12350 2631 2632 1000 2633 Request Succeeded. 2634 2635 2636 2637 2639 10.13. Get Destination Group 2641 SSP2 uses the 'spppGetRequest' operation to tally the last 2642 provisioned record for destination group DEST_GRP_SSP2_1. 2644 2645 2649 2650 2651 2652 2653 2654 iana-en:222 2655 DEST_GRP_SSP2_1 2656 DestGrp 2657 2658 2659 2660 2662 Registry completes the request successfully and returns a favorable 2663 response. 2665 2666 2669 2670 2673 2674 1000 2675 success 2676 2677 2678 iana-en:222 2679 iana-en:223 2680 2012-10-22T09:30:10Z 2681 DEST_GRP_SSP2_1 2682 2683 2684 2685 2687 10.14. Get Public Identifier 2689 SSP2 obtains the last provisioned record associated with a given TN. 2691 2692 2697 2698 2699 2700 2701 2702 iana-en:222 2703 2704 +12025556666 2705 TN 2706 2707 2708 2709 2710 2712 Registry completes the request successfully and returns a favorable 2713 response. 2715 2718 2719 2722 2723 1000 2724 success 2725 2726 2727 iana-en:222 2728 iana-en:223 2729 2012-10-22T09:30:10Z 2730 DEST_GRP_SSP2_1 2731 +12025556666 2732 2733 true 2734 true 2735 2010-05-30T09:30:10Z 2736 2737 2738 2739 2740 2742 10.15. Get SED Group Request 2744 SSP2 obtains the last provisioned record for the SED group 2745 SED_GRP_SSP2_1. 2747 2748 2752 2753 2754 2755 2756 2757 iana-en:222 2758 SED_GRP_SSP2_1 2759 SedGrp 2760 2761 2762 2763 2765 Registry completes the request successfully and returns a favorable 2766 response. 2768 2769 2772 2773 2776 2777 1000 2778 success 2779 2780 2781 iana-en:222 2782 iana-en:223 2783 2012-10-22T09:30:10Z 2784 SED_GRP_SSP2_1 2785 2786 2787 iana-en:222 2788 SED_SSP2_SBE2 2789 SedRec 2790 2791 100 2792 2793 2794 2795 iana-en:222 2796 SED_SSP2_SBE4 2797 SedRec 2798 2799 101 2800 2801 DEST_GRP_SSP2_1 2802 true 2803 10 2804 2805 2806 2807 2809 10.16. Get SED Group Offers Request 2811 SSP2 fetches the last provisioned SED group offer to the 2812 SSP1. 2814 2815 2818 2819 2820 2821 iana-en:111 2822 2823 2824 2826 Registry processes the request successfully and returns a favorable 2827 response. 2829 2830 2833 2834 2837 2838 1000 2839 success 2840 2841 2842 iana-en:222 2843 iana-en:223 2844 2012-10-22T09:30:10Z 2845 2847 2848 iana-en:222 2849 SED_GRP_SSP2_1 2850 SedGrp 2851 2852 iana-en:111 2853 2854 offered 2855 2856 2006-05-04T18:13:51.0Z 2857 2858 2859 2860 2861 2863 10.17. Get Egress Route 2865 SSP1 wants to verify the last provisioned record for the egress route 2866 called EGR_RTE_01. 2868 2869 2873 2874 2875 2876 2877 2878 iana-en:111 2879 EGR_RTE_01 2880 EgrRte 2881 2882 2883 2884 2886 Registry completes the request successfully and returns a favorable 2887 response. 2889 2890 2893 2894 2897 2898 1000 2899 success 2900 2901 2902 iana-en:222 2903 iana-en:223 2904 2012-10-22T09:30:10Z 2905 EGR_RTE_01 2906 50 2907 2908 ^(.*)$ 2909 sip:\1@sbe1.ssp1.example.com 2910 2911 2912 iana-en:222 2913 SED_GRP_SSP2_1 2914 SedRec 2915 2916 2917 2918 2919 2921 10.18. Delete Destination Group 2923 SSP2 initiates a request to delete the destination group 2924 DEST_GRP_SSP2_1. 2926 2927 2931 2932 2933 2934 2935 2936 iana-en:222 2937 DEST_GRP_SSP2_1 2938 DestGrp 2939 2940 2941 2942 2944 Registry completes the request successfully and returns a favorable 2945 response. 2947 2948 2950 2951 2954 tx_12354 2955 2956 1000 2957 Request Succeeded. 2958 2959 2960 2961 2963 10.19. Delete Public Identifier 2965 SSP2 chooses to de-activate the TN and remove it from the registry. 2967 2968 2973 2974 2975 2976 2977 2978 iana-en:222 2979 2980 +12025556666 2981 TN 2982 2983 2984 2985 2986 2988 Registry completes the request successfully and returns a favorable 2989 response. 2991 2992 2994 2995 2998 tx_12354 2999 3000 1000 3001 Request Succeeded. 3002 3003 3004 3005 3007 10.20. Delete SED Group Request 3009 SSP2 removes the SED group called SED_GRP_SSP2_1. 3011 3012 3016 3017 3018 3019 3020 3021 iana-en:222 3022 SED_GRP_SSP2_1 3023 SedGrp 3024 3025 3026 3027 3029 Registry completes the request successfully and returns a favorable 3030 response. 3032 3033 3035 3036 3039 tx_12354 3040 3041 1000 3042 Request Succeeded. 3043 3044 3045 3046 3048 10.21. Delete SED Group Offers Request 3050 SSP2 no longer wants to share SED group SED_GRP_SSP2_1 with SSP1. 3052 3053 3057 3058 3059 3060 3061 3062 3063 iana-en:222 3064 SED_GRP_SSP2_1 3065 SedGrp 3066 3067 iana-en:111 3068 3069 3070 3071 3073 Registry completes the request successfully and returns a favorable 3074 response. Restoring this resource sharing will require a new SED 3075 group offer from SSP2 to SSP1 followed by a successful SED group 3076 accept request from SSP1. 3078 3079 3081 3082 3085 tx_12354 3086 3087 1000 3088 Request Succeeded. 3089 3090 3091 3092 3094 10.22. Delete Egress Route 3096 SSP1 decides to remove the egress route with the label EGR_RTE_01. 3098 3099 3103 3104 3105 3106 3107 3108 iana-en:111 3109 EGR_RTE_01 3110 EgrRte 3111 3112 3113 3114 3116 Registry completes the request successfully and returns a favorable 3117 response. 3119 3120 3122 3123 3126 tx_12354 3127 3128 1000 3129 Request Succeeded. 3130 3131 3132 3133 3135 10.23. Batch Request 3137 Following is an example of how some of the operations mentioned in 3138 previous sections MAY be performed by an SPPF client as a batch in 3139 one single SPP Protocol over SOAP request. 3141 In the sample request below SSP1 wants to accept a SED Group Offer 3142 from SSP3, add a Destination Group, add a NAPTR SED Record, add a SED 3143 Group, add a SED Group Offer, delete a previously provisioned TN type 3144 Public Identifier, delete a previously provisioned SED Group, and 3145 reject a SED Group Offer from SSP4. 3147 3148 3153 3154 3155 3156 txn_1467 3157 1 3159 3160 3161 iana-en:225 3162 SED_SSP3_SBE1_Offered 3163 SedGrp 3164 3165 iana-en:222 3166 3168 3169 iana-en:222 3170 iana-en:223 3171 DEST_GRP_SSP2_1 3172 3174 3175 iana-en:222 3176 iana-en:223 3177 SED_SSP2_SBE2 3178 10 3179 u 3180 E2U+sip 3181 3182 ^(.*)$ 3183 sip:\1@sbe2.ssp2.example.com 3184 3185 3187 3188 iana-en:222 3189 iana-en:223 3190 SED_GRP_SSP2_1 3191 3192 3193 iana-en:222 3194 SED_SSP2_SBE2 3195 SedRec 3196 3197 100 3198 3199 DEST_GRP_SSP2_1 3200 true 3201 10 3202 3204 3205 iana-en:222 3206 iana-en:223 3207 3208 3209 iana-en:222 3210 SED_GRP_SSP2_1 3211 SedGrp 3212 3213 iana-en:111 3214 3215 offered 3216 3217 2006-05-04T18:13:51.0Z 3218 3219 3221 3222 iana-en:222 3223 3224 +12025556666 3225 TN 3226 3227 3229 3230 iana-en:222 3231 SED_GRP_SSP2_Previous 3232 SedGrp 3233 3235 3236 3237 iana-en:226 3238 SED_SSP4_SBE1_Offered 3239 SedGrp 3240 3241 iana-en:222 3242 3244 3245 3246 3248 Registry completes the request successfully and returns a favorable 3249 response. 3251 3252 3254 3255 3258 tx_12354 3259 3260 1000 3261 Request Succeeded. 3262 3263 3264 3265 3267 11. Security Considerations 3269 The base security considerations of SPPP outlined in Section 9 of 3270 [I-D.draft-ietf-drinks-spp-framework] also apply to SPP Protocol over 3271 SOAP implementations. Additionally, the following must be 3272 considered: 3274 SPP Protocol over SOAP is used to query and update session peering 3275 data and addresses, so the ability to access this protocol should be 3276 limited to users and systems that are authorized to query and update 3277 this data. Because this data is sent in both directions, it may not 3278 be sufficient for just the client or user to be authenticated with 3279 the server. The identity of the server should also be authenticated 3280 by the client, which is often accomplished using the TLS certificate 3281 exchange and validation described in [RFC2818]. 3283 11.1. Vulnerabilities 3285 Section 5 describes the use of HTTP and TLS as the underlying 3286 substrate protocols for SPP Protocol over SOAP. These underlying 3287 protocols may have various vulnerabilities, and these may be 3288 inherited by SPP Protocol over SOAP. SPP Protocol over SOAP itself 3289 may have vulnerabilities because an authorization model is not 3290 explicitly specified in this document. 3292 During a TLS handshake, TLS servers can optionally request a 3293 certificate from a TLS client; that option is not a requirement for 3294 this protocol. This presents a denial of service risk in which 3295 unauthenticated clients can consume server CPU resources by creating 3296 TLS sessions. The risk is increased if the server supports client- 3297 initiated renegotiation. This risk can be mitigated by disabling 3298 client-initiated renegotiation on the server and by ensuring that 3299 other means (such as firewall access control lists) are used to 3300 restrict unauthenticated client access to servers. 3302 In conjunction with the above, it is important that SPP Protocol over 3303 SOAP implementations implement an authorization model that considers 3304 the source of each query or update request and determines whether it 3305 is reasonable to authorize that source to perform that specific query 3306 or update. 3308 12. IANA Considerations 3310 This document uses URNs to describe XML Namespaces and XML Schemas. 3311 According to [RFC3688], IANA is requested to perform the following 3312 URN assignment: 3314 URN: urn:ietf:params:xml:ns:sppf:soap:1 3316 Registrant Contact: IESG 3318 XML: See Section 9 of [THISDOCUMENT] 3320 13. Acknowledgements 3322 This document is a result of various discussions held with the IETF 3323 DRINKS working group, specifically the protocol design team, with 3324 contributions from the following individuals, in alphabetical order: 3325 Alexander Mayrhofer, David Schwartz, Deborah A Guyton, Jean-Francois 3326 Mule Kenneth Cartwright, Lisa Dusseault, Manjul Maharishi, Mickael 3327 Marrache, Otmar Lendl, Peter Saint-Andre, Richard Shockey, Samuel 3328 Melloul, Scott Hollenbeck, Sumanth Channabasappa, Syed Ali, and Vikas 3329 Bhatia . 3331 14. References 3333 14.1. Normative References 3335 [I-D.draft-ietf-drinks-spp-framework] 3336 Cartwright, K., Bhatia, V., Ali, S., and D. Schwartz, 3337 "Session Peering Provisioning Framework", draft-ietf- 3338 drinks-spp-framework-08 (work in progress), July 2015. 3340 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3341 Requirement Levels", BCP 14, RFC 2119, 3342 DOI 10.17487/RFC2119, March 1997, 3343 . 3345 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 3346 Leach, P., Luotonen, A., and L. Stewart, "HTTP 3347 Authentication: Basic and Digest Access Authentication", 3348 RFC 2617, DOI 10.17487/RFC2617, June 1999, 3349 . 3351 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 3352 DOI 10.17487/RFC3688, January 2004, 3353 . 3355 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 3356 (TLS) Protocol Version 1.2", RFC 5246, 3357 DOI 10.17487/RFC5246, August 2008, 3358 . 3360 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 3361 Protocol (HTTP/1.1): Message Syntax and Routing", 3362 RFC 7230, DOI 10.17487/RFC7230, June 2014, 3363 . 3365 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 3366 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 3367 DOI 10.17487/RFC7231, June 2014, 3368 . 3370 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 3371 "Recommendations for Secure Use of Transport Layer 3372 Security (TLS) and Datagram Transport Layer Security 3373 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 3374 2015, . 3376 [SOAPREF] Gudgin, M., Hadley, M., Moreau, J., and H. Nielsen, "SOAP 3377 Version 1.2 Part 1: Messaging Framework", W3C 3378 Recommendation REC-SOAP12-part1-20030624, June 2002. 3380 14.2. Informative References 3382 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 3383 DOI 10.17487/RFC2818, May 2000, 3384 . 3386 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 3387 DOI 10.17487/RFC5321, October 2008, 3388 . 3390 [W3C.REC-xml-20081126] 3391 Sperberg-McQueen, C., Yergeau, F., Bray, T., Maler, E., 3392 and J. Paoli, "Extensible Markup Language (XML) 1.0 (Fifth 3393 Edition)", World Wide Web Consortium Recommendation REC- 3394 xml-20081126, November 2008, 3395 . 3397 [WSDLREF] Christensen, E., Curbera, F., Meredith, G., and S. 3398 Weerawarana, "Web Services Description Language (WSDL) 3399 1.1", W3C Note NOTE-wsdl-20010315, March 2001. 3401 Authors' Addresses 3403 Kenneth Cartwright 3404 TNS 3405 1939 Roland Clarke Place 3406 Reston, VA 20191 3407 USA 3409 Email: kcartwright@tnsi.com 3410 Vikas Bhatia 3411 TNS 3412 1939 Roland Clarke Place 3413 Reston, VA 20191 3414 USA 3416 Email: vbhatia@tnsi.com 3418 Jean-Francois Mule 3419 CableLabs 3420 858 Coal Creek Circle 3421 Louisville, CO 80027 3422 USA 3424 Email: jfm@cablelabs.com 3426 Alexander Mayrhofer 3427 nic.at GmbH 3428 Karlsplatz 1/2/9 3429 Wien A-1010 3430 Austria 3432 Email: alexander.mayrhofer@nic.at