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