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