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