idnits 2.17.1 draft-ietf-drinks-spp-protocol-over-soap-08.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 (July 22, 2015) is 3201 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 3300, but not defined == Outdated reference: A later version (-12) exists of draft-ietf-drinks-spp-framework-08 ** 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 (~~), 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: January 23, 2016 J-F. Mule 6 CableLabs 7 A. Mayrhofer 8 enum.at GmbH 9 July 22, 2015 11 Session Peering Provisioning (SPP) Protocol over SOAP 12 draft-ietf-drinks-spp-protocol-over-soap-08 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 January 23, 2016. 45 Copyright Notice 47 Copyright (c) 2015 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 Identity Object Key . . . . . . . . . . . . . 9 72 7.1.3. SED Group Offer Key . . . . . . . . . . . . . . . . . 10 73 7.2. Operation Request and Response Structures . . . . . . . . 10 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 . . . . . . . . . . . . . . . 44 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 Identity -- 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 Identity . . . . . . . . . . . . . . . . . . 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 Identity . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . 80 115 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 81 116 14.1. Normative References . . . . . . . . . . . . . . . . . . 81 117 14.2. Informative References . . . . . . . . . . . . . . . . . 81 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 This document RECOMMENDS SOAP 1.2 [SOAPREF] or higher, and WSDL 1.1 252 [WSDLREF] or higher. 254 SPPF is a request/reply framework that allows a client application to 255 submit provisioning data and query requests to a server. The SPPF 256 data structures are designed to be protocol agnostic. Concerns 257 regarding encryption, non-repudiation, and authentication are beyond 258 the scope of this document. For more details, please refer to 259 Section 4 ("Substrate Protocol Requirements") of 260 [I-D.draft-ietf-drinks-spp-framework]. 262 As illustrated in the previous diagram, SPPF can be viewed as a set 263 of layers that collectively define the structure of an SPPF request 264 and response. Layers 1 and 2 represent the transport, envelope, and 265 authentication technologies. This document defines layers 3, 4, 5, 266 and 6 for SPP Protocol over SOAP. 268 1. Layer 1: The transport protocol layer represents the 269 communication mechanism between the client and server. SPPF can 270 be layered over any substrate protocol that provides a set of 271 basic requirements defined in Section 4 of 272 [I-D.draft-ietf-drinks-spp-framework]. 274 2. Layer 2: The message envelope layer is optional, but can provide 275 features that are above the transport technology layer but below 276 the application messaging layer. Technologies such as HTTP and 277 SOAP are examples of messaging envelope technologies. 279 3. Layers 3,4,5,6: The operation and message layers provide an 280 envelope-independent and substrate-independent wrapper for the 281 SPPF data model objects that are being acted on (created, 282 modified, queried). 284 4. HTTP(s) Features and SPP Protocol over SOAP 286 While SOAP is not tied to HTTP(S), for reasons described in the 287 introduction, HTTP(S) is a good choice as the substrate protocol for 288 the SPP Protocol SOAP messages. HTTP 1.1 includes the "persistent 289 connection" feature, which allows multiple HTTP request/response 290 pairs to be transported across a single HTTP connection. This is an 291 important performance optimization feature, particularly when the 292 connections is an HTTPS connection where the relatively time 293 consuming SSL handshake has occurred. 295 Implementations compliant with this document MUST use HTTP 1.1 296 [RFC2616] or higher. Also, implementations SHOULD use persistent 297 connections. 299 5. Authentication, Integrity and Confidentiality 301 To accomplish authentication, conforming SPP Protocol over SOAP 302 Clients and Servers MUST use HTTP Digest Authentication as defined in 303 [RFC2617]. 305 To achieve integrity and privacy, conforming SPP Protocol over SOAP 306 Clients and Servers MUST support Transport Layer Security (TLS) as 307 defined in [RFC5246] as the secure transport mechanism. 309 6. Language Identification 311 Section 9 of [I-D.draft-ietf-drinks-spp-framework] requires protocols 312 to provide a mechanism to transmit language tags together with human- 313 readable messages. When conforming SPP Protocol SOAP servers use 314 such tagging, the XML "lang" attribute ([W3C.REC-xml-20081126], 315 Section 2.12) MUST be used. Clients MAY use the HTTP "Accept- 316 Language" header field (see Section 14.4 of [RFC2616]) in order to 317 indicate their language preference. 319 7. SPP Protocol SOAP Data Structures 321 SPP Protocol over SOAP uses a set of XML based data structures for 322 all the supported operations and any parameters that those operations 323 are applied to. As also mentioned earlier in this document, these 324 XML structures are envelope-independent and substrate-independent. 325 Refer the "Protocol Operations" (Section 8) of this document for a 326 description of all the operations that MUST be supported. 328 The following sections describe the definition all the XML data 329 structures. 331 7.1. Concrete Object Key Types 333 Certain operations in SPPF require an object key that uniquely 334 identifies the object(s) on which a given operation needs to be 335 performed. SPPF defines the XML structure of the any such object key 336 in an abstract manner and delegates the concrete representation to 337 any conforming substrate protocol. The following sub-sections define 338 the various types of concrete object key types used in various 339 operations in SPP Protocol over SOAP. 341 7.1.1. Generic Object Key 343 Most objects in SPP Protocol over SOAP are uniquely identified by the 344 attributes in the generic object key (Refer Section 5.2.1 "Generic 345 Object Key Type" of [I-D.draft-ietf-drinks-spp-framework] for 346 details). The concrete XML representation of ObjKeyType is as below: 348 349 350 351 352 353 354 355 356 357 358 360 The ObjKeyType has the data elements as described below: 362 o rant: The identifier of the registrant organization that owns the 363 object. 365 o name: The character string that contains the name of the object. 367 o type: The enumeration value that represents the type of SPPF 368 object. For example, both a Destination Group and a SED Group can 369 have the same name "TestObj" and be associated with same 370 Registrant Id. Hence, to uniquely identify the object that 371 represents a Destination Group with the name "TestObj", the type 372 "DestGrp" must be specified when using this concrete ObjKeyType 373 structure to identify the Destination Group "TestObj". 375 The object types in SPP Protocol over SOAP MUST adhere to the above 376 definition of generic object key, and are defined as an enumeration 377 in the XML data structure as follows: 379 380 381 382 383 384 385 386 388 7.1.2. Public Identity Object Key 390 Public Identity type objects can further be of various sub-types like 391 a Telephone Number (TN), Routing Number (RN), TN Prefix, URI, or a TN 392 Range and cannot be cleanly identified with the attributes in the 393 generic ObjKeyType. The definition of PubIdKeyType is as below: 395 396 397 398 399 400 401 403 405 407 408 409 410 411 413 The PubIdKeyType has data elements, as described below: 415 o rant: The identifier of the registrant organization that owns the 416 object. 418 o number: An element of type NumberType (refer Section 12 of 419 [I-D.draft-ietf-drinks-spp-framework]) that contains the value and 420 type of a number . 422 o range: An element of type NumberRangeType (refer Section 12 of 423 [I-D.draft-ietf-drinks-spp-framework]) that contains a range of 424 numbers. 426 o uri: A value that represents a Public Identifier. 428 Any instance of PubIdKeyType MUST contain exactly one element from 429 the following set of elements: "number", "range", "uri". 431 7.1.3. SED Group Offer Key 433 In addition to the attributes in the generic ObjKeyType, a SED Group 434 Offer object is uniquely identified by the organization ID of the 435 organization to whom an SED Group has been offered. The definition 436 of SedGrpOfferKeyType is as below: 438 439 440 441 442 443 444 445 446 447 449 The SedGrpOfferKeyType has the data elements as described below: 451 o sedGrpKey: Identifies the SED Group that was offered. 453 o offeredTo: The organization ID of the organization that was 454 offered the SED Group object identified by the sedGrpKey. 456 7.2. Operation Request and Response Structures 458 An SPPF client interacts with an SPPF server by sending one or more 459 requests to the server, and by receiving corresponding responses from 460 the server. The basic set of operations that an SPPF client can 461 submit to an SPPF server and the semantics of those operations are 462 defined in Section 7 ("Framework Operations") of 463 [I-D.draft-ietf-drinks-spp-framework]. The following sub-sections 464 describe the XML data structures that are used for each of those 465 types of operations for a SPP Protocol over SOAP implementation. 467 7.2.1. Add Operation Structure 469 In order to add (or modify) an object in the registry, an authorized 470 entity can send the spppAddRequest to the registry. 472 An SPP Protocol over SOAP Add request is wrapped within the 473 element while an SPP Protocol over SOAP Add response 474 is wrapped within an element. The following sub- 475 sections describe the spppAddRequest and spppAddResponse elements. 476 Refer to Section 10 for an example of Add operation on each type of 477 SPPF object. 479 7.2.1.1. Add Request 481 An SPP Protocol over SOAP Add request definition is contained within 482 the generic element. 484 485 486 487 489 491 493 494 495 497 The data elements within the element are described 498 as follows: 500 o clientTransId: Zero or one client-generated transaction ID that, 501 within the context of the SPPF client, identifies this request. 502 This value can be used at the discretion of the SPPF client to 503 track, log or correlate requests and their responses. SPPF server 504 MUST echo back this value to the client in the corresponding 505 response to the incoming request. SPPF server will not check this 506 value for uniqueness. 508 o minorVer: Zero or one minor version identifier, as defined in 509 Section 7.4. 511 o obj: One or more elements of abstract type BasicObjType (defined 512 in [I-D.draft-ietf-drinks-spp-framework]). Each element contains 513 all the attributes of an SPPF object that that the client is 514 requesting the SPPF server to add. Refer to section 3.1 of 515 [I-D.draft-ietf-drinks-spp-framework] for the XML structure of all 516 concrete types, for various SPPF objects, that extend from 517 abstract BasicObjType and hence are eligible to be passed into 518 this element. The elements are processed by the SPPF server in 519 the order in which they are included in the request. With respect 520 to handling of error conditions, conforming SPPP SOAP servers MUST 521 stop processing BasicObjType elements in the request at the first 522 error, and roll back any BasicObjType elements that had already 523 been processed for that add request ("stop and rollback"). 525 7.2.1.2. Add Response 527 An SPP Protocol over SOAP add response object is contained within the 528 generic element. This response structure is used 529 for all types of SPPF objects that are provisioned by the SPPF 530 client. 532 533 534 535 537 538 539 541 542 543 545 546 547 548 549 550 552 553 554 555 556 557 558 559 560 562 An contains the elements necessary for the SPPF 563 client to precisely determine the overall result of the request, and 564 if an error occurred, it provides information about the specific 565 object(s) that caused the error. 567 The data elements within the SPP Protocol over SOAP Add response are 568 described as follows: 570 o clientTransId: Zero or one client transaction ID. This value is 571 simply an echo of the client transaction ID that SPPF client 572 passed into the SPPF update request. When included in the 573 request, the SPPF server MUST return it in the corresponding 574 response message. 576 o serverTransId: Exactly one server transaction ID that identifies 577 this request for tracking purposes. This value MUST be unique for 578 a given SPPF server. 580 o overallResult: Exactly one response code and message pair that 581 explicitly identifies the result of the request. See Section 7.3 582 for further details. 584 o detailResult: An optional response code, response message, and 585 BasicObjType (as defined in [I-D.draft-ietf-drinks-spp-framework]) 586 triplet. This element will be present only if an object level 587 error has occurred. It indicates the error condition and the 588 exact request object that contributed to the error. The response 589 code will reflect the exact error. See Section 7.3 for further 590 details. 592 7.2.2. Delete Operation Structure 594 In order to remove an object from the registry, an authorized entity 595 can send the spppDelRequest into the registry. An SPP Protocol over 596 SOAP Delete request is wrapped within the element 597 while a SPP Protocol over SOAP Delete response is wrapped within the 598 generic element. The following sub-sections 599 describe the spppDelRequest and spppDelResponse elements. Refer to 600 Section 10 for an example of Delete operation on each type of SPPF 601 object. 603 7.2.2.1. Delete Request 605 An SPP Protocol over SOAP Delete request definition is contained 606 within the generic element. 608 609 610 611 613 615 617 618 619 621 The data elements within the element are described 622 as follows: 624 o clientTransId: Zero or one client-generated transaction ID that, 625 within the context of the SPPF client, identifies this request. 626 This value can be used at the discretion of the SPPF client to 627 track, log or correlate requests and their responses. SPPF server 628 MUST echo back this value to the client in the corresponding 629 response to the incoming request. SPPF server will not check this 630 value for uniqueness. 632 o minorVer: Zero or one minor version identifier, as defined in 633 Section 7.4. 635 o objKey: One or more elements of abstract type ObjKeyType (as 636 defined in [I-D.draft-ietf-drinks-spp-framework]). Each element 637 contains attributes that uniquely identify the object that the 638 client is requesting the server to delete. Refer to Section 7.1 639 for a description of all concrete object key types, for various 640 SPPF objects, which are eligible to be passed into this element. 641 The elements are processed by the SPPF server in the order in 642 which they are included in the request. With respect to handling 643 of error conditions, conforming SPPP SOAP servers MUST stop 644 processing ObjKeyType elements in the request at the first error, 645 and roll back any ObjKeyType elements that had already been 646 processed for that delete request ("stop and rollback"). 648 7.2.2.2. Delete Response 650 An SPP Protocol over SOAP delete response object is contained within 651 the generic element. This response structure is 652 used for a delete request on all types of SPPF objects that are 653 provisioned by the SPPF client. 655 656 657 658 660 661 662 664 665 666 668 669 670 671 672 673 675 676 677 678 679 680 681 682 683 685 An contains the elements necessary for the SPPF 686 client to precisely determine the overall result of the request, and 687 if an error occurred, it provides information about the specific 688 object key(s) that caused the error. 690 The data elements within the SPP Protocol over SOAP Delete response 691 are described as follows: 693 o clientTransId: Zero or one client transaction ID. This value is 694 simply an echo of the client transaction ID that SPPF client 695 passed into the SPPF update request. When included in the 696 request, the SPPF server MUST return it in the corresponding 697 response message. 699 o serverTransId: Exactly one server transaction ID that identifies 700 this request for tracking purposes. This value MUST be unique for 701 a given SPPF server. 703 o overallResult: Exactly one response code and message pair that 704 explicitly identifies the result of the request. See Section 7.3 705 for further details. 707 o detailResult: An optional response code, response message, and 708 ObjKeyType (as defined in [I-D.draft-ietf-drinks-spp-framework]) 709 triplet. This element will be present only if an specific object 710 key level error has occurred. It indicates the error condition 711 and the exact request object key that contributed to the error. 712 The response code will reflect the exact error. See Section 7.3 713 for further details. 715 7.2.3. Accept Operation Structure 717 In SPPF, a SED Group Offer can be accepted or rejected by, or on 718 behalf of, the registrant to whom the SED Group has been offered 719 (refer Section 3.1 of [I-D.draft-ietf-drinks-spp-framework] for a 720 description of the SED Group Offer object). The Accept operation is 721 used to accept such SED Group Offers by, or on behalf of, the 722 Registrant. The request structure for an SPP Protocol over SOAP 723 Accept operation is wrapped within the element 724 while an SPP Protocol over SOAP Accept response is wrapped within the 725 generic element. The following sub-sections 726 describe the spppAcceptRequest and spppAcceptResponse elements. 727 Refer to Section 10 for an example of Accept operation on a SED Group 728 Offer. 730 7.2.3.1. Accept Request Structure 732 An SPP Protocol over SOAP Accept request definition is contained 733 within the generic element. 735 736 737 738 740 742 745 746 747 749 The data elements within the element are 750 described as follows: 752 o clientTransId: Zero or one client-generated transaction ID that, 753 within the context of the SPPF client, identifies this request. 754 This value can be used at the discretion of the SPPF client to 755 track, log or correlate requests and their responses. SPPF server 756 MUST echo back this value to the client in the corresponding 757 response to the incoming request. SPPF server will not check this 758 value for uniqueness. 760 o minorVer: Zero or one minor version identifier, as defined in 761 Section 7.4. 763 o sedGrpOfferKey: One or more elements of type SedGrpOfferKeyType 764 (as defined in this document). Each element contains attributes 765 that uniquely identify a SED Group Offer that the client is 766 requesting the server to accept. The elements are processed by 767 the SPPF server in the order in which they are included in the 768 request. With respect to handling of error conditions, conforming 769 SPPP SOAP servers MUST stop processing SedGrpOfferKeyType elements 770 in the request at the first error, and roll back any 771 SedGrpOfferKeyType elements that had already been processed for 772 that accept request ("stop and rollback"). 774 7.2.3.2. Accept Response 776 An SPP Protocol over SOAP accept response structure is contained 777 within the generic element. This response 778 structure is used for an Accept request on a SED Group Offer. 780 781 782 783 785 786 787 790 791 792 794 795 796 797 798 799 801 802 803 804 805 806 807 808 809 811 An contains the elements necessary for the SPPF 812 client to precisely determine the overall result of the request, and 813 if an error occurred, it provides information about the specific SED 814 Group Offer key(s) that caused the error. 816 The data elements within the SPP Protocol over SOAP Accept response 817 are described as follows: 819 o clientTransId: Zero or one client transaction ID. This value is 820 simply an echo of the client transaction ID that SPPF client 821 passed into the SPPF update request. When included in the 822 request, the SPPF server MUST return it in the corresponding 823 response message. 825 o serverTransId: Exactly one server transaction ID that identifies 826 this request for tracking purposes. This value MUST be unique for 827 a given SPPF server. 829 o overallResult: Exactly one response code and message pair that 830 explicitly identifies the result of the request. See Section 7.3 831 for further details. 833 o detailResult: An optional response code, response message, and 834 SedGrpOfferKeyType (as defined in this document) triplet. This 835 element will be present only if any specific SED Group Offer key 836 level error has occurred. It indicates the error condition and 837 the exact request SED Group Offer key that contributed to the 838 error. The response code will reflect the exact error. See 839 Section 7.3 for further details. 841 7.2.4. Reject Operation Structure 843 In SPPF, SED Group Offer can be accepted or rejected by, or on behalf 844 of, the registrant to whom the SED Group has been offered (refer 845 "Framework Data Model Objects" section of 846 [I-D.draft-ietf-drinks-spp-framework] for a description of the SED 847 Group Offer object). The Reject operation is used to reject such SED 848 Group Offers by, or on behalf of, the Registrant. The request 849 structure for an SPP Protocol over SOAP Reject operation is wrapped 850 within the element while an SPP Protocol over 851 SOAP Reject response is wrapped within the generic 852 element. The following sub-sections describe the 853 spppRejectRequest and spppRejecResponse elements. Refer to 854 Section 10 for an example of Reject operation on a SED Group Offer. 856 7.2.4.1. Reject Request 858 An SPP Protocol over SOAP Reject request definition is contained 859 within the generic element. 861 862 863 864 866 868 871 872 874 The data elements within the element are 875 described as follows: 877 o clientTransId: Zero or one client-generated transaction ID that, 878 within the context of the SPPF client, identifies this request. 879 This value can be used at the discretion of the SPPF client to 880 track, log or correlate requests and their responses. SPPF server 881 MUST echo back this value to the client in the corresponding 882 response to the incoming request. SPPF server will not check this 883 value for uniqueness. 885 o minorVer: Zero or one minor version identifier, as defined in 886 Section 7.4. 888 o sedGrpOfferKey: One or more elements of type SedGrpOfferKeyType 889 (as defined in this document). Each element contains attributes 890 that uniquely identify a SED Group Offer that the client is 891 requesting the server to reject. The elements are processed by 892 the SPPF server in the order in which they are included in the 893 request. With respect to handling of error conditions, conforming 894 SPPF servers MUST stop processing SedGrpOfferKeyType elements in 895 the request at the first error, and roll back any 896 SedGrpOfferKeyType elements that had already been processed for 897 that reject request ("stop and rollback"). 899 7.2.4.2. Reject Response 901 An SPP Protocol over SOAP reject response structure is contained 902 within the generic element. This response 903 structure is used for an Reject request on a SED Group Offer. 905 906 907 908 910 911 912 915 916 917 919 920 921 922 923 924 926 927 928 929 930 931 932 933 934 936 An contains the elements necessary for the SPPF 937 client to precisely determine the overall result of the request, and 938 if an error occurred, it provides information about the specific SED 939 Group Offer key(s) that caused the error. 941 The data elements within the SPP Protocol over SOAP Reject response 942 are described as follows: 944 o clientTransId: Zero or one client transaction ID. This value is 945 simply an echo of the client transaction ID that SPPF client 946 passed into the SPPF update request. When included in the 947 request, the SPPF server MUST return it in the corresponding 948 response message. 950 o serverTransId: Exactly one server transaction ID that identifies 951 this request for tracking purposes. This value MUST be unique for 952 a given SPPF server. 954 o overallResult: Exactly one response code and message pair that 955 explicitly identifies the result of the request. See Section 7.3 956 for further details. 958 o detailResult: An optional response code, response message, and 959 SedGrpOfferKeyType (as defined in this document) triplet. This 960 element will be present only if any specific SED Group Offer key 961 level error has occurred. It indicates the error condition and 962 the exact request SED Group Offer key that contributed to the 963 error. The response code will reflect the exact error. See 964 Section 7.3 for further details. 966 7.2.5. Batch Operation Structure 968 An SPP Protocol over SOAP Batch request XML structure allows the SPPF 969 client to send any of of Add, Del, Accept or Reject operations 970 together in one single request. This gives an SPPF Client the 971 flexibility to use one single request structure to perform more than 972 operations (verbs). The batch request structure is wrapped within 973 the element while a SPPF Batch response is wrapped 974 within the element. This following sub-sections 975 describe the spppBatchRequest and spppBatchResponse elements. Refer 976 to Section 10 for an example of a batch operation. 978 7.2.5.1. Batch Request Structure 980 An SPP Protocol over SOAP Batch request definition is contained 981 within the generic element. 983 984 985 986 988 990 991 992 993 995 997 998 999 1000 1002 The data elements within the element are described 1003 as follows: 1005 o clientTransId: Zero or one client-generated transaction ID that, 1006 within the context of the SPPF Client, identifies this request. 1007 This value can be used at the discretion of the SPPF client to 1008 track, log or correlate requests and their responses. SPPF Server 1009 MUST echo back this value to the Client in the corresponding 1010 response to the incoming request. SPPF Server will not check this 1011 value for uniqueness. 1013 o minorVer: Zero or one minor version identifier, as defined in 1014 Section 7.4. 1016 o addObj: One or more elements of abstract type BasicObjType where 1017 each element identifies an object that needs to be added. 1019 o delObj: One or more elements of abstract type ObjKeyType where 1020 each element identifies a key for the object that needs to be 1021 deleted . 1023 o acceptSedGrpOffer: One or more elements of type SedGrpOfferKeyType 1024 where each element identifies a SED Group Offer that needs to be 1025 accepted. 1027 o rejectSedGrpOffer: One or more elements of type SedGrpOfferKeyType 1028 where each element identifies a SED Group Offer that needs to be 1029 rejected. 1031 With respect to handling of error conditions, conforming SPPP SOAP 1032 servers MUST stop processing elements in the request at the first 1033 error, and roll back any elements that had already been processed for 1034 that batch request ("stop and rollback"). 1036 7.2.5.2. Batch Response 1038 An SPP Protocol over SOAP batch response structure is contained 1039 within the generic element. This response 1040 structure is used for an Batch request that contains many different 1041 types of SPPF operations. 1043 1044 1045 1046 1048 1049 1050 1051 1053 1055 1057 1059 1060 1061 1062 1064 An contains the elements necessary for an SPPF 1065 client to precisely determine the overall result of various 1066 operations in the request, and if an error occurred, it provides 1067 information about the specific objects or keys in the request that 1068 caused the error. 1070 The data elements within the SPP Protocol over SOAP Batch response 1071 are described as follows: 1073 o clientTransId: Zero or one client transaction ID. This value is 1074 simply an echo of the client transaction ID that SPPF client 1075 passed into the SPPF update request. When included in the 1076 request, the SPPF server MUST return it in the corresponding 1077 response message. 1079 o serverTransId: Exactly one server transaction ID that identifies 1080 this request for tracking purposes. This value MUST be unique for 1081 a given SPPF server. 1083 o overallResult: Exactly one response code and message pair that 1084 explicitly identifies the result of the request. See Section 7.3 1085 for further details. 1087 o addResult: One or more elements of type ObjResultCodeType where 1088 each element identifies the result code, result message and the 1089 specific object that the result relates to. 1091 o delResult: One or more elements of type ObjKeyResultCodeType where 1092 each element identifies the result code, result message and the 1093 specific object key that the result relates to. 1095 o acceptResult: One or more elements of type 1096 SedGrpOfferKeyResultCodeType where each element identifies the 1097 result code, result message and the specific SED Group Offer key 1098 that the result relates to. 1100 o rejectResult: One or more elements of type 1101 SedGrpOfferKeyResultCodeType where each element identifies the 1102 result code, result message and the specific SED Group Offer key 1103 that the result relates to. 1105 7.2.6. Get Operation Structure 1107 In order to query the details of an object from the Registry, an 1108 authorized entity can send the spppGetRequest to the registry with a 1109 GetRqstType XML data structure containing one or more object keys 1110 that uniquely identify the object whose details are being queried. 1111 The request structure for an SPP Protocol over SOAP Get operation is 1112 contained within the generic element while an SPP 1113 Protocol over SOAP Get response is wrapped within the generic 1114 element. The following sub-sections describe the 1115 spppGetRequest and spppGetResponse element. Refer to Section 10 for 1116 an example of SPP Protocol over SOAP Get operation on each type of 1117 SPPF object 1119 7.2.6.1. Get Request 1120 1121 1122 1123 1125 1128 1129 1130 1132 The data elements within the element are described 1133 as follows: 1135 o minorVer: Zero or one minor version identifier, as defined in 1136 Section 7.4. 1138 o objKey: One or more elements of abstract type ObjKeyType (as 1139 defined in [I-D.draft-ietf-drinks-spp-framework]). Each element 1140 contains attributes that uniquely identify the object that the 1141 client is requesting the server to query. Refer to Section 7.1 of 1142 this document for a description of all concrete object key types, 1143 for various SPPF objects, which are eligible to be passed into 1144 this element. 1146 7.2.6.2. Get Response 1148 The spppGetResponse element is described in Section 7.2.8. 1150 7.2.7. Get SED Group Offers Operation Structure 1152 In addition to the ability to query the details of one or more SED 1153 Group offers using an a SED Group Offer key in the spppGetRequest, 1154 this operation also provides an additional, more flexible, structure 1155 to query for SED Group Offer objects. This additional structure is 1156 contained within the element while the 1157 response is wrapped within the generic element. 1158 The following sub-sections describe the getSedGrpOffersRequest and 1159 spppGetResponse elements. 1161 7.2.7.1. Get SED Group Offers Request 1163 Using the details passed into this structure, the server will attempt 1164 to find SED Group Offer objects that satisfy all the criteria passed 1165 into the request. If no criteria is passed in then the SPPF Server 1166 will return the list of SED Group Offer objects that belongs to the 1167 registrant. If there are no matching SED Group Offers found then an 1168 empty result set will be returned. 1170 1171 1172 1173 1175 1177 1179 1181 1183 1184 1185 1187 The data elements within the element are 1188 described as follows: 1190 o minorVer: Zero or one minor version identifier, as defined in 1191 Section 7.4. 1193 o offeredBy: Zero or more organization IDs. Only offers that are 1194 offered to the organization IDs in this list should be included in 1195 the result set. The result set is also subject to other query 1196 criteria in the request. 1198 o offeredTo: Zero or more organization IDs. Only offers that are 1199 offered by the organization IDs in this list should be included in 1200 the result set. The result set is also subject to other query 1201 criteria in the request. 1203 o status: The status of the offer, offered or accepted. Only offers 1204 in the specified status should be included in the result set. If 1205 this element is not present then the status of the offer should 1206 not be considered in the query. The result set is also subject to 1207 other query criteria in the request. 1209 o sedGrpOfferKey: Zero or more SED Group Offer Keys. Only offers 1210 having one of these keys should be included in the result set. 1211 The result set is also subject to other query criteria in the 1212 request. 1214 7.2.7.2. Get SED Group Offers Response 1216 The spppGetResponse element is described in Section 7.2.8. 1218 7.2.8. Generic Query Response 1220 An SPP Protocol over SOAP query response object is contained within 1221 the generic element. 1223 1224 1225 1226 1228 1231 1232 1233 1235 An contains the elements necessary for the SPPF 1236 client to precisely determine the overall result of the query, and 1237 details of any SPPF objects that matched the criteria in the request. 1239 The data elements within the SPP Protocol over SOAP query response 1240 are described as follows: 1242 o overallResult: Exactly one response code and message pair that 1243 explicitly identifies the result of the request. See Section 7.3 1244 for further details. 1246 o resultObj: The set of zero or more objects that matched the query 1247 criteria. If no objects matched the query criteria then the 1248 result object(s) MUST be empty and the overallResult value MUST 1249 indicate success (if no matches are found for the query criteria, 1250 the response is considered a success). 1252 7.2.9. Get Server Details Operation Structure 1254 In order to query certain details of the SPPF server, such as the 1255 SPPF server's status and the major/minor version supported by the 1256 server, the Server Details operation structure SHOULD be used. This 1257 structure is contained within the element 1258 whereas a SPPF server status response is wrapped within the 1259 element. The following sub-sections 1260 describe the spppServerStatusRequest and spppServerStatusResponse 1261 elements. 1263 7.2.9.1. Get Server Details Request 1265 1266 1267 1268 1270 1271 1272 1274 The data elements within the element are 1275 described as follows: 1277 o minorVer: Zero or one minor version identifier, as defined in 1278 Section 7.4. 1280 7.2.9.2. Get Server Details Response 1282 An SPP Protocol over SOAP server details response structure is 1283 contained within the generic element. 1285 1286 1287 1288 1289 1290 1291 1292 1294 The data elements within the element are 1295 described as follows: 1297 o overallResult: Exactly one response code and message pair that 1298 explicitly identifies the result of the request. See Section 7.3 1299 for further details. 1301 o svcMenu: Exactly one element of type SvcMenuType which in turn 1302 contains the elements to return the server status, the major and 1303 minor versions of the SPP Protocol over SOAP supported by the SPPF 1304 server (refer Section 12 of [I-D.draft-ietf-drinks-spp-framework] 1305 for definition of SvcMenuType). 1307 7.3. Response Codes and Messages 1309 This section contains the listing of response codes and their 1310 corresponding human-readable text. These response codes are in 1311 conformance with the response types defined in Section 5.3 of 1312 [I-D.draft-ietf-drinks-spp-framework]. 1314 The response code numbering scheme generally adheres to the theory 1315 formalized in section 4.2.1 of [RFC5321]: 1317 o The first digit of the response code can only be 1 or 2: 1 = a 1318 positive result, 2 = a negative result. 1320 o The second digit of the response code indicates the category: 0 = 1321 Protocol Syntax, 1 = Implementation Specific Business Rule, 2 = 1322 Security, 3 = Server System. 1324 o The third and fourth digits of the response code indicate the 1325 individual message event within the category defines by the first 1326 two digits. 1328 The response codes are also categorized as to whether they are 1329 overall response codes that may only be returned in the 1330 "overallResult" data element in SPPF responses, or object level 1331 response codes that may only be returned in the "detailResult" 1332 element of the SPPF responses. 1334 +--------+--------------------------+-------------------------------+ 1335 | Result | Result Message | Overall or Object Level | 1336 | Code | | | 1337 +--------+--------------------------+-------------------------------+ 1338 | 1000 | Request Succeeded. | Overall Response Code | 1339 | | | | 1340 | 2000 | Request syntax invalid. | Overall Response Code | 1341 | | | | 1342 | 2001 | Request too large. | Overall Response Code | 1343 | | MaxSupported:[Maximum | | 1344 | | requests supported] | | 1345 | | | | 1346 | 2002 | Version not supported. | Overall Response Code | 1347 | | | | 1348 | 2100 | Command invalid. | Overall Response Code | 1349 | | | | 1350 | 2300 | System temporarily | Overall Response Code | 1351 | | unavailable. | | 1352 | | | | 1353 | 2301 | Unexpected internal | Overall Response Code | 1354 | | system or server error. | | 1355 | | | | 1356 | 2101 | Attribute value invalid. | Object Level Response Code | 1357 | | AttrName:[AttributeName] | | 1358 | | AttrVal:[AttributeValue] | | 1359 | | | | 1360 | 2102 | Object does not exist. | Object Level Response Code | 1361 | | AttrName:[AttributeName] | | 1362 | | AttrVal:[AttributeValue] | | 1363 | | | | 1364 | 2103 | Object status or | Object Level Response Code | 1365 | | ownership does not allow | | 1366 | | for operation. | | 1367 | | AttrName:[AttributeName] | | 1368 | | AttrVal:[AttributeValue] | | 1369 +--------+--------------------------+-------------------------------+ 1371 Table 1: Response Codes Numbering Scheme and Messages 1373 Response message for response code 2001 is "parameterized" with the 1374 following parameter: "[Maximum requests supported]". When the 1375 request is too large, this parameter MUST be used to indicate the 1376 maximum number of requests supported by the server in a single 1377 protocol operation. 1379 Each of the object level response messages are "parameterized" with 1380 the following parameters: "AttributeName" and "AttributeValue". 1382 For example, if an SPPF client sends a request to delete a 1383 Destination Group with a name "TestDG", and it does not already 1384 exist, then the error message returned should be: "Attribute value 1385 invalid. AttrName:dgName AttrVal:TestDG". 1387 The use of these parameters MUST adhere to the rules defined in 1388 Section 5.3 of [I-D.draft-ietf-drinks-spp-framework]. 1390 7.4. Minor Version Identifier 1392 The minor version identifier element is defined as follows: 1394 o minorVer: Zero or one minor version identifier, indicating the 1395 minor version of the SPP Protocol over SOAP API that the client is 1396 attempting to use. This is used in conjunction with the major 1397 version identifier in the XML namespace to identify the version of 1398 SPP Protocol over SOAP that the client is using. If the element 1399 is not present, the server assumes that the client is using the 1400 latest minor version of SPP Protocol over SOAP supported by the 1401 SPPF server for the given major version. The versions of SPP 1402 Protocol over SOAP supported by a given SPPF server can be 1403 retrieved by the client using this same spppServerStatusRequest 1404 without passing in the minorVer element. 1406 8. Protocol Operations 1408 Refer to Section 7 of [I-D.draft-ietf-drinks-spp-framework] for a 1409 description of all SPPF operations, and any necessary semantics that 1410 MUST be adhered to in order to conform with SPPF. 1412 9. SPP Protocol over SOAP WSDL Definition 1414 The SPP Protocol over SOAP WSDL and data types are defined below. 1415 The WSDL design approach is commonly referred to as "Generic WSDL". 1416 It is generic in the sense that there is not a specific WSDL 1417 operation defined for each object type that is supported by the SPPF 1418 protocol. There is a single WSDL structure for each type of SPPF 1419 operation. Each such WSDL structure contains exactly one input 1420 structure and one output structure that wraps any data elements that 1421 are part of the incoming request and the outgoing response 1422 respectively. The spppSOAPBinding in the WSDL defines the binding 1423 style as "document" and the encoding as "literal". It is this 1424 combination of "wrapped" input and output data structures, "document" 1425 binding style, and "literal" encoding that characterize the Document 1426 Literal Wrapped style of WSDL specifications. 1428 Notes: The following WSDL has been formatted (e.g. tabs, spaces) to 1429 meet IETF document requirements. Deployments MUST replace 1430 "REPLACE_WITH_ACTUAL_URL" in the WSDL below with the URI of the SPPF 1431 Server instance. 1433 1434 1441 1442 1445 1446 1447 ---- Import base schema ---- 1448 1449 1450 1452 1453 1454 ---- Key type(s) extended 1455 from base schema. ---- 1456 1457 1458 1459 1460 1461 1462 1463 1464 1465 1466 1467 1468 1469 1470 1471 1472 1473 1474 1475 1476 1477 1478 1479 1480 1481 1483 1485 1486 1487 1488 1490 1491 1492 1493 1494 1495 1496 1498 1500 1501 1502 1503 1504 1506 1507 1508 ---- Generic Request and 1509 Response Definitions ---- 1510 1511 1512 1513 1514 1515 1517 1519 1521 1522 1523 1524 1525 1526 1527 1529 1531 1533 1534 1535 1536 1537 1538 1539 1541 1543 1546 1547 1548 1549 1550 1551 1552 1554 1556 1559 1560 1561 1562 1563 1564 1565 1567 1570 1571 1572 1573 1574 1575 1576 1578 1580 1581 1582 1583 1585 1587 1588 1589 1590 1591 1592 1593 1594 1596 1597 1598 1599 1600 1601 1602 1604 1607 1609 1611 1614 1615 1616 1617 1618 1619 1620 1622 1624 1626 1629 1630 1631 1632 1633 1634 1635 1637 1639 1641 1644 1645 1646 1647 1648 1649 1650 1652 1654 1656 1659 1660 1661 1662 1663 1664 1665 1667 1669 1671 1674 1675 1676 1677 1678 1679 1680 1682 1684 1686 1687 1689 1691 1693 1695 1696 1697 1698 1699 1700 1701 1702 1704 1707 1708 1709 1710 1711 1712 1713 1715 1718 1719 1720 1721 1722 1723 ---- Operation Result Type 1724 Definitions ---- 1725 1726 1727 1728 1729 1730 1731 1732 1734 1735 1736 1737 1738 1739 1740 1741 1742 1743 1744 1745 1746 1747 1749 1750 1751 1752 1753 1754 1756 1757 1758 1759 1760 1761 1762 1763 1764 1765 1766 1767 1768 1769 1770 1771 1772 1773 1774 1775 1776 1777 1778 1780 1781 1782 1783 1784 1785 1786 1787 1788 1789 1790 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 1823 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 1868 1869 1870 1871 1872 1873 1874 1875 1876 1877 1878 1879 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 1920 1921 1922 1923 1925 1926 1927 1928 1929 1930 1931 1932 1933 1935 1936 1937 1938 1939 1940 1941 1942 1943 1944 1945 1946 1947 1948 1950 Figure 2: WSDL 1952 10. SPP Protocol over SOAP Examples 1954 This section shows XML message exchange between two SIP Service 1955 Providers (SSP) and a registry. The messages in this section are 1956 valid XML instances that conform to the SPP Protocol over SOAP schema 1957 version within this document. This section also relies on the XML 1958 data structures defined in the SPPF specification 1959 [I-D.draft-ietf-drinks-spp-framework]. Which should also be 1960 referenced to understand XML object types embedded in these example 1961 messages. 1963 In this sample use case scenario, SSP1 and SSP2 provision resource 1964 data in the registry and use SPPF constructs to selectively share the 1965 SED groups. In the figure below, SSP2 has two ingress SBE instances 1966 that are associated with the public identities that SSP2 has the 1967 retail relationship with. Also, the two Session Border Element 1968 instances for SSP1 are used to show how to use SPPF to associate 1969 route preferences for the destination ingress routes and exercise 1970 greater control on outbound traffic to the peer's ingress SBEs. 1972 ---------------+ +------------------ 1973 | | 1974 +------+ +------+ 1975 | sbe1 | | sbe2 | 1976 +------+ +------+ 1977 SSP1 | | SSP2 1978 +------+ +------+ 1979 | sbe3 | | sbe4 | 1980 +------+ +------+ 1981 iana-en:111 | | iana-en:222 1982 ---------------+ +------------------ 1983 | | 1984 | | 1985 | SPPF +------------------+ SPPF | 1986 +------->| Registry |<--------+ 1987 +------------------+ 1989 10.1. Add Destination Group 1991 SSP2 adds a destination group to the registry for use later. The 1992 SSP2 SPPF client sets a unique transaction identifier 'txn_1479' for 1993 tracking purposes. The name of the destination group is set to 1994 DEST_GRP_SSP2_1 1995 1996 2001 2002 2003 2004 2005 txn_1479 2006 2007 2008 iana-en:222 2009 iana-en:223 2010 DEST_GRP_SSP2_1 2011 2012 2013 2014 2016 The registry processes the request and return a favorable response 2017 confirming successful creation of the named destination group. Also, 2018 besides returning a unique server transaction identifier, Registry 2019 also returns the matching client transaction identifier from the 2020 request message back to the SPPF client. 2022 2023 2025 2026 2029 txn_1479 2030 tx_12345 2031 2032 1000 2033 Request Succeeded. 2034 2035 2036 2037 2039 10.2. Add SED Records 2041 SSP2 adds SED records in the form of ingress routes to the registry. 2043 2044 2049 2050 2051 2052 2053 txn_1479 2054 2055 2056 iana-en:222 2057 iana-en:223 2058 SED_SSP2_SBE2 2059 true 2060 10 2061 u 2062 E2U+sip 2063 2064 ^(.*)$ 2065 sip:\1@sbe2.ssp2.example.com 2066 2067 2068 2069 2070 2072 The registry returns a success response. 2074 2075 2077 2078 2081 txn_1479 2082 tx_12345 2083 2084 1000 2085 Request Succeeded. 2086 2087 2088 2089 2091 10.3. Add SED Records -- URIType 2093 SSP2 adds another SED record to the registry and makes use of URIType 2095 2096 2101 2102 2103 2104 txn_1479 2105 2106 2107 iana-en:222 2108 iana-en:223 2109 SED_SSP2_SBE4 2110 true 2111 ^(.*)$ 2112 sip:\1;npdi@sbe4.ssp2.example.com 2113 2114 2115 2116 2118 The registry returns a success response. 2120 2121 2122 2123 2126 txn_1479 2127 tx_12345 2128 2129 1000 2130 Request Succeeded. 2131 2132 2133 2134 2136 10.4. Add SED Group 2138 SSP2 creates the grouping of SED records (e.g. ingress routes) and 2139 chooses higher precedence for SED_SSP2_SBE2 by setting a lower number 2140 for the "priority" attribute, a protocol agnostic precedence 2141 indicator. 2143 2144 2149 2150 2151 2152 txn_1479 2153 2154 2155 iana-en:222 2156 iana-en:223 2157 SED_GRP_SSP2_1 2158 2159 2160 iana-en:222 2161 SED_SSP2_SBE2 2162 SedRec 2163 2164 100 2165 2166 DEST_GRP_SSP2_1 2167 true 2168 10 2169 2170 2171 2172 2174 To confirm successful processing of this request, registry returns a 2175 well-known result code '1000' to the SSP2 client. 2177 2178 2179 2180 2183 txn_1479 2184 tx_12345 2185 2186 1000 2187 Request Succeeded. 2188 2189 2190 2191 2193 10.5. Add Public Identity -- Successful COR claim 2195 SSP2 activates a TN public identity by associating it with a valid 2196 destination group. Further, SSP2 puts forth a claim that it is the 2197 carrier-of-record for the TN. 2199 2204 2205 2206 2207 txn_1479 2208 2209 2210 iana-en:222 2211 iana-en:223 2212 DEST_GRP_SSP2_1 2213 +12025556666 2214 2215 true 2216 2217 2218 2219 2220 2221 Assuming that the registry has access to TN authority data and it 2222 performs the required checks to verify that SSP2 is in fact the 2223 service provider of record for the given TN, the request is processed 2224 successfully. In the response message, the registry sets the value 2225 of to "true" in order to confirm SSP2 claim as the carrier of 2226 record and the reflects the time when the carrier of record 2227 claim is processed. 2229 2230 2233 2234 2237 txn_1479 2238 tx_12345 2239 2240 1000 2241 Request Succeeded. 2242 2243 2244 1000 2245 Request Succeeded. 2246 2247 iana-en:222 2248 iana-en:223 2249 2010-05-30T09:30:10Z 2250 DEST_GRP_SSP2_1 2251 +12025556666 2252 2253 true 2254 true 2255 2010-05-30T09:30:11Z 2256 2257 2258 2259 2260 2261 2263 10.6. Add LRN 2265 If another entity that SSP2 shares session establishment information 2266 (e.g. routes) with has access to Number Portability data, it may 2267 choose to perform route lookups by routing number. Therefore, SSP2 2268 associates a routing number to a destination group in order to 2269 facilitate ingress route discovery. 2271 2272 2277 2278 2279 2280 txn_1479 2281 2282 2283 iana-en:222 2284 iana-en:223 2285 DEST_GRP_SSP2_1 2286 2025550000 2287 2288 2289 2290 2292 Registry completes the request successfully and returns a favorable 2293 response to the SPPF client. 2295 2296 2298 2299 2302 txn_1479 2303 tx_12345 2304 2305 1000 2306 Request Succeeded. 2307 2308 2309 2310 2312 10.7. Add TN Range 2314 Next, SSP2 activates a block of ten thousand TNs and associate it to 2315 a destination group. 2317 2318 2323 2324 2325 2326 txn_1479 2327 2328 2329 iana-en:222 2330 iana-en:223 2331 DEST_GRP_SSP2_1 2332 2333 +12026660000 2334 +12026669999 2335 2336 2337 2338 2339 2340 Registry completes the request successfully and returns a favorable 2341 response. 2343 2344 2346 2347 2350 txn_1479 2351 tx_12345 2352 2353 1000 2354 Request Succeeded. 2355 2356 2357 2358 2360 10.8. Add TN Prefix 2362 Next, SSP2 activates a block of ten thousand TNs using the TNPType 2363 structure and identifying a TN prefix. 2365 2366 2371 2372 2373 2374 txn_1479 2375 2376 2377 iana-en:222 2378 iana-en:223 2379 DEST_GRP_SSP2_1 2380 +1202777 2381 2382 2383 2384 2386 Registry completes the request successfully and returns a favorable 2387 response. 2389 2390 2392 2393 2396 txn_1479 2397 tx_12345 2398 2399 1000 2400 Request Succeeded. 2401 2402 2403 2404 2406 10.9. Enable Peering -- SED Group Offer 2408 In order for SSP1 to complete session establishment for a destination 2409 TN where the target subscriber has a retail relationship with SSP2, 2410 it first requires an asynchronous bi-directional handshake to show 2411 mutual consent. To start the process, SSP2 initiates the peering 2412 handshake by offering SSP1 access to its SED group. 2414 2415 2420 2421 2422 2423 txn_1479 2424 2425 2426 iana-en:222 2427 iana-en:223 2428 2429 2430 iana-en:222 2431 SED_GRP_SSP2_1 2432 SedGrp 2433 2434 iana-en:111 2435 2436 offered 2437 2438 2006-05-04T18:13:51.0Z 2439 2440 2441 2442 2443 2445 Registry completes the request successfully and confirms that the 2446 SSP1 will now have the opportunity to weigh in on the offer and 2447 either accept or reject it. The registry may employ out-of-band 2448 notification mechanisms for quicker updates to SSP1 so they can act 2449 faster, though this topic is beyond the scope of this document. 2451 2452 2454 2455 2458 txn_1479 2459 tx_12345 2460 2461 1000 2462 Request Succeeded. 2463 2464 2465 2466 2468 10.10. Enable Peering -- SED Group Offer Accept 2470 SSP1 responds to the offer from SSP2 and agrees to have visibility to 2471 SSP2 session establishment information (e.g. ingress routes). 2473 2474 2477 2478 2479 2480 2481 txn_1479 2482 2483 2484 2485 iana-en:222 2486 SED_GRP_SSP2_1 2487 SedGrp 2488 2489 iana-en:111 2490 2491 2492 2493 2494 Registry confirms that the request has been processed successfully. 2495 From this point forward, if SSP1 looks up a public identity through 2496 the query resolution server, where the public identity is part of the 2497 destination group by way of "SED_GRP_SSP2_1" session establishment 2498 data association, SSP2 ingress SBE information will be shared with 2499 SSP1. 2501 2502 2504 2505 2508 txn_1479 2509 tx_12350 2510 2511 1000 2512 Request Succeeded. 2513 2514 2515 2516 2518 10.11. Add Egress Route 2520 SSP1 wants to prioritize all outbound traffic to the ingress route 2521 associated with the "SED_GRP_SSP2_1" SED Group record, through 2522 "sbe1.ssp1.example.com". 2524 2525 2530 2531 2532 2533 txn_1479 2534 2535 2536 iana-en:222 2537 iana-en:223 2538 EGR_RTE_01 2539 50 2540 2541 ^(.*@)(.*)$ 2542 \1\2?route=sbe1.ssp1.example.com 2543 2544 2545 iana-en:222 2546 SED_GRP_SSP2_1 2547 SedGrp 2548 2549 2550 2551 2552 2554 Since peering has already been established, the request to add the 2555 egress route has been successfully completed. 2557 2558 2560 2561 2564 txn_1479 2565 tx_12345 2566 2567 1000 2568 Request Succeeded. 2569 2570 2571 2572 2574 10.12. Remove Peering -- SED Group Offer Reject 2576 SSP1 had earlier accepted to have visibility to SSP2 session 2577 establishment data. SSP1 now decides to no longer maintain this 2578 visibility and hence rejects the SED Group Offer. 2580 2581 2584 2585 2586 2587 2588 txn_1479 2589 2590 2591 2592 iana-en:222 2593 SED_GRP_SSP2_1 2594 SedGrp 2595 2596 iana-en:111 2597 2598 2599 2600 2601 Registry confirms that the request has been processed successfully. 2602 From this point forward, if SSP1 looks up a public identity through 2603 the query resolution server, where the public identity is part of the 2604 destination group by way of "SED_GRP_SSP2_1" session establishment 2605 data association, SSP2 ingress SBE information will not be shared 2606 with SSP1 and hence SSP2 ingress SBE will not be returned in the 2607 query response. 2609 2610 2612 2613 2616 txn_1479 2617 tx_12350 2618 2619 1000 2620 Request Succeeded. 2621 2622 2623 2624 2626 10.13. Get Destination Group 2628 SSP2 uses the 'spppGetRequest' operation to tally the last 2629 provisioned record for destination group DEST_GRP_SSP2_1. 2631 2632 2636 2637 2638 2639 2640 2641 iana-en:222 2642 DEST_GRP_SSP2_1 2643 DestGrp 2644 2645 2646 2647 2649 Registry completes the request successfully and returns a favorable 2650 response. 2652 2653 2656 2657 2660 2661 1000 2662 success 2663 2664 2665 iana-en:222 2666 iana-en:223 2667 2012-10-22T09:30:10Z 2668 DEST_GRP_SSP2_1 2669 2670 2671 2672 2674 10.14. Get Public Identity 2676 SSP2 obtains the last provisioned record associated with a given TN. 2678 2679 2684 2685 2686 2687 2688 2689 iana-en:222 2690 2691 +12025556666 2692 TN 2693 2694 2695 2696 2697 2699 Registry completes the request successfully and returns a favorable 2700 response. 2702 2705 2706 2709 2710 1000 2711 success 2712 2713 2714 iana-en:222 2715 iana-en:223 2716 2012-10-22T09:30:10Z 2717 DEST_GRP_SSP2_1 2718 +12025556666 2719 2720 true 2721 true 2722 2010-05-30T09:30:10Z 2723 2724 2725 2726 2727 2729 10.15. Get SED Group Request 2731 SSP2 obtains the last provisioned record for the SED group 2732 SED_GRP_SSP2_1. 2734 2735 2739 2740 2741 2742 2743 2744 iana-en:222 2745 SED_GRP_SSP2_1 2746 SedGrp 2747 2748 2749 2750 2752 Registry completes the request successfully and returns a favorable 2753 response. 2755 2756 2759 2760 2763 2764 1000 2765 success 2766 2767 2768 iana-en:222 2769 iana-en:223 2770 2012-10-22T09:30:10Z 2771 SED_GRP_SSP2_1 2772 2773 2774 iana-en:222 2775 SED_SSP2_SBE2 2776 SedRec 2777 2778 100 2779 2780 2781 2782 iana-en:222 2783 SED_SSP2_SBE4 2784 SedRec 2785 2786 101 2787 2788 DEST_GRP_SSP2_1 2789 true 2790 10 2791 2792 2793 2794 2796 10.16. Get SED Group Offers Request 2798 SSP2 fetches the last provisioned SED group offer to the 2799 SSP1. 2801 2802 2805 2806 2807 2808 iana-en:111 2809 2810 2811 2813 Registry processes the request successfully and returns a favorable 2814 response. 2816 2817 2820 2821 2824 2825 1000 2826 success 2827 2828 2829 iana-en:222 2830 iana-en:223 2831 2012-10-22T09:30:10Z 2832 2834 2835 iana-en:222 2836 SED_GRP_SSP2_1 2837 SedGrp 2838 2839 iana-en:111 2840 2841 offered 2842 2843 2006-05-04T18:13:51.0Z 2844 2845 2846 2847 2848 2850 10.17. Get Egress Route 2852 SSP1 wants to verify the last provisioned record for the egress route 2853 called EGR_RTE_01. 2855 2856 2860 2861 2862 2863 2864 2865 iana-en:111 2866 EGR_RTE_01 2867 EgrRte 2868 2869 2870 2871 2873 Registry completes the request successfully and returns a favorable 2874 response. 2876 2877 2880 2881 2884 2885 1000 2886 success 2887 2888 2889 iana-en:222 2890 iana-en:223 2891 2012-10-22T09:30:10Z 2892 EGR_RTE_01 2893 50 2894 2895 ^(.*)$ 2896 sip:\1@sbe1.ssp1.example.com 2897 2898 2899 iana-en:222 2900 SED_GRP_SSP2_1 2901 SedRec 2902 2903 2904 2905 2906 2908 10.18. Delete Destination Group 2910 SSP2 initiates a request to delete the destination group 2911 DEST_GRP_SSP2_1. 2913 2914 2918 2919 2920 2921 2922 2923 iana-en:222 2924 DEST_GRP_SSP2_1 2925 DestGrp 2926 2927 2928 2929 2931 Registry completes the request successfully and returns a favorable 2932 response. 2934 2935 2937 2938 2941 tx_12354 2942 2943 1000 2944 Request Succeeded. 2945 2946 2947 2948 2950 10.19. Delete Public Identity 2952 SSP2 chooses to de-activate the TN and remove it from the registry. 2954 2955 2960 2961 2962 2963 2964 2965 iana-en:222 2966 2967 +12025556666 2968 TN 2969 2970 2971 2972 2973 2975 Registry completes the request successfully and returns a favorable 2976 response. 2978 2979 2981 2982 2985 tx_12354 2986 2987 1000 2988 Request Succeeded. 2989 2990 2991 2992 2994 10.20. Delete SED Group Request 2996 SSP2 removes the SED group called SED_GRP_SSP2_1. 2998 2999 3003 3004 3005 3006 3007 3008 iana-en:222 3009 SED_GRP_SSP2_1 3010 SedGrp 3011 3012 3013 3014 3016 Registry completes the request successfully and returns a favorable 3017 response. 3019 3020 3022 3023 3026 tx_12354 3027 3028 1000 3029 Request Succeeded. 3030 3031 3032 3033 3035 10.21. Delete SED Group Offers Request 3037 SSP2 no longer wants to share SED group SED_GRP_SSP2_1 with SSP1. 3039 3040 3044 3045 3046 3047 3048 3049 3050 iana-en:222 3051 SED_GRP_SSP2_1 3052 SedGrp 3053 3054 iana-en:111 3055 3056 3057 3058 3060 Registry completes the request successfully and returns a favorable 3061 response. Restoring this resource sharing will require a new SED 3062 group offer from SSP2 to SSP1 followed by a successful SED group 3063 accept request from SSP1. 3065 3066 3068 3069 3072 tx_12354 3073 3074 1000 3075 Request Succeeded. 3076 3077 3078 3079 3081 10.22. Delete Egress Route 3083 SSP1 decides to remove the egress route with the label EGR_RTE_01. 3085 3086 3090 3091 3092 3093 3094 3095 iana-en:111 3096 EGR_RTE_01 3097 EgrRte 3098 3099 3100 3101 3103 Registry completes the request successfully and returns a favorable 3104 response. 3106 3107 3109 3110 3113 tx_12354 3114 3115 1000 3116 Request Succeeded. 3117 3118 3119 3120 3122 10.23. Batch Request 3124 Following is an example of how some of the operations mentioned in 3125 previous sections MAY be performed by an SPPF client as a batch in 3126 one single SPP Protocol over SOAP request. 3128 In the sample request below SSP1 wants to accept a SED Group Offer 3129 from SSP3, add a Destination Group, add a NAPTR SED Record, add a SED 3130 Group, add a SED Group Offer, delete a previously provisioned TN type 3131 Public Identifier, delete a previously provisioned SED Group, and 3132 reject a SED Group Offer from SSP4. 3134 3135 3140 3141 3142 3143 txn_1467 3144 1 3146 3147 3148 iana-en:225 3149 SED_SSP3_SBE1_Offered 3150 SedGrp 3151 3152 iana-en:222 3153 3155 3156 iana-en:222 3157 iana-en:223 3158 DEST_GRP_SSP2_1 3159 3161 3162 iana-en:222 3163 iana-en:223 3164 SED_SSP2_SBE2 3165 10 3166 u 3167 E2U+sip 3168 3169 ^(.*)$ 3170 sip:\1@sbe2.ssp2.example.com 3171 3172 3174 3175 iana-en:222 3176 iana-en:223 3177 SED_GRP_SSP2_1 3178 3179 3180 iana-en:222 3181 SED_SSP2_SBE2 3182 SedRec 3183 3184 100 3185 3186 DEST_GRP_SSP2_1 3187 true 3188 10 3189 3191 3192 iana-en:222 3193 iana-en:223 3194 3195 3196 iana-en:222 3197 SED_GRP_SSP2_1 3198 SedGrp 3199 3200 iana-en:111 3201 3202 offered 3203 3204 2006-05-04T18:13:51.0Z 3205 3206 3208 3209 iana-en:222 3210 3211 +12025556666 3212 TN 3213 3214 3216 3217 iana-en:222 3218 SED_GRP_SSP2_Previous 3219 SedGrp 3220 3222 3223 3224 iana-en:226 3225 SED_SSP4_SBE1_Offered 3226 SedGrp 3227 3228 iana-en:222 3229 3231 3232 3233 3235 Registry completes the request successfully and returns a favorable 3236 response. 3238 3239 3241 3242 3245 tx_12354 3246 3247 1000 3248 Request Succeeded. 3249 3250 3251 3252 3254 11. Security Considerations 3256 SPP Protocol over SOAP is used to query and update session peering 3257 data and addresses, so the ability to access this protocol should be 3258 limited to users and systems that are authorized to query and update 3259 this data. Because this data is sent in both directions, it may not 3260 be sufficient for just the client or user to be authenticated with 3261 the server. The identity of the server should also be authenticated 3262 by the client, which is often accomplished using the TLS certificate 3263 exchange and validation described in [RFC2818]. 3265 11.1. Vulnerabilities 3267 Section 5 describes the use of HTTP and TLS as the underlying 3268 substrate protocols for SPP Protocol over SOAP. These underlying 3269 protocols may have various vulnerabilities, and these may be 3270 inherited by SPP Protocol over SOAP. SPP Protocol over SOAP itself 3271 may have vulnerabilities because an authorization model is not 3272 explicitly specified in this document. 3274 During a TLS handshake, TLS servers can optionally request a 3275 certificate from a TLS client; that option is not a requirement for 3276 this protocol. This presents a denial of service risk in which 3277 unauthenticated clients can consume server CPU resources by creating 3278 TLS sessions. The risk is increased if the server supports client- 3279 initiated renegotiation. This risk can be mitigated by disabling 3280 client-initiated renegotiation on the server and by ensuring that 3281 other means (such as firewall access control lists) are used to 3282 restrict unauthenticated client access to servers. 3284 In conjunction with the above, it is important that SPP Protocol over 3285 SOAP implementations implement an authorization model that considers 3286 the source of each query or update request and determines whether it 3287 is reasonable to authorize that source to perform that specific query 3288 or update. 3290 12. IANA Considerations 3292 This document uses URNs to describe XML Namespaces and XML Schemas. 3293 According to [RFC3688], IANA is requested to perform the following 3294 URN assignment: 3296 URN: urn:ietf:params:xml:ns:sppf:soap:1 3298 Registrant Contact: IESG 3300 XML: See Section 9 of [THISDOCUMENT] 3302 13. Acknowledgements 3304 This document is a result of various discussions held with the IETF 3305 DRINKS working group, specifically the protocol design team, with 3306 contributions from the following individuals, in alphabetical order: 3307 Alexander Mayrhofer, David Schwartz, Deborah A Guyton, Jean-Francois 3308 Mule Kenneth Cartwright, Lisa Dusseault, Manjul Maharishi, Mickael 3309 Marrache, Otmar Lendl, Peter Saint-Andre, Richard Shockey, Samuel 3310 Melloul, Scott Hollenbeck, Sumanth Channabasappa, Syed Ali, and Vikas 3311 Bhatia . 3313 14. References 3315 14.1. Normative References 3317 [I-D.draft-ietf-drinks-spp-framework] 3318 Cartwright, K., Bhatia, V., Ali, S., and D. Schwartz, 3319 "Session Peering Provisioning Framework", draft-ietf- 3320 drinks-spp-framework-08 (work in progress), July 2015. 3322 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3323 Requirement Levels", BCP 14, RFC 2119, March 1997. 3325 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 3326 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 3327 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 3329 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 3330 Leach, P., Luotonen, A., and L. Stewart, "HTTP 3331 Authentication: Basic and Digest Access Authentication", 3332 RFC 2617, DOI 10.17487/RFC2617, June 1999, 3333 . 3335 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 3336 DOI 10.17487/RFC3688, January 2004, 3337 . 3339 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 3340 (TLS) Protocol Version 1.2", RFC 5246, 3341 DOI 10.17487/RFC5246, August 2008, 3342 . 3344 [SOAPREF] Gudgin, M., Hadley, M., Moreau, J., and H. Nielsen, "SOAP 3345 Version 1.2 Part 1: Messaging Framework", W3C 3346 Recommendation REC-SOAP12-part1-20030624, June 2002. 3348 14.2. Informative References 3350 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 3351 DOI 10.17487/RFC2818, May 2000, 3352 . 3354 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 3355 DOI 10.17487/RFC5321, October 2008, 3356 . 3358 [W3C.REC-xml-20081126] 3359 Sperberg-McQueen, C., Yergeau, F., Bray, T., Maler, E., 3360 and J. Paoli, "Extensible Markup Language (XML) 1.0 (Fifth 3361 Edition)", World Wide Web Consortium Recommendation REC- 3362 xml-20081126, November 2008, 3363 . 3365 [WSDLREF] Christensen, E., Curbera, F., Meredith, G., and S. 3366 Weerawarana, "Web Services Description Language (WSDL) 3367 1.1", W3C Note NOTE-wsdl-20010315, March 2001. 3369 Authors' Addresses 3371 Kenneth Cartwright 3372 TNS 3373 1939 Roland Clarke Place 3374 Reston, VA 20191 3375 USA 3377 Email: kcartwright@tnsi.com 3379 Vikas Bhatia 3380 TNS 3381 1939 Roland Clarke Place 3382 Reston, VA 20191 3383 USA 3385 Email: vbhatia@tnsi.com 3387 Jean-Francois Mule 3388 CableLabs 3389 858 Coal Creek Circle 3390 Louisville, CO 80027 3391 USA 3393 Email: jfm@cablelabs.com 3395 Alexander Mayrhofer 3396 enum.at GmbH 3397 Karlsplatz 1/9 3398 Wien A-1010 3399 Austria 3401 Email: alexander.mayrhofer@enum.at