idnits 2.17.1
draft-ietf-drinks-sppp-over-soap-07.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 (November 15, 2011) is 4540 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)
** 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 (~~), 1 warning (==), 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: May 18, 2012 November 15, 2011
7 SPPP Over SOAP and HTTP
8 draft-ietf-drinks-sppp-over-soap-07
10 Abstract
12 The Session Peering Provisioning Protocol (SPPP) is an XML protocol
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 for SPPP is a natural fit. The obvious
19 benefits include leveraging existing industry expertise, leveraging
20 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 SPPP 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 May 18, 2012.
42 Copyright Notice
44 Copyright (c) 2011 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 SPPP . . . . . . . . . . . . . . . . . . 9
63 5. Authentication and Session Management . . . . . . . . . . . . 10
64 6. SPPP 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 . . . . . . . . . . . . . . . 13
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. SPPP SOAP WSDL Definition . . . . . . . . . . . . . . . . . . 38
82 9. SPPP 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 SPPP, defined in [I-D.draft-ietf-drinks-spprov], is best supported by
120 a transport and messaging infrastructure that is connection oriented,
121 request-response oriented, easily secured, supports propagation
122 through firewalls in a standard fashion, and that is easily
123 integrated into back-office systems. This is due to the fact that
124 the client side of SPPP 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 SPPP is likely
128 to reside in a separate organization's network, resulting the SPPP
129 provisioning transactions traversing the Internet as they are
130 propagated from the SPPP client to the SPPP 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 SPPP XML structures over
134 SOAP and HTTP(s).
136 The specification in this document for transporting SPPP 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 SPPP over SOAP, and (5) "transport" specific XML
142 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 SPPP are limited. Most SOAP features are not necessary for SPPP.
154 SPPP primarily uses SOAP simply as a standard message envelope
155 technology. The SOAP message envelope is comprised of the SOAP
156 header and body. As described in the SOAP specifications, the SOAP
157 header can contain optional, application specific, information about
158 the message. The SOAP body contains the SPPP message itself, whose
159 structure is defined by the combination of one of the WSDL operations
160 defined in this document and the SPPP XML data structures defined in
161 this document and the SPPP protocol document. SPPP does not rely on
162 any data elements in the SOAP header. All relevant data elements are
163 defined in the SPPP XML schema described in
164 [I-D.draft-ietf-drinks-spprov] and the SPPP WSDL types specification
165 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 SPPP SOAP
170 messages is defined later in this document, which imports by
171 reference the XML data types contained in the SPPP schema. The IANA
172 registry where the SPPP 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 | SPPP | | SPPP |
225 |XML Types | (6) | XML Types |
226 +-------------+ +---------------+
228 Figure 1: Layering and Technical Structure of the SPPP SOAP Messages
230 The SOAP operations supported by SPPP are normatively defined later
231 in this document. Each SOAP operation defines a request/input
232 message and a response/output message. Each such request and
233 response message then contains a single object that wraps the SPPP
234 XML data types that comprise the inputs and the outputs,
235 respectively, of the SOAP operation.
237 SOAP faults are not used by the SPPP SOAP mapping. All SPPP success
238 and error responses are specified in the "Response Codes and
239 Messages" section of this document. However, if a SOAP fault were to
240 occur, perhaps due to failures in the SOAP message handling layer of
241 a SOAP library, the client application should capture and handle the
242 fault. Specifics on how to handle such SOAP faults, if they should
243 occur, will be specific to the chosen SOAP implementation.
245 SOAP 1.2 [SOAPREF] or higher and WSDL 1.1 [WSDLREF] or higher SHOULD
246 be used.
248 SPPP is a request/reply protocol that allows a client application to
249 submit provisioning data and query requests to a server. The SPPP
250 data structures are designed to be protocol agnostic. Concerns
251 regarding encryption, non-repudiation, and authentication are beyond
252 the scope of this document. For more details, please refer to the
253 "Transport Protocol Requirements" section in the protocol document.
255 As illustrated in the previous diagram, SPPP can be viewed as a set
256 of layers that collectively define the structure of an SPPP request
257 and response. Layers 1 and 2 represent the transport, envelope, and
258 authentication technologies. This document defines layers 3, 4, 5,
259 and 6 below.
261 1. Layer 1: The transport protocol layer represents the
262 communication mechanism between the client and server. SPPP can
263 be layered over any transport protocol that provides a set of
264 basic requirements defined in the Transport Protocol Requirements
265 section. But this document specifies the required mechanism.
267 2. Layer 2: The message envelope layer is optional, but can provide
268 features that are above the transport technology layer but below
269 the application messaging layer. Technologies such as HTTP and
270 SOAP are examples of messaging envelope technologies. This
271 document specifies the required envelope technology.
273 3. Layers 3,4,5,6: The operation and message layers provides an
274 envelope-independent and transport-independent wrapper for the
275 SPPP data model objects that are being acted on (created,
276 modified, queried).
278 4. HTTP(s) Features and SPPP
280 SOAP is not tied to HTTP(s), however, for reasons described in the
281 introduction, HTTP(s) is a good choice as the transport mechanism for
282 the SPPP SOAP messages. HTTP 1.1 includes the "persistent
283 connection" feature, which allows multiple HTTP request/response
284 pairs to be transported across a single HTTP connection. This is an
285 important performance optimization feature, particularly when the
286 connections is an HTTPS connection where the relatively time
287 consuming SSL handshake has occurred. Persistent connections SHOULD
288 be used for the SPPP HTTP connections.
290 HTTP 1.1 [RFC2616] or higher SHOULD be used.
292 5. Authentication and Session Management
294 To achieve integrity and privacy, conforming SPPP SOAP Clients and
295 Servers MUST support SOAP over HTTP over TLS [RFC5246] as the secure
296 transport mechanism. This combination of HTTP and TLS is referred to
297 as HTTPS. And to accomplish authentication, conforming SOAP SPPP
298 Clients and Servers MUST use HTTP Digest Authentication as defined in
299 [RFC2617]. As a result, the communication session is established
300 through the initial HTTP connection setup, the digest authentication,
301 and the TLS handshake. When the HTTP connection is broken down, the
302 communication session ends.
304 6. SPPP SOAP Data Structures
306 SPPP over SOAP uses a set of XML based data structures for all the
307 supported operations and any parameters that those operations are
308 applied to. As also mentioned earlier in this document, these XML
309 structures are envelope-independent and transport-independent. Refer
310 the "Protocol Operations" section of document for a description of
311 all the operations that MUST be supported.
313 The following sections describe the definition all the XML data
314 structures.
316 6.1. Concrete Object Key Types
318 Certain SPPP operations require an object key that uniquely
319 identifies the object on which a given operation needs to be
320 performed. The following sub-sections define the various types of
321 concrete object key types used in certain operations:
323 6.1.1. Generic Object Key
325 Most objects in SPPP are unqiuely identified by the attributes in the
326 concrete ObjKeyType. The definition of ObjKeyType is as below:
328
329
330
331
332
333
334
335
336
337
338
340 The ObjKeyType has the data elements as described below:
342 o rant: The identifier of the registrant organization that owns
343 the object.
345 o name: The character string that contains the name of the object.
347 o type: The enumeration vaue that represents the type of SPPP
348 object.
350 6.1.2. Public Identity Object Key
352 Public Identity type objects can further be of various sub-types like
353 a TN, RN, TN Prefix, or a TN Range and cannot be cleanly identified
354 with the attributes in the generic ObjKeyType. The definition of
355 PubIdKeyType is as below:
357
358
359
360
361
362
363
364
366
368
369
370
371
372
374 The PubIdKeyType has the data elements as described below:
376 o rant: The identifier of the registrant organization that owns
377 the object.
379 o dgName: The name of the Destination Group that a Public
380 Identifier is member of. Note that this is an optional
381 attribute of the key as Public Identifiers may or may not be
382 provisioned as members of a Destination Group.
384 o number: An element of type NumberType (refer protocol document)
385 that contains the value and type of a the number .
387 o range: An element of type NumberRangeType (refer protocol
388 document) that contains a rage of numbers.
390 It is MUST that only one of the "number" and "range" elements appears
391 in a PubIdKeyType instance.
393 6.1.3. Route Group Offer Key
395 In addition to the attributes in the generic ObjKeyType, a Route
396 Group Offer object is uniquely identified by the organization ID of
397 the organization to whom an Route Group has been offered. The
398 definition of RteGrpOfferKeyType is as below:
400
401
402
403
404
405
406
407
408
409
411 The RteGrpOfferKeyType has the data elements as described below:
413 o rteGrpKey: Identifies the Route Group that was offered.
415 o offeredTo: The organization ID of the organization that was
416 offered the Route Group object identified by the rteGrpKey.
418 6.2. Operation Request and Response Structures
420 An SPPP client interacts with an SPPP server by using one of the
421 supported transport mechanisms to send one or more requests to the
422 server and receive corresponding replies from the server. The basic
423 set of operations that an SPPP client can submit to an SPPP server
424 and the semantics of those operations are defined in the "Protocol
425 Operations" section of the protocol document. The following sub-
426 sections describe the XML data structures that are used for each of
427 those types of operations for a SOAP based SPPP implementation.
429 6.2.1. Add Operation Structure
431 In order to add (or modify) an object in the registry, an authorized
432 entity can send the spppAddRequest to the registry.
434 An SPPP Add request is wrapped within the element
435 while an SPPP Add response is wrapped within an
436 element. The following sub-sections describe the spppAddRequest and
437 spppAddResponse elements. Refer the "SPPP SOAP Examples" section of
438 this document for an example of Add operation on each type of SPPP
439 object.
441 6.2.1.1. Add Request
443 An SPPP Add request definition is contained within the generic
444 element.
446
447
448
449
451
453
455
456
457
459
460
461
463
464
465
467 The data elements within the element are described
468 as follows:
470 o clientTransId: Zero or one client-generated transaction ID that,
471 within the context of the SPPP client, identifies this request.
472 This value can be used at the discretion of the SPPP client to
473 track, log or correlate requests and their responses. SPPP
474 server MUST echo back this value to the client in the
475 corresponding response to the incoming request. SPPP server
476 will not check this value for uniqueness.
478 o minorVer: Zero or one minor version identifier, indicating the
479 minor version of the SPPP API that the client is attempting to
480 use. This is used in conjunction with the major version
481 identifier in the XML namespace to identify the version of SPPP
482 that the client is using. If the element is not present, the
483 server assumes that the client is using the latest minor version
484 supported by the SPPP server for the given major version. The
485 versions supported by a given SPPP server can be retrieved by
486 the client using the SPPP server menu operation described later
487 in the document.
489 o obj: One or more elements of abstract type BasicObjType (defined
490 in the protocol document). Each element contains all the
491 attributes of an SPPP object that that the client is requesting
492 the SPPP server to add. Refer the "Protocol Data Model Objects"
493 section of the protocol document for the XML structure of all
494 concrete types, for various SPPP objects, that extend from
495 abstract BasicObjType and hence are eligible to be passed into
496 this element. The elements are processed by the SPPP server in
497 the order in which they are included in the request. With
498 respect to handling of error conditions, it is a matter of
499 policy whether the objects are processed in a "stop and
500 rollback" fashion or in a "stop and commit" fashion. In the
501 "stop and rollback" scenario, the SPPP server would stop
502 processing BasicObjType elements in the request at the first
503 error and roll back any BasicObjType elements that had already
504 been processed for that add request. In the "stop and commit"
505 scenario the SPPP server would stop processing BasicObjType
506 elements in the request at the first error but commit any
507 BasicObjType elements that had already been processed for that
508 add request.
510 6.2.1.2. Add Response
512 An SPPP add response object is contained within the generic
513 element. This response structure is used for all
514 types of SPPP objects that are provisioned by the SPPP client.
516
517
518
519
521
522
523
525
526
527
529
530
531
532
533
534
536
537
538
539
540
541
542
543
544
546 An contains the elements necessary for the SPPP
547 client to precisely determine the overall result of the request, and
548 if an error occurred, it provides information about the specific
549 object(s) that caused the error.
551 The data elements within the SPPP Add response are described as
552 follows:
554 o clientTransId: Zero or one client transaction ID. This value is
555 simply an echo of the client transaction ID that SPPP client
556 passed into the SPPP update request. When included in the
557 request, the SPPP server MUST return it in the corresponding
558 response message.
560 o serverTransId: Exactly one server transaction ID that identifies
561 this request for tracking purposes. This value MUST be unique
562 for a given SPPP server.
564 o overallResult: Exactly one response code and message pair that
565 explicitly identifies the result of the request. See the
566 Response Code section for further details.
568 o dtlResult: An optional response code, response message, and
569 BasicObjType (as defined in the protocol document) triplet.
570 This element will be present only if an object level error has
571 occurred. It indicates the error condition and the exact
572 request object that contributed to the error. The response code
573 will reflect the exact error. See the Response Code section for
574 further details.
576 6.2.2. Delete Operation Structure
578 In order to remove an object from the registry, an authorized entity
579 can send the spppDelRequest into the registry. An SPPP Del request
580 is wrapped within the element while a SPPP Del
581 response is wrapped within the generic element.
582 The following sub-sections describe the spppDelRequest and
583 spppDelResponse elements. Refer the "SPPP SOAP Examples" section of
584 this document for an example of Delete operation on each type of SPPP
585 object.
587 6.2.2.1. Delete Request
589 An SPPP Del request definition is contained within the generic
590 element.
592
593
594
595
597
599
601
602
603
605 The data elements within the element are described
606 as follows:
608 o clientTransId: Zero or one client-generated transaction ID that,
609 within the context of the SPPP client, identifies this request.
610 This value can be used at the discretion of the SPPP client to
611 track, log or correlate requests and their responses. SPPP
612 server MUST echo back this value to the client in the
613 corresponding response to the incoming request. SPPP server
614 will not check this value for uniqueness.
616 o minorVer: Zero or one minor version identifier, indicating the
617 minor version of the SPPP API that the client is attempting to
618 use. This is used in conjunction with the major version
619 identifier in the XML namespace to identify the version of SPPP
620 that the client is using. If the element is not present, the
621 server assumes that the client is using the latest minor version
622 supported by the SPPP server for the given major version. The
623 versions supported by a given SPPP server can be retrieved by
624 the client using the SPPP server menu operation described later
625 in the document.
627 o objKey: One or more elements of abstract type ObjKeyType (as
628 defined in the protocol document). Each element contains
629 attributes that uniquely identify the object that the client is
630 requesting the server to delete. Refer the "Concrete Object
631 Keys" section of this document for a description of all concrete
632 object key types, for various SPPP objects, which are eligible
633 to be passed into this element. The elements are processed by
634 the SPPP server in the order in which they are included in the
635 request. With respect to handling of error conditions, it is a
636 matter of policy whether the objects are processed in a "stop
637 and rollback" fashion or in a "stop and commit" fashion. In the
638 "stop and rollback" scenario, the SPPP server would stop
639 processing ObjKeyType elements in the request at the first error
640 and roll back any ObjKeyType elements that had already been
641 processed for that delete request. In the "stop and commit"
642 scenario the SPPP server would stop processing ObjKeyType
643 elements in the request at the first error but commit any
644 KeyParamType elements that had already been processed for that
645 delete request.
647 6.2.2.2. Delete Response
649 An SPPP delete response object is contained within the generic
650 element. This response structure is used for a
651 delete request on all types of SPPP objects that are provisioned by
652 the SPPP client.
654
655
656
657
659
660
661
663
664
665
667
668
669
670
671
672
674
675
676
677
678
679
680
681
682
684 An contains the elements necessary for the SPPP
685 client to precisely determine the overall result of the request, and
686 if an error occurred, it provides information about the specific
687 object key(s) that caused the error.
689 The data elements within the SPPP Delete response are described as
690 follows:
692 o clientTransId: Zero or one client transaction ID. This value is
693 simply an echo of the client transaction ID that SPPP client
694 passed into the SPPP update request. When included in the
695 request, the SPPP server MUST return it in the corresponding
696 response message.
698 o serverTransId: Exactly one server transaction ID that identifies
699 this request for tracking purposes. This value MUST be unique
700 for a given SPPP server.
702 o overallResult: Exactly one response code and message pair that
703 explicitly identifies the result of the request. See the
704 Response Code section for further details.
706 o dtlResult: An optional response code, response message, and
707 ObjKeyType (as defined in the protocol document) triplet. This
708 element will be present only if an specific object key level
709 error has occurred. It indicates the error condition and the
710 exact request object key that contributed to the error. The
711 response code will reflect the exact error. See the Response
712 Code section for further details.
714 6.2.3. Accept Operation Structure
716 In SPPP, a Route Group Offer can be accepted or rejected by, or on
717 behalf of, the registrant to whom the Route Group has been offered
718 (refer "Protocol Data Model Objects" section of the protocol document
719 for a description of the Route Group Offer object). The Accept
720 operation is used to accept such Route Group Offers by, or on behalf
721 of, the Registrant. The request structure for an SPPP Accept
722 operation is wrapped within the element while an
723 SPPP Accept response is wrapped within the generic
724 element. The following sub-sections describe
725 the spppAcceptRequest and spppAcceptResponse elements. Refer the
726 "SPPP SOAP Examples" section of this document for an example of
727 Accept operation on a Route Group Offer.
729 6.2.3.1. Accept Request Structure
731 An SPPP Accept request definition is contained within the generic
732 element.
734
735
736
737
739
741
744
746
747
749 The data elements within the element are
750 described as follows:
752 o clientTransId: Zero or one client-generated transaction ID that,
753 within the context of the SPPP client, identifies this request.
754 This value can be used at the discretion of the SPPP client to
755 track, log or correlate requests and their responses. SPPP
756 server MUST echo back this value to the client in the
757 corresponding response to the incoming request. SPPP server
758 will not check this value for uniqueness.
760 o minorVer: Zero or one minor version identifier, indicating the
761 minor version of the SPPP API that the client is attempting to
762 use. This is used in conjunction with the major version
763 identifier in the XML namespace to identify the version of SPPP
764 that the client is using. If the element is not present, the
765 server assumes that the client is using the latest minor version
766 supported by the SPPP server for the given major version. The
767 versions supported by a given SPPP server can be retrieved by
768 the client using the SPPP server menu operation described later
769 in the document.
771 o rteGrpOfferKey: One or more elements of type RteGrpOfferKeyType
772 (as defined in this document). Each element contains attributes
773 that uniquely identify a Route Group Offer that the client is
774 requesting the server to accept. The elements are processed by
775 the SPPP server in the order in which they are included in the
776 request. With respect to handling of error conditions, it is a
777 matter of policy whether the objects are processed in a "stop
778 and rollback" fashion or in a "stop and commit" fashion. In the
779 "stop and rollback" scenario, the SPPP server would stop
780 processing RteGrpOfferKeyType elements in the request at the
781 first error and roll back any RteGrpOfferKeyType elements that
782 had already been processed for that accept request. In the
783 "stop and commit" scenario the SPPP server would stop processing
784 RteGrpOfferKeyType elements in the request at the first error
785 but commit any RteGrpOfferKeyType elements that had already been
786 processed for that accept request.
788 6.2.3.2. Accept Response
790 An SPPP accept response structure is contained within the generic
791 element. This response structure is used for an
792 Accept request on a Route Group Offer.
794
795
796
797
799
800
801
804
805
806
808
809
810
811
812
813
815
816
817
818
819
820
821
822
823
825 An contains the elements necessary for the SPPP
826 client to precisely determine the overall result of the request, and
827 if an error occurred, it provides information about the specific
828 Route Group Offer key(s) that caused the error.
830 The data elements within the SPPP Accept response are described as
831 follows:
833 o clientTransId: Zero or one client transaction ID. This value is
834 simply an echo of the client transaction ID that SPPP client
835 passed into the SPPP update request. When included in the
836 request, the SPPP server MUST return it in the corresponding
837 response message.
839 o serverTransId: Exactly one server transaction ID that identifies
840 this request for tracking purposes. This value MUST be unique
841 for a given SPPP server.
843 o overallResult: Exactly one response code and message pair that
844 explicitly identifies the result of the request. See the
845 Response Code section for further details.
847 o dtlResult: An optional response code, response message, and
848 RteGrpOfferKeyType (as defined in this document) triplet. This
849 element will be present only if any specific Route Group Offer
850 key level error has occurred. It indicates the error condition
851 and the exact request Route Group Offer key that contributed to
852 the error. The response code will reflect the exact error. See
853 the Response Code section for further details.
855 6.2.4. Reject Operation Structure
857 In SPPP, Route Group Offer can be accepted or rejected by, or on
858 behalf of, the registrant to whom the Route Group has been offered
859 (refer "Protocol Data Model Objects" section of this document for a
860 description of the Route Group Offer object). The Reject operation
861 is used to reject such Route Group Offers by, or on behalf of, the
862 Registrant. The request structure for an SPPP Reject operation is
863 wrapped within the element while an SPPP Reject
864 response is wrapped within the generic element.
865 The following sub-sections describe the spppRejectRequest and
866 spppRejecResponse elements. Refer the "SPPP SOAP Examples" section
867 of this document for an example of Reject operation on a Route Group
868 Offer.
870 6.2.4.1. Reject Request
872 An SPPP Reject request definition is contained within the generic
873 element.
875
876
877
878
880
882
885
886
888 The data elements within the element are
889 described as follows:
891 o clientTransId: Zero or one client-generated transaction ID that,
892 within the context of the SPPP client, identifies this request.
893 This value can be used at the discretion of the SPPP client to
894 track, log or correlate requests and their responses. SPPP
895 server MUST echo back this value to the client in the
896 corresponding response to the incoming request. SPPP server
897 will not check this value for uniqueness.
899 o minorVer: Zero or one minor version identifier, indicating the
900 minor version of the SPPP API that the client is attempting to
901 use. This is used in conjunction with the major version
902 identifier in the XML namespace to identify the version of SPPP
903 that the client is using. If the element is not present, the
904 server assumes that the client is using the latest minor version
905 supported by the SPPP server for the given major version. The
906 versions supported by a given SPPP server can be retrieved by
907 the client using the SPPP server menu operation described later
908 in the document.
910 o rteGrpOfferKey: One or more elements of type RteGrpOfferKeyType
911 (as defined in this document). Each element contains attributes
912 that uniquely identify a Route Group Offer that the client is
913 requesting the server to reject. The elements are processed by
914 the SPPP server in the order in which they are included in the
915 request. With respect to handling of error conditions, it is a
916 matter of policy whether the objects are processed in a "stop
917 and rollback" fashion or in a "stop and commit" fashion. In the
918 "stop and rollback" scenario, the SPPP server would stop
919 processing RteGrpOfferKeyType elements in the request at the
920 first error and roll back any RteGrpOfferKeyType elements that
921 had already been processed for that reject request. In the
922 "stop and commit" scenario the SPPP server would stop processing
923 RteGrpOfferKeyType elements in the request at the first error
924 but commit any RteGrpOfferKeyType elements that had already been
925 processed for that reject request.
927 6.2.4.2. Reject Response
929 An SPPP reject response structure is contained within the generic
930 element. This response structure is used for an
931 Reject request on a Route Group Offer.
933
934
935
936
938
939
940
943
944
945
947
948
949
950
951
952
954
955
956
957
958
959
960
961
962
964 An contains the elements necessary for the SPPP
965 client to precisely determine the overall result of the request, and
966 if an error occurred, it provides information about the specific
967 Route Group Offer key(s) that caused the error.
969 The data elements within the SPPP Reject response are described as
970 follows:
972 o clientTransId: Zero or one client transaction ID. This value is
973 simply an echo of the client transaction ID that SPPP client
974 passed into the SPPP update request. When included in the
975 request, the SPPP server MUST return it in the corresponding
976 response message.
978 o serverTransId: Exactly one server transaction ID that identifies
979 this request for tracking purposes. This value MUST be unique
980 for a given SPPP server.
982 o overallResult: Exactly one response code and message pair that
983 explicitly identifies the result of the request. See the
984 Response Code section for further details.
986 o dtlResult: An optional response code, response message, and
987 RteGrpOfferKeyType (as defined in this document) triplet. This
988 element will be present only if any specific Route Group Offer
989 key level error has occurred. It indicates the error condition
990 and the exact request Route Group Offer key that contributed to
991 the error. The response code will reflect the exact error. See
992 the Response Code section for further details.
994 6.2.5. Batch Operation Structure
996 An SPPP Batch request XML structure allows the SPPP client to send
997 any of of Add, Del, Accept or Reject operations together in one
998 single request. This gives an SPPP Client the flexibility to use one
999 single request structure to perform more than operations (verbs).
1000 The batch request structure is wrapped within the
1001 element while a SPPP Batch response is wrapped within the
1002 element. This following sub-sections describe
1003 the spppBatchRequest and spppBatchResponse elements. Refer the "SPPP
1004 SOAP Examples" section of this document for an example of a batch
1005 operation.
1007 6.2.5.1. Batch Request Structure
1009 An SPPP Batch request definition is contained within the generic
1010 element.
1012
1013
1014
1015
1017
1019
1020
1021
1022
1024
1026
1027
1028
1029
1031 The data elements within the element are described
1032 as follows:
1034 o clientTransId: Zero or one client-generated transaction ID that,
1035 within the context of the SPPP client, identifies this request.
1036 This value can be used at the discretion of the SPPP client to
1037 track, log or correlate requests and their responses. SPPP
1038 server MUST echo back this value to the client in the
1039 corresponding response to the incoming request. SPPP server
1040 will not check this value for uniqueness.
1042 o minorVer: Zero or one minor version identifier, indicating the
1043 minor version of the SPPP API that the client is attempting to
1044 use. This is used in conjunction with the major version
1045 identifier in the XML namespace to identify the version of SPPP
1046 that the client is using. If the element is not present, the
1047 server assumes that the client is using the latest minor version
1048 supported by the SPPP server for the given major version. The
1049 versions supported by a given SPPP server can be retrieved by
1050 the client using the SPPP server menu operation described later
1051 in the document.
1053 o addObj: One or more elements of abstract type BasicObjType where
1054 each element identifies an object that needs to be added.
1056 o delObj: One or more elements of abstract type ObjKeyType where
1057 each element identifies a key for the object that needs to be
1058 deleted .
1060 o acceptRteGrpOffer: One or more elements of type
1061 RteGrpOfferKeyType where each element identifies a Route Group
1062 Offer that needs to be accepted.
1064 o rejectRteGrpOffer: One or more elements of type
1065 RteGrpOfferKeyType where each element identifies a Route Group
1066 Offer that needs to be rejected.
1068 With respect to handling of error conditions, it is a matter of
1069 policy whether the batch operation processed in a "stop and rollback"
1070 fashion or in a "stop and commit" fashion. In the "stop and
1071 rollback" scenario, the SPPP server would stop processing elements in
1072 the request at the first error and roll back any elements that had
1073 already been processed for that batch request. In the "stop and
1074 commit" scenario the SPPP server would stop processing elements in
1075 the request at the first error but commit any elements that had
1076 already been processed for that batch request.
1078 6.2.5.2. Batch Response
1080 An SPPP batch response structure is contained within the generic
1081 element. This response structure is used for an
1082 Batch request that contains many different types of SPPP operations.
1084
1085
1086
1087
1089
1090
1091
1092
1094
1096
1098
1100
1101
1102
1103
1105 An contains the elements necessary for an SPPP
1106 client to precisely determine the overall result of various
1107 operations in the request, and if an error occurred, it provides
1108 information about the specific objects or keys in the request that
1109 caused the error.
1111 The data elements within the SPPP Batch response are described as
1112 follows:
1114 o clientTransId: Zero or one client transaction ID. This value is
1115 simply an echo of the client transaction ID that SPPP client
1116 passed into the SPPP update request. When included in the
1117 request, the SPPP server MUST return it in the corresponding
1118 response message.
1120 o serverTransId: Exactly one server transaction ID that identifies
1121 this request for tracking purposes. This value MUST be unique
1122 for a given SPPP server.
1124 o overallResult: Exactly one response code and message pair that
1125 explicitly identifies the result of the request. See the
1126 Response Code section for further details.
1128 o addResult: One or more elements of type ObjResultCodeType where
1129 each element identifies the result code, result message and the
1130 specific object that the result relates to.
1132 o delResult: One or more elements of type ObjKeyResultCodeType
1133 where each element identifies the result code, result message
1134 and the specific object key that the result relates to.
1136 o acceptResult: One or more elements of type
1137 RteGrpOfferKeyResultCodeType where each element identifies the
1138 result code, result message and the specific Route Group Offer
1139 key that the result relates to.
1141 o rejectResult: One or more elements of type
1142 RteGrpOfferKeyResultCodeType where each element identifies the
1143 result code, result message and the specific Route Group Offer
1144 key that the result relates to.
1146 6.2.6. Get Operation Structure
1148 In order to query the details of an object from the Registry, an
1149 authorized entity can send the spppGetRequest to the registry with a
1150 GetRqstType XML data structure containing one or more object keys
1151 that uniquely identify the object whose details are being queried.
1152 The request strcuture for an SPPP Get operation is contained within
1153 the generic element while an SPPP Get response is
1154 wrapped within the generic element. The following
1155 sub-sections describe the spppGetRequest and spppGetResponse element.
1156 Refer the examples section for an example of Get operation on each
1157 type of SPPP object
1159 6.2.6.1. Get Request
1161
1162
1163
1164
1166
1169
1170
1171
1173 The data elements within the element are described
1174 as follows:
1176 o minorVer: Zero or one minor version identifier, indicating the
1177 minor version of the SPPP API that the client is attempting to
1178 use. This is used in conjunction with the major version
1179 identifier in the XML namespace to identify the version of SPPP
1180 that the client is using. If the element is not present, the
1181 server assumes that the client is using the latest minor version
1182 supported by the SPPP server for the given major version. The
1183 versions supported by a given SPPP server can be retrieved by
1184 the client using the SPPP server menu operation described later
1185 in the document.
1187 o objKey: One or more elements of abstract type ObjKeyType (as
1188 defined in the protocol document). Each element contains
1189 attributes that uniquely identify the object that the client is
1190 requesting the server to query. Refer the "Concrete Object
1191 Keys" section of this document for a description of all concrete
1192 object key types, for various SPPP objects, which are eligible
1193 to be passed into this element.
1195 6.2.6.2. Get Response
1197 The spppGetResponse element is described later in section titled
1198 "Generic Query Response".
1200 6.2.7. Get Route Group Offers Operation Structure
1202 In addition to the ability to query the details of one or more Route
1203 Group offers using an a Route Group Offer key in the spppGetRequest,
1204 this operation also provides an additonal, more flexible, structure
1205 to query for Route Group Offer objects. This additional structure is
1206 contained within the element while the
1207 response is wrapped within the generic element.
1208 The following sub-sections describe the getRteGrpOffersRequest and
1209 spppGetResponse elements.
1211 6.2.7.1. Get Route Group Offers Request
1213 Using the details passed into this structure, the server will attempt
1214 to find Route Group Offer objects that satisfy all the criteria
1215 passed into the request. If no criteria is passed in then the server
1216 will return the list of Route Group Offer objects that belongs to the
1217 registrant. If there are no matching Route Group Offers found then
1218 an empty result set will be returned.
1220
1221
1222
1223
1225
1227
1229
1231
1233
1234
1235
1237 The data elements within the element are
1238 described as follows:
1240 o minorVer: Zero or one minor version identifier, indicating the
1241 minor version of the SPPP API that the client is attempting to
1242 use. This is used in conjunction with the major version
1243 identifier in the XML namespace to identify the version of SPPP
1244 that the client is using. If the element is not present, the
1245 server assumes that the client is using the latest minor version
1246 supported by the SPPP server for the given major version. The
1247 versions supported by a given SPPP server can be retrieved by
1248 the client using the SPPP server menu operation described later
1249 in the document.
1251 o offeredBy: Zero or more organization IDs. Only offers that are
1252 offered to the organization IDs in this list should be included
1253 in the result set. The result set is also subject to other
1254 query criteria in the request.
1256 o offeredTo: Zero or more organization IDs. Only offers that are
1257 offered by the organization IDs in this list should be included
1258 in the result set. The result set is also subject to other
1259 query criteria in the request.
1261 o status: The status of the offer, offered or accepted. Only
1262 offers in the specified status should be included in the result
1263 set. If this element is not present then the status of the
1264 offer should not be considered in the query. The result set is
1265 also subject to other query criteria in the request.
1267 o rteGrpOfferKey: Zero or more Route Group Offer Keys. Only
1268 offers having one of these keys should be included in the result
1269 set. The result set is also subject to other query criteria in
1270 the request.
1272 6.2.7.2. Get Route Group Offers Response
1274 The spppGetResponse element is described later in section titled
1275 "Generic Query Response".
1277 6.2.8. Generic Query Response
1279 An SPPP query response object is contained within the generic
1280 element.
1282
1283
1284
1285
1287
1290
1291
1292
1294 An contains the elements necessary for the SPPP
1295 client to precisely determine the overall result of the query, and
1296 details of any SPPP objects that matched the criteria in the request.
1298 The data elements within the SPPP query response are described as
1299 follows:
1301 o overallResult: Exactly one response code and message pair that
1302 explicitly identifies the result of the request. See the
1303 Response Code section for further details.
1305 o resultObj: The set of zero or more objects that matched the
1306 query criteria. If no objects matched the query criteria then
1307 the result object(s) MUST be empty and the overallResult value
1308 MUST indicate success (if no matches are found for the query
1309 criteria, the response is considered a success).
1311 6.2.9. Get Server Details Operation Structure
1313 In order to query certain details of the SPPP server, like the SPPP
1314 server's status and the major/minor version supported by the server,
1315 the Server Details operation structure SHOULD be used. This
1316 structure is contained within the element
1317 while a SPPP server status response is wrapped within the
1318 element. This following sub-sections
1319 describe the spppServerStatusRequest and spppServerStatusResponse
1320 elements.
1322 6.2.9.1. Get Server Details Request
1323
1324
1325
1326
1328
1329
1330
1332 The data elements within the element are
1333 described as follows:
1335 o minorVer: Zero or one minor version identifier, indicating the
1336 minor version of the SPPP API that the client is attempting to
1337 use. This is used in conjunction with the major version
1338 identifier in the XML namespace to identify the version of SPPP
1339 that the client is using. If the element is not present, the
1340 server assumes that the client is using the latest minor version
1341 supported by the SPPP server for the given major version. The
1342 versions supported by a given SPPP server can be retrieved by
1343 the client using this same spppServerStatusRequest without
1344 passing in the minorVer element.
1346 6.2.9.2. Get Server Details Response
1348 An SPPP server details response structure is contained within the
1349 generic element.
1351
1352
1353
1354
1355
1356
1357
1358
1360 The data elements within the element are
1361 described as follows:
1363 o overallResult: Exactly one response code and message pair that
1364 explicitly identifies the result of the request. See the
1365 Response Code section for further details.
1367 o svcMenu: Exactly one element of type SvcMenuType which in turn
1368 contains the elements to return the server status and major/
1369 minor version of the SPPP protocol supported by the SPPP server
1370 (refer protocol document for definition of SvcMenuType) .
1372 6.3. Response Codes and Messages
1374 This section contains the listing of response codes and their
1375 corresponding human-readable text. These response codes are in
1376 conformance with the response types defined in the section "Response
1377 Message Types" of the protocol document.
1379 The response code numbering scheme generally adheres to the theory
1380 formalized in section 4.2.1 of [RFC5321]:
1382 o The first digit of the response code can only be 1 or 2: 1 = a
1383 positive result, 2 = a negative result.
1385 o The second digit of the response code indicates the category: 0
1386 = Protocol Syntax, 1 = Implementation Specific Business Rule, 2
1387 = Security, 3 = Server System.
1389 o The third and fourth digits of the response code indicate the
1390 individual message event within the category defines by the
1391 first two digits.
1393 The response codes are also categorized as to whether they are
1394 overall response codes that may only be returned in the
1395 "overallResult" data element in SPPP responses, or object level
1396 response codes that may only be returned in the "dtlResult" element
1397 of the SPPP responses.
1399 +--------+--------------------------+-------------------------------+
1400 | Result | Result Message | Overall or Object Level |
1401 | Code | | |
1402 +--------+--------------------------+-------------------------------+
1403 | 1000 | Request Succeeded. | Overall Response Code |
1404 | | | |
1405 | 2001 | Request syntax invalid. | Overall Response Code |
1406 | | | |
1407 | 2002 | Request too large. | Overall Response Code |
1408 | | | |
1409 | 2003 | Version not supported. | Overall Response Code |
1410 | | | |
1411 | 2103 | Command invalid. | Overall Response Code |
1412 | | | |
1413 | 2301 | System temporarily | Overall Response Code |
1414 | | unavailable. | |
1415 | | | |
1416 | 2302 | Unexpected internal | Overall Response Code |
1417 | | system or server error. | |
1418 | | | |
1419 | 2104 | Attribute value invalid. | Object Level Response Code |
1420 | | | |
1421 | | AttrName:[AttributeName] | |
1422 | | AttrVal:[AttributeValue] | |
1423 | | | |
1424 | 2105 | Object does not exist. | Object Level Response Code |
1425 | | AttrName:[AttributeName] | |
1426 | | AttrVal:[AttributeValue] | |
1427 | | | |
1428 | 2106 | Object status or | Object Level Response Code |
1429 | | ownership does not allow | |
1430 | | for operation. | |
1431 | | AttrName:[AttributeName] | |
1432 | | AttrVal:[AttributeValue] | |
1433 +--------+--------------------------+-------------------------------+
1435 Table 1: Response Codes Numbering Scheme and Messages
1437 Each of the object level response messages are "parameterized" with
1438 the following parameters: "AttributeName" and "AttributeValue".
1440 The use of these parameters MUST adhere to the rules defined in
1441 "Response Message Types" section of the protocol document.
1443 7. Protocol Operations
1445 Refer the "Protocol Operations" section of the protocol document for
1446 a description of all SPPP operations, and any necessary semantics
1447 that MUST be adhered to in order to conform with the SPPP protocol
1448 specification.
1450 8. SPPP SOAP WSDL Definition
1452 The SPPP WSDL and data types are defined below. The WSDL design
1453 approach is commonly referred to as _Generic WSDL_. It is generic in
1454 the sense that there is not a specific WSDL operation defined for
1455 each object type that is supported by the SPPP protocol. There is a
1456 single WSDL structure for each type of SPPP operation. Each such
1457 WSDL structure contains exactly one input structure and one output
1458 structure that wraps any data elements that are part of the incoming
1459 request and the outgoing response respectively. The spppSOAPBinding
1460 in the WSDL defines the binding style as _document_ and the encoding
1461 as _literal_. It is this combination of _wrapped_ input and output
1462 data structures, _document_ binding style, and _literal_ encoding
1463 that characterize the Document Literal Wrapped style of WSDL
1464 specifications.
1466 Note: The following WSDL has been formatted (e.g., tabs, spaces) to
1467 meet I-D requirements.
1469
1470
1477
1478
1481
1482
1483 ---- Import base schema ----
1484
1485
1486
1488
1489
1490 ---- Key type(s) extended
1491 from base schema. ----
1492
1493
1494
1495
1496
1497
1498
1499
1500
1501
1502
1503
1504
1505
1506
1507
1508
1509
1511
1513
1514
1515
1516
1517
1518
1519
1520
1521
1522
1524
1525
1527
1529
1530
1531
1532
1533
1535
1536
1537 ---- Generic Request and
1538 Response Definitions ----
1539
1540
1541
1542
1543
1544
1546
1548
1550
1551
1552
1553
1554
1555
1556
1558
1560
1562
1563
1564
1565
1566
1567
1568
1570
1572
1575
1576
1577
1578
1579
1580
1581
1583
1585
1588
1589
1590
1591
1592
1593
1594
1596
1599
1600
1601
1602
1603
1604
1605
1607
1609
1610
1611
1612
1614
1616
1617
1618
1619
1620
1621
1622
1623
1625
1626
1627
1628
1629
1630
1631
1633
1636
1638
1640
1643
1644
1645
1646
1647
1648
1649
1651
1653
1655
1658
1659
1660
1661
1662
1663
1664
1666
1668
1670
1673
1674
1675
1676
1677
1678
1679
1681
1683
1685
1689
1690
1691
1692
1693
1694
1695
1697
1699
1701
1704
1705
1706
1707
1708
1709
1710
1712
1714
1716
1717
1719
1721
1723
1725
1726
1727
1728
1729
1730
1731
1732
1734
1738
1739
1740
1741
1742
1743
1744
1746
1748
1749
1750
1751
1752
1753 ---- Operation Result Type
1754 Definitions ----
1755
1756
1757
1758
1759
1760
1761
1762
1763
1764
1765
1766
1767
1768
1769
1770
1771
1772
1773
1774
1775
1776
1777
1778
1779
1780
1781
1782
1783
1784
1785
1787
1788
1789
1790
1791
1792
1793
1794
1795
1796
1797
1798
1799
1800
1801
1802
1803
1804
1805
1806
1807
1808
1809
1810
1811
1812
1813
1814
1815
1816
1817
1818
1819
1820
1821
1822
1823
1824
1825
1826
1827
1828
1829
1830
1831
1832
1833
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
1876
1877
1878
1879
1880
1881
1882
1884
1885
1886
1887
1888
1889
1890
1891
1892
1893
1894
1895
1896
1897
1898
1899
1900
1901
1902
1903
1904
1905
1906
1907
1908
1909
1910
1911
1912
1913
1914
1915
1916
1917
1918
1919
1920
1921
1922
1923
1924
1925
1926
1927
1928
1929
1930
1931
1932
1934
1935
1936
1937
1938
1939
1940
1941
1942
1944
1945
1946
1947
1948
1949
1950
1951
1952
1953
1954
1955
1956
1957
1959 Figure 2: WSDL
1961 9. SPPP SOAP Examples
1963 This section shows XML message exchange between two SIP Service
1964 Providers (SSP) and a registry. The SPPP messages in this section
1965 are valid XML instances that conform to the SOAP based SPPP schema
1966 version within this document. This section relies on the XML data
1967 structures defined in the base SPPP protocol specification
1968 [I-D.draft-ietf-drinks-spprov]. So refer to that document to
1969 understand XML object types embedded in these example messages.
1971 In this sample use case scenario, SSP1 and SSP2 provision resource
1972 data in the registry and use SPPP constructs to selectively share the
1973 route groups. In the figure below, SSP2 has two ingress SBE
1974 instances that are associated with the public identities that SSP2
1975 has the retail relationship with. Also, the two SBE instances for
1976 SSP1 are used to show how to use SPPP to associate route preferences
1977 for the destination ingress routes and exercise greater control on
1978 outbound traffic to the peer's ingress SBEs.
1980 ---------------+ +------------------
1981 | |
1982 +------+ +------+
1983 | sbe1 | | sbe2 |
1984 +------+ +------+
1985 SSP1 | | SSP2
1986 +------+ +------+
1987 | sbe3 | | sbe4 |
1988 +------+ +------+
1989 iana-en:111 | | iana-en:222
1990 ---------------+ +------------------
1991 | |
1992 | |
1993 | SPPP +------------------+ SPPP |
1994 +------->| Registry |<--------+
1995 +------------------+
1997 9.1. Add Destination Group
1999 SSP2 adds a destination group to the registry for use later. The
2000 SSP2 SPPP client sets a unique transaction identifier 'txn_1479' for
2001 tracking purposes. The name of the destination group is set to
2002 DEST_GRP_SSP2_1
2003
2004
2009
2010
2011
2012
2013 txn_1479
2014
2015
2016 iana-en:222
2017 iana-en:223
2018 DEST_GRP_SSP2_1
2019
2020
2021
2022
2024 The registry processes the request and return a favorable response
2025 confirming successful creation of the named destination group. Also,
2026 besides returning a unique server transaction identifier, Registry
2027 also returns the matching client transaction identifier from the
2028 request message back to the SPPP client.
2030
2031
2033
2034
2037 txn_1479
2038 tx_12345
2039
2040 1000
2041 Request Succeeded.
2042
2043
2044
2045
2047 9.2. Add Route Records
2049 SSP2 adds an ingress routes in the registry.
2051
2052
2057
2058
2059
2060
2061 txn_1479
2062
2063
2064 iana-en:222
2065 iana-en:223
2066 RTE_SSP2_SBE2
2067 10
2068 u
2069 E2U+sip
2070
2071 ^(.*)$
2072 sip:\1@sbe2.ssp2.example.com
2073
2074
2075
2076
2077
2079 The registry returns a success response.
2081
2082
2084
2085
2088 txn_1479
2089 tx_12345
2090
2091 1000
2092 Request Succeeded.
2093
2094
2095
2096
2098 9.3. Add Route Records -- URIType
2100 SSP2 adds another ingress routes in the registry and makes use of
2101 URIType
2103
2104
2109
2110
2111
2112 txn_1479
2113
2114
2115 iana-en:222
2116 iana-en:223
2117 RTE_SSP2_SBE4
2118 ^(.*)$
2119 sip:\1;npdi@sbe4.ssp2.example.com
2120
2121
2122
2123
2124 The registry returns a success response.
2126
2127
2128
2129
2132 txn_1479
2133 tx_12345
2134
2135 1000
2136 Request Succeeded.
2137
2138
2139
2140
2142 9.4. Add Route Group
2144 SSP2 creates the grouping of the ingress routes and choses higher
2145 precedence for RTE_SSP2_SBE2 by setting a lower number for the
2146 "priority" attribute, a protocol agnostic precedence indicator.
2148
2149
2154
2155
2156
2157 txn_1479
2158
2159
2160 iana-en:222
2161 iana-en:223
2162 RTE_GRP_SSP2_1
2163
2164
2165 iana-en:222
2166 RTE_SSP2_SBE2
2167 RteRec
2168
2169 100
2170
2171 DEST_GRP_SSP2_1
2172 true
2173 10
2174
2175
2176
2177
2179 To confirm successful processing of this request, registry returns a
2180 well-known result code '1000' to the SSP2 client.
2182
2183
2184
2185
2188 txn_1479
2189 tx_12345
2190
2191 1000
2192 Request Succeeded.
2193
2194
2195
2196
2198 9.5. Add Public Identity -- Successful COR claim
2200 SSP2 activates a TN public identity by associating it with a valid
2201 destination group. Further, SSP2 puts forth a claim that it is the
2202 carrier-of-record for the TN.
2204
2209
2210
2211
2212 txn_1479
2213
2214
2215 iana-en:222
2216 iana-en:223
2217 DEST_GRP_SSP2_1
2218 +12025556666
2219
2220 true
2221
2222
2223
2224
2225
2226 Assuming that the registry has access to TN authority data and it
2227 performs the required checks to verify that SSP2 is in fact the
2228 service provider of record for the given TN, the request is processed
2229 successfully. In the response message, the registry sets the value
2230 of to "true" in order to confirm SSP2 claim as the carrier of
2231 record and the reflects the time when the carrier of record
2232 claim is processed.
2234
2235
2238
2239
2242 txn_1479
2243 tx_12345
2244
2245 1000
2246 Request Succeeded.
2247
2248
2249 1000
2250 Request Succeeded.
2251
2252 iana-en:222
2253 iana-en:223
2254 2010-05-30T09:30:10Z
2255 DEST_GRP_SSP2_1
2256 +12025556666
2257
2258 true
2259 true
2260 2010-05-30T09:30:11Z
2261
2262
2263
2264
2265
2266
2268 9.6. Add LRN
2270 If another entity that SSP2 shares the routes with has access to
2271 Number Portability data, it may choose to perform route lookups by
2272 routing number. Therefore, SSP2 associates a routing number to a
2273 destination group in order to facilitate ingress route discovery.
2275
2276
2281
2282
2283
2284 txn_1479
2285
2286
2287 iana-en:222
2288 iana-en:223
2289 DEST_GRP_SSP2_1
2290 2025550000
2291
2292
2293
2294
2296 Registry completes the request successfully and returns a favorable
2297 response to the SPPP client.
2299
2300
2302
2303
2306 txn_1479
2307 tx_12345
2308
2309 1000
2310 Request Succeeded.
2311
2312
2313
2314
2316 9.7. Add TN Range
2318 Next, SSP2 activates a block of ten thousand TNs and associate it to
2319 a destination group.
2321
2322
2327
2328
2329
2330 txn_1479
2331
2332
2333 iana-en:222
2334 iana-en:223
2335 DEST_GRP_SSP2_1
2336
2337 +12026660000
2338 +12026669999
2339
2340
2341
2342
2343
2344 Registry completes the request successfully and returns a favorable
2345 response.
2347
2348
2350
2351
2354 txn_1479
2355 tx_12345
2356
2357 1000
2358 Request Succeeded.
2359
2360
2361
2362
2364 9.8. Add TN Prefix
2366 Next, SSP2 activates a block of ten thousand TNs using the TNPType
2367 structure and identifying a TN prefix.
2369
2370
2375
2376
2377
2378 txn_1479
2379
2380
2381 iana-en:222
2382 iana-en:223
2383 DEST_GRP_SSP2_1
2384 +1202777
2385
2386
2388
2389
2391 Registry completes the request successfully and returns a favorable
2392 response.
2394
2395
2397
2398
2401 txn_1479
2402 tx_12345
2403
2404 1000
2405 Request Succeeded.
2406
2407
2408
2409
2411 9.9. Enable Peering -- Route Group Offer
2413 In order for SSP1 to complete session establishment for a destination
2414 TN where the target subscriber has a retail relationship with SSP2,
2415 it first requires an asynchronous bi-directional handshake to show
2416 mutual consent. To start the process, SSP2 initiates the peering
2417 handshake by offering SSP1 access to its route group.
2419
2420
2425
2426
2427
2428 txn_1479
2429
2430
2431 iana-en:222
2432 iana-en:223
2433
2434
2435 iana-en:222
2436 RTE_GRP_SSP2_1
2437 RteGrp
2438
2439 iana-en:111
2440
2441 offered
2442
2443 2006-05-04T18:13:51.0Z
2444
2445
2446
2447
2448
2450 Registry completes the request successfully and confirms that the
2451 SSP1 will now have the opportunity to weigh in on the offer and
2452 either accept or reject it. The registry may employ out-of-band
2453 notification mechanisms for quicker updates to SSP1 so they can act
2454 faster, though this topic is beyond the scope of this document.
2456
2457
2459
2460
2463 txn_1479
2464 tx_12345
2465
2466 1000
2467 Request Succeeded.
2468
2469
2470
2471
2473 9.10. Enable Peering -- Route Group Offer Accept
2475 SSP1 responds to the offer from SSP2 and agrees to have visibility to
2476 SSP2 ingress routes.
2478
2479
2482
2483
2484
2485
2486 txn_1479
2487
2488
2489
2490 iana-en:222
2491 RTE_GRP_SSP2_1
2492 RteGrp
2493
2494 iana-en:111
2495
2496
2497
2498
2499 Registry confirms that the request has been processed successfully.
2500 From this point forward, if SSP1 looks up a public identity through
2501 the query resolution server, where the public identity is part of the
2502 destination group by way of "RTE_GRP_SSP2_1" route association, SSP2
2503 ingress SBE information will be shared with SSP1.
2505
2506
2508
2509
2512 txn_1479
2513 tx_12350
2514
2515 1000
2516 Request Succeeded.
2517
2518
2519
2520
2522 9.11. Add Egress Route
2524 SSP1 wants to prioritize all outbound traffic to routes associated
2525 with "RTE_GRP_SSP2_1" route group through "sbe1.ssp1.example.com".
2527
2528
2533
2534
2535
2536 txn_1479
2537
2538
2539 iana-en:222
2540 iana-en:223
2541 EGR_RTE_01
2542 50
2543
2544 ^(.*@)(.*)$
2545 \1\2?route=sbe1.ssp1.example.com
2546
2547
2548 iana-en:222
2549 SSP2_RTE_REC_3
2550 RteRec
2551
2552
2553
2554
2555
2557 Since peering has already been established, the request to add the
2558 egress route has been successfully completed.
2560
2561
2563
2564
2567 txn_1479
2568 tx_12345
2569
2570 1000
2571 Request Succeeded.
2572
2573
2574
2575
2577 9.12. Remove Peering -- Route Group Offer Reject
2579 SSP1 had earlier accepted to have visibility to SSP2 ingress routes.
2580 SSP1 now decides to no more maintain this visiblity and hence rejects
2581 the Route Group Offer.
2583
2584
2587
2588
2589
2590
2591 txn_1479
2592
2593
2594
2595 iana-en:222
2596 RTE_GRP_SSP2_1
2597 RteGrp
2598
2599 iana-en:111
2600
2601
2602
2603
2604 Registry confirms that the request has been processed successfully.
2605 From this point forward, if SSP1 looks up a public identity through
2606 the query resolution server, where the public identity is part of the
2607 destination group by way of "RTE_GRP_SSP2_1" route association, SSP2
2608 ingress SBE information will NOT be shared with SSP1 and hence SSP2
2609 ingress SBE will NOT be returned in the query response.
2611
2612
2614
2615
2618 txn_1479
2619 tx_12350
2620
2621 1000
2622 Request Succeeded.
2623
2624
2625
2626
2628 9.13. Get Destination Group
2630 SSP2 uses the 'spppGetRequest' operation to tally the last
2631 provisioned record for destination group DEST_GRP_SSP2_1.
2633
2634
2638
2639
2640
2641
2642
2643 iana-en:222
2644 DEST_GRP_SSP2_1
2645 DestGrp
2646
2647
2648
2649
2651 Registry completes the request successfully and returns a favorable
2652 response.
2654
2655
2658
2659
2662
2663 1000
2664 success
2665
2666
2667 iana-en:222
2668 iana-en:223
2669 DEST_GRP_SSP2_1
2670
2671
2672
2673
2675 9.14. Get Public Identity
2677 SSP2 obtains the last provisioned record associated with a given TN.
2679
2680
2685
2686
2687
2688
2689
2690 iana-en:222
2691
2692 +12025556666
2693 TN
2694
2695
2696
2697
2698
2700 Registry completes the request successfully and returns a favorable
2701 response.
2703
2706
2707
2710
2711 1000
2712 success
2713
2714
2715 iana-en:222
2716 iana-en:223
2717 DEST_GRP_SSP2_1
2718 +12025556666
2719
2720 true
2721 true
2722 2010-05-30T09:30:10Z
2723
2724
2725
2726
2727
2729 9.15. Get Route Group Request
2731 SSP2 obtains the last provisioned record for the route group
2732 RTE_GRP_SSP2_1.
2734
2735
2739
2740
2741
2742
2743
2744 iana-en:222
2745 RTE_GRP_SSP2_1
2746 RteGrp
2747
2748
2749
2750
2752 Registry completes the request successfully and returns a favorable
2753 response.
2755
2756
2759
2760
2763
2764 1000
2765 success
2766
2767
2768 iana-en:222
2769 iana-en:223
2770 RTE_GRP_SSP2_1
2771
2772
2773 iana-en:222
2774 RTE_SSP2_SBE2
2775 RteRec
2776
2777 100
2778
2779
2780
2781 iana-en:222
2782 RTE_SSP2_SBE4
2783 RteRec
2784
2785 101
2786
2787 DEST_GRP_SSP2_1
2788 true
2789 10
2790
2791
2792
2793
2795 9.16. Get Route Group Offers Request
2797 SSP2 fetches the last provisioned route group offer to the
2798 SSP1.
2800
2801
2804
2805
2806
2807 iana-en:111
2808
2809
2810
2812 Registry processes the request successfully and returns a favorable
2813 response.
2815
2816
2819
2820
2823
2824 1000
2825 success
2826
2827
2828 iana-en:222
2829 iana-en:223
2830
2832
2833 iana-en:222
2834 RTE_GRP_SSP2_1
2835 RteGrp
2836
2837 iana-en:111
2838
2839 offered
2840
2841 2006-05-04T18:13:51.0Z
2842
2843
2844
2846
2847
2849 9.17. Get Egress Route
2851 SSP1 wants to verify the last provisioned record for the egress route
2852 called EGR_RTE_01.
2854
2855
2859
2860
2861
2862
2863
2864 iana-en:111
2865 EGR_RTE_01
2866 EgrRte
2867
2868
2869
2870
2872 Registry completes the request successfully and returns a favorable
2873 response.
2875
2876
2879
2880
2883
2884 1000
2885 success
2886
2887
2888 iana-en:222
2889 iana-en:223
2890 EGR_RTE_01
2891 50
2892
2893 ^(.*)$
2894 sip:\1@sbe1.ssp1.example.com
2895
2896
2897 iana-en:222
2898 RTE_GRP_SSP2_1
2899 RteRec
2900
2901
2902
2903
2904
2906 9.18. Delete Destination Group
2908 SSP2 initiates a request to delete the destination group
2909 DEST_GRP_SSP2_1.
2911
2912
2916
2917
2918
2919
2920
2921 iana-en:222
2922 DEST_GRP_SSP2_1
2923 DestGrp
2924
2925
2926
2927
2929 Registry completes the request successfully and returns a favorable
2930 response.
2932
2933
2935
2936
2939 tx_12354
2940
2941 1000
2942 Request Succeeded.
2943
2944
2945
2946
2948 9.19. Delete Public Identity
2950 SSP2 choses to de-activate the TN and remove it from the registry.
2952
2953
2958
2959
2960
2961
2962
2963 iana-en:222
2964 DEST_GRP_SSP2_1
2965
2966 +12025556666
2967 TN
2968
2969
2970
2971
2972
2974 Registry completes the request successfully and returns a favorable
2975 response.
2977
2978
2980
2981
2984 tx_12354
2985
2986 1000
2987 Request Succeeded.
2988
2989
2990
2991
2993 9.20. Delete Route Group Request
2995 SSP2 removes the route group called RTE_GRP_SSP2_1.
2997
2998
3002
3003
3004
3005
3006
3007 iana-en:222
3008 RTE_GRP_SSP2_1
3009 RteGrp
3010
3011
3012
3013
3015 Registry completes the request successfully and returns a favorable
3016 response.
3018
3019
3021
3022
3025 tx_12354
3026
3027 1000
3028 Request Succeeded.
3029
3030
3031
3032
3034 9.21. Delete Route Group Offers Request
3036 SSP2 no longer wants to share route group RTE_GRP_SSP2_1 with SSP1.
3038
3039
3043
3044
3045
3046
3047
3048
3049 iana-en:222
3050 RTE_GRP_SSP2_1
3051 RteGrp
3052
3053 iana-en:111
3054
3055
3056
3057
3059 Registry completes the request successfully and returns a favorable
3060 response. Restoring this resource sharing will require a new route
3061 group offer from SSP2 to SSP1 followed by a successful route group
3062 accept request from SSP1.
3064
3065
3067
3068
3071 tx_12354
3072
3073 1000
3074 Request Succeeded.
3075
3076
3078
3079
3081 9.22. Delete Egress Route
3083 SSP1 decides to remove the egress route with the label EGR_RTE_01.
3085
3086
3090
3091
3092
3093
3094
3095 iana-en:111
3096 EGR_RTE_01
3097 EgrRte
3098
3099
3100
3101
3103 Registry completes the request successfully and returns a favorable
3104 response.
3106
3107
3109
3110
3113 tx_12354
3114
3115 1000
3116 Request Succeeded.
3117
3118
3119
3121
3123 9.23. Batch Request
3125 Following is an example of how some of the operations mentioned in
3126 previous sections MAY be performed by an SPPP client as a batch in
3127 one single SOAP based SPPP request.
3129 In the sample request below SSP1 wants to accept a Route Group Offer
3130 from SSP3, add a Destination Group, add a NAPTR Route Rec, add a
3131 Route Group, add a Route Group Offer, delete a previously provisioned
3132 TN type Public Identifier, delete a previously provisioned Route
3133 Group, and reject a Route Group Offer from SSP4.
3135
3136
3141
3142
3143
3144 txn_1467
3145 1
3147
3148
3149 iana-en:225
3150 RTE_SSP3_SBE1_Offered
3151 RteGrp
3152
3153 iana-en:222
3154
3156
3157 iana-en:222
3158 iana-en:223
3159 DEST_GRP_SSP2_1
3160
3162
3163 iana-en:222
3164 iana-en:223
3165 RTE_SSP2_SBE2
3166 10
3167 u
3168 E2U+sip
3169
3170 ^(.*)$
3171 sip:\1@sbe2.ssp2.example.com
3172
3173
3175
3176 iana-en:222
3177 iana-en:223
3178 RTE_GRP_SSP2_1
3179
3180
3181 iana-en:222
3182 RTE_SSP2_SBE2
3183 RteRec
3184
3185 100
3186
3187 DEST_GRP_SSP2_1
3188 true
3189 10
3190
3192
3193 iana-en:222
3194 iana-en:223
3195
3196
3197 iana-en:222
3198 RTE_GRP_SSP2_1
3199 RteGrp
3200
3201 iana-en:111
3202
3203 offered
3204
3205 2006-05-04T18:13:51.0Z
3206
3207
3209
3210 iana-en:222
3211 DEST_GRP_SSP2_Previous
3212
3213 +12025556666
3214 TN
3215
3216
3218
3219 iana-en:222
3220 RTE_GRP_SSP2_Previous
3221 RteGrp
3222
3224
3225
3226 iana-en:226
3227 RTE_SSP4_SBE1_Offered
3228 RteGrp
3229
3230 iana-en:222
3231
3233
3234
3235
3237 Registry completes the request successfully and returns a favorable
3238 response.
3240
3241
3243
3244
3247 tx_12354
3248
3249 1000
3250 Request Succeeded.
3251
3252
3253
3254
3256 10. Security Considerations
3258 SPPP is used to query and update session peering data and addresses,
3259 so the ability to access this protocol should be limited to users and
3260 systems that are authorized to query and update this data. Because
3261 this data is sent in both directions, it may not be sufficient for
3262 just the client or user to be authenticated with the server. The
3263 identity of the server should also be authenticated by the client,
3264 which is often accomplished using the TLS certificate exchange and
3265 validation described in [RFC2818]. SPPP data may include sensitive
3266 information, routing data, lists of resolvable addresses, etc. So
3267 when used in a production setting and across non-secure networks,
3268 SPPP should only be used over communications channels that provide
3269 strong encryption for data privacy.
3271 10.1. Integrity, Privacy, and Authentication
3273 The SPPP SOAP binding relies on an underlying secure transport for
3274 integrity and privacy. Such transports are expected to include TLS/
3275 HTTPS. In addition to the application level authentication imposed
3276 by an SPPP server, there are a number of options for authentication
3277 within the transport layer and the messaging envelope. These include
3278 TLS client certificates, HTTP Digest Access Authentication, and
3279 digital signatures within SOAP headers.
3281 At a miniumum, all conforming SPPP over SOAP implementations MUST
3282 support HTTPS.
3284 10.2. Vulnerabilities
3286 The above protocols may have various vulnerabilities, and these may
3287 be inherited by SPPP over SOAP. And SPPP itself may have
3288 vulnerabilities because an authorization model is not explicitly
3289 specified in the current specification.
3291 It is important that SPPP implementations implement an authorization
3292 model that considers the source of each SPPP query or update request
3293 and determines whether it is reasonable to authorize that source to
3294 perform that specific query or update.
3296 10.3. Deployment Environment Specifics
3298 Some deployments of SPPP over SOAP could choose to use transports
3299 without encryption. This presents vulnerabilities but could be
3300 selected for deployments involving closed networks or debugging
3301 scenarios. However, the vulnerabilities of such a deployment could
3302 be a lack of integrity and privacy of the data transported over SPPP
3303 messages in this type of deployment.
3305 11. IANA Considerations
3307 This document uses URNs to describe XML namespaces and XML schemas
3308 conforming to a registry mechanism described in [RFC3688].
3310 URN assignments are requested: urn:ietf:params:xml:ns:sppp:soap
3312 12. Acknowledgements
3314 This document is a result of various discussions held by the DRINKS
3315 design team, which is comprised of the following individuals, in no
3316 specific order: Syed Ali (NeuStar), Sumanth Channabasappa (Cable
3317 Labs), David Schwartz (XConnect), Jean-Francois Mule (CableLabs),
3318 Kenneth Cartwright (TNS, Inc.), Manjul Maharishi (TNS, Inc.),
3319 Alexander Mayrhofer (enum.at GmbH), Vikas Bhatia (TNS, Inc.).
3321 13. References
3323 13.1. Normative References
3325 [I-D.draft-ietf-drinks-spprov]
3326 Mule, J-F., Cartwright, K., Ali, S., Mayrhofer, A., and V.
3327 Bhatia, "DRINKS Use cases and Protocol Requirements",
3328 draft-ietf-drinks-spprov-12 (work in progress), June 2011.
3330 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
3331 Requirement Levels", BCP 14, RFC 2119, March 1997.
3333 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
3334 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
3335 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
3337 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
3338 Leach, P., Luotonen, A., and L. Stewart, "HTTP
3339 Authentication: Basic and Digest Access Authentication",
3340 RFC 2617, June 1999.
3342 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
3343 January 2004.
3345 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
3346 (TLS) Protocol Version 1.2", RFC 5246, August 2008.
3348 [SOAPREF] Gudgin, M., Hadley, M., Moreau, J., and H. Nielsen, "SOAP
3349 Version 1.2 Part 1: Messaging Framework", W3C
3350 Recommendation REC-SOAP12-part1-20030624, June 2002.
3352 13.2. Informative References
3354 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
3356 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
3357 October 2008.
3359 [WSDLREF] Christensen, E., Curbera, F., Meredith, G., and S.
3360 Weerawarana, "Web Services Description Language (WSDL)
3361 1.1", W3C Note NOTE-wsdl-20010315, March 2001.
3363 Authors' Addresses
3365 Kenneth Cartwright
3366 TNS
3367 1939 Roland Clarke Place
3368 Reston, VA 20191
3369 USA
3371 Email: kcartwright@tnsi.com
3373 Vikas Bhatia
3374 TNS
3375 1939 Roland Clarke Place
3376 Reston, VA 20191
3377 USA
3379 Email: vbhatia@tnsi.com