idnits 2.17.1 draft-mrose-rfc3288bis-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 943. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 920. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 927. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 933. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 98: '... BEEP profile [1]. Conforming implementations MUST support SOAP...' RFC 2119 keyword, line 99: '... version 1.2 [15] and MAY support other versions, such as SOAP version...' RFC 2119 keyword, line 259: '... SHOULD use the media type "application/soap+xml" [5] e.g.,...' RFC 2119 keyword, line 275: '... To provide compatibility with RFC3288 [16], it MAY use the media type...' RFC 2119 keyword, line 278: '...ation of the BEEP profile for SOAP MAY...' (7 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 13, 2005) is 6921 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) -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' ** Obsolete normative reference: RFC 2616 (ref. '4') (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Downref: Normative reference to an Informational RFC: RFC 3902 (ref. '5') ** Obsolete normative reference: RFC 3023 (ref. '6') (Obsoleted by RFC 7303) -- Possible downref: Non-RFC (?) normative reference: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '8' ** Obsolete normative reference: RFC 2732 (ref. '12') (Obsoleted by RFC 3986) ** Obsolete normative reference: RFC 3851 (ref. '14') (Obsoleted by RFC 5751) -- Obsolete informational reference (is this intentional?): RFC 3288 (ref. '16') (Obsoleted by RFC 4227) Summary: 9 errors (**), 0 flaws (~~), 3 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group E. O'Tuathail 2 Internet-Draft Clipcode.com 3 Expires: November 14, 2005 M. Rose 4 Dover Beach Consulting, Inc. 5 May 13, 2005 7 Using the Simple Object Access Protocol (SOAP) in Blocks Extensible 8 Exchange Protocol (BEEP) 9 draft-mrose-rfc3288bis-02 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on November 14, 2005. 36 Copyright Notice 38 Copyright (C) The Internet Society (2005). 40 Abstract 42 This memo specifies a Simple Object Access Protocol (SOAP) binding to 43 the Blocks Extensible Exchange Protocol core (BEEP). A SOAP binding 44 describes how SOAP messages are transmitted in the network. 46 The SOAP is an XML-based (extensible markup language) messaging 47 protocol used to implement a wide variety of distributed messaging 48 models. It defines a message format and describes a variety of 49 message patterns, including, but not limited to, RPC, asynchronous 50 event notification, unacknowledged messages, and forwarding via SOAP 51 intermediaries. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. BEEP Profile Identification . . . . . . . . . . . . . . . . . 4 57 2.1 Profile Initialization . . . . . . . . . . . . . . . . . . 6 58 3. SOAP Message Packages . . . . . . . . . . . . . . . . . . . . 8 59 4. SOAP Message Patterns . . . . . . . . . . . . . . . . . . . . 11 60 4.1 One-way Message . . . . . . . . . . . . . . . . . . . . . 11 61 4.2 Request-Response Exchange . . . . . . . . . . . . . . . . 11 62 4.3 Request/N-Responses Exchange . . . . . . . . . . . . . . . 11 63 4.4 Error Handling . . . . . . . . . . . . . . . . . . . . . . 11 64 5. SOAP Protocol Binding Framework Conformance . . . . . . . . . 12 65 5.1 Binding Name . . . . . . . . . . . . . . . . . . . . . . . 12 66 5.2 Base URI . . . . . . . . . . . . . . . . . . . . . . . . . 12 67 5.3 Supported SOAP Message Exchange Patterns . . . . . . . . . 12 68 5.4 Supported Features . . . . . . . . . . . . . . . . . . . . 12 69 5.5 MEP Operation . . . . . . . . . . . . . . . . . . . . . . 12 70 5.5.1 Behavior of Requesting SOAP Node . . . . . . . . . . . 12 71 5.5.2 Behavior of Responding SOAP Node . . . . . . . . . . . 13 72 6. URL Schemes . . . . . . . . . . . . . . . . . . . . . . . . . 15 73 6.1 The soap.beep URL Scheme . . . . . . . . . . . . . . . . . 15 74 6.1.1 Resolving IP/TCP Address Information . . . . . . . . . 15 75 6.2 The soap.beeps URL Scheme . . . . . . . . . . . . . . . . 16 76 7. Registration Templates . . . . . . . . . . . . . . . . . . . . 17 77 7.1 SOAP Profile Feature Registration Template . . . . . . . . 17 78 8. Initial Registrations . . . . . . . . . . . . . . . . . . . . 18 79 8.1 Registration: The SOAP Profile . . . . . . . . . . . . . . 18 80 8.2 Registration: The soap.beep URL Scheme . . . . . . . . . . 19 81 8.3 Registration: The soap.beeps URL Scheme . . . . . . . . . 20 82 8.4 Registration: The System (Well-Known) TCP port number 83 for SOAP over BEEP . . . . . . . . . . . . . . . . . . . . 20 84 9. Security Considerations . . . . . . . . . . . . . . . . . . . 21 85 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 86 10.1 Normative References . . . . . . . . . . . . . . . . . . . 22 87 10.2 Non-Normative References . . . . . . . . . . . . . . . . . 23 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 23 89 A. SOAP With Attachments (non-normative) . . . . . . . . . . . . 25 90 B. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26 91 C. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 92 D. Changes from RFC3288 . . . . . . . . . . . . . . . . . . . . . 28 93 Intellectual Property and Copyright Statements . . . . . . . . 29 95 1. Introduction 97 This memo specifies how SOAP envelopes [15] are transmitted using a 98 BEEP profile [1]. Conforming implementations MUST support SOAP 99 version 1.2 [15] and MAY support other versions, such as SOAP version 100 1.1 [17]. This memo specifies how SOAP envelopes [15] are 101 transmitted using a BEEP profile [1]. Unlike its predecessor, 102 RFC3288 [16], this memo does not mandate the use of SOAP version 1.1. 104 Throughout this memo, the term "envelope" refers to the top-level 105 element exchanged by SOAP senders and receivers. For example, when 106 referring to SOAP version 1.2, the term "envelope" refers to the 107 "Envelope" element defined in Section 5.1 of [2]. Further, the terms 108 "peer", "client", "server", "one-to-one", and "one-to-many" are used 109 in the context of BEEP. In particular, Sections 2.1 and 2.1.1 of [1] 110 discuss BEEP roles and exchange styles. 112 2. BEEP Profile Identification 114 The BEEP profile for SOAP is identified as 116 http://iana.org/beep/soap/VERSION 118 in the BEEP "profile" element during channel creation. where 119 "VERSION" refers to the numeric version of the SOAP specification. 121 For example, 123 http://iana.org/beep/soap/1.2 125 refers to version 1.2. 127 Note that RFC3288 [16] used 129 http://iana.org/beep/soap 131 for the purposes of profile identification for SOAP version 1.1 132 envelopes [17]. If an implementation of this memo chooses to 133 implement SOAP version 1.1, then it should support both this URI for 134 profile identification as well as "http://iana.org/beep/soap/1.1". 136 In BEEP, when the first channel is successfully created, the 137 "serverName" attribute in the "start" element identifies the "virtual 138 host" associated with the peer acting in the server role, e.g., 140 141 142 144 The "serverName" attribute is analogous to HTTP's "Host" request- 145 header field (c.f., Section 14.23 of [4]). 147 There are two states in the BEEP profile for SOAP, "boot" and 148 "ready": 150 o In the "boot" state, the peer requesting the creation of the 151 channel sends a "bootmsg" (either during channel initialization or 152 in a "MSG" message). 154 * If the other peer sends a "bootrpy" (either during channel 155 initialization or in a "RPY" message), then the "ready" state 156 is entered 158 * Otherwise, the other peer sends an "error" (either during 159 channel initialization or in a "ERR" message), then no state 160 change occurs. 162 o In the "ready" state, either peer begins a SOAP message pattern by 163 sending a "MSG" message containing an envelope. The other peer 164 completes the message pattern either by: 166 * sending back a "RPY" message containing an envelope; or, 168 * sending back zero or more "ANS" messages, each containing an 169 envelope, followed by a "NUL" message. 171 Regardless, no state change occurs. 173 2.1 Profile Initialization 175 The boot message is used for two purposes: 177 resource identification: each channel bound to the BEEP profile 178 for SOAP provides access to a single resource (a network data 179 object or service). 181 feature negotiation: if new features of SOAP (such as compression) 182 emerge, their use can be negotiated. 184 The DTD syntax for the boot message and its response are: 186 187 191 192 195 The boot message contains a mandatory and an optional attribute: 197 o the "resource" attribute, which is analogous to HTTP's "abs_path" 198 Request-URI parameter (c.f., Section 5.1.2 of [4]); and, 200 o the "features" attribute, which, if present, contains one or more 201 feature tokens, each indicating an optional feature of the BEEP 202 profile for SOAP that is being requested for possible use over the 203 channel. 205 Section 7.1 defines a registration template for optional features. 207 If the peer acting in the server role recognizes the requested 208 resource, it replies with the boot response that contains one 209 optional attribute: 211 o the "features" attribute, if present, contains a subset of the 212 feature tokens in the boot message, indicating which features may 213 be used over the channel. (If not present or empty, then no 214 features may be used.) 216 Otherwise, if the boot message is improperly formed, or if the 217 requested resource isn't recognized, the peer acting in the server 218 role replies with an error message (c.f., Section 7.1 of [1]). 220 Typically, the boot message and its response are exchanged during 221 channel initialization (c.f., Section 2.3.1.2 of [1]). 223 For example, here the boot message and its response are exchanged 224 during channel initialization: 226 C: 227 C: 228 C: ]]> 229 C: 230 C: 232 S: 233 S: ]]> 234 S: 236 The channel bound to the BEEP profile for SOAP is now in the "ready" 237 state. 239 Alternatively, here is an example in which the boot exchange is 240 unsuccessful: 242 C: 243 C: 244 C: ]]> 245 C: 246 C: 248 S: 249 S: resource not 250 S: supported]]> 251 S: 253 Although the channel was created successfully, it remains in the 254 "boot" state. 256 3. SOAP Message Packages 258 The BEEP profile for SOAP transmits envelopes encoded as UTF-8 and 259 SHOULD use the media type "application/soap+xml" [5] e.g., 261 MSG 1 1 . 0 283 262 Content-Type: application/soap+xml 264 267 268 269 270 DIS 271 272 273 END 275 To provide compatibility with RFC3288 [16], it MAY use the media type 276 "application/xml" [6]. 278 In addition, an implementation of the BEEP profile for SOAP MAY 279 support transmission of envelopes using the MTOM [7] / XOP [8] 280 packaging technique e.g., 281 MSG 1 2 . 283 1436 282 MIME-Version: 1.0 283 Content-Type: Multipart/Related;boundary=MIME_boundary; 284 type="application/xop+xml"; 285 start=""; 286 startinfo="application/soap+xml; action=\"ProcessData\"" 287 Content-Description: A SOAP message with my pic and sig in it 289 --MIME_boundary 290 Content-Type: application/xop+xml; 291 charset=UTF-8; 292 type="application/soap+xml; action=\"ProcessData\"" 293 Content-Transfer-Encoding: 8bit 294 Content-ID: 296 299 300 301 305 309 310 311 313 --MIME_boundary 314 Content-Type: image/png 315 Content-Transfer-Encoding: binary 316 Content-ID: 318 // binary octets for png 320 --MIME_boundary 321 Content-Type: application/pkcs7-signature 322 Content-Transfer-Encoding: binary 323 Content-ID: 325 // binary octets for signature 327 --MIME_boundary-- 328 END 329 Consult Section 4.1 of XOP [8] for guidance on MIME Multipart/Related 330 usage. Because BEEP provides an 8bit-wide path, a "transformative" 331 Content-Transfer-Encoding (e.g., "base64" or "quoted-printable") 332 should not be used. Note that MIME [9] requires that the value of 333 the "Content-ID" header be globally unique. As stated in Section 4 334 of XOP [8], XOP may be used with diverse packaging mechanisms. When 335 an implementation of BEEP in SOAP does support MTOM/XOP, it SHOULD 336 support the MIME Multipart/Related XOP Package format, and MAY 337 support others. Additional formats could in future include XOP 338 package formats specific to BEEP (For example, sending the 339 attachments on a different channel to the SOAP channel, which would 340 avoid searching for the MIME boundary tags and allows lazy delivery 341 of attachments - delivering them only when really needed.) 343 4. SOAP Message Patterns 345 4.1 One-way Message 347 A one-way message involves sending a message without any response 348 being returned. 350 The BEEP profile for SOAP achieves this using a one-to-many exchange, 351 in which the client sends a "MSG" message containing an envelope, and 352 the server immediately sends back a "NUL" message, before processing 353 the contents of the envelope. 355 4.2 Request-Response Exchange 357 A request/response exchange involves sending a request, which results 358 in a response being returned. 360 The BEEP profile for SOAP achieves this using a one-to-one exchange, 361 in which the client sends a "MSG" message containing an envelope, and 362 the server sends back a "RPY" message containing an envelope. 364 4.3 Request/N-Responses Exchange 366 A request/N-responses exchange involves sending a request, which 367 results in zero or more responses being returned. 369 The BEEP profile for SOAP achieves this using a one-to-many exchange, 370 in which the client sends a "MSG" message containing an envelope, and 371 the server sends back zero or more "ANS" messages, each containing an 372 envelope, followed by a "NUL" message. 374 4.4 Error Handling 376 The BEEP profile for SOAP does not use the "ERR" message for SOAP 377 faults. When performing one-to-one exchanges, whatever SOAP response 378 (including SOAP faults) generated by the server is always returned in 379 the "RPY" message. When performing one-to-many exchanges, whatever 380 SOAP response (including SOAP faults) generated by the server is 381 always returned in the "ANS" messages. 383 If there is an error with the BEEP message unrelated to the SOAP 384 envelope (e.g. poorly formed MIME message or MIME Content-Type not 385 supported), then the server responds with an ERR message (see Section 386 7.1 of [1]) with an appropriate reply code (e.g. see Section 8 of 387 [1]). 389 5. SOAP Protocol Binding Framework Conformance 391 5.1 Binding Name 393 This binding is identified by a URI that is the exact same as the 394 profile URI for BEEP in SOAP (see Section 2). 396 5.2 Base URI 398 The Base URI for the SOAP envelope is the URI of the resource 399 identified in the bootmsg. 401 5.3 Supported SOAP Message Exchange Patterns 403 An implementation of this binding MUST support the following SOAP 404 message exchange pattern (MEP): 406 o "http://www.w3.org/2003/05/soap/mep/request-response/" (see 407 Section 6.2 of [3].) 409 5.4 Supported Features 411 An implementation of this binding MAY support the following feature: 412 "http://www.w3.org/2003/05/soap/features/action/" (see Section 6.5 of 413 [3].) 415 5.5 MEP Operation 417 For binding instances conforming to this specification: 419 o A SOAP node instantiated at the BEEP peer that initiates the 420 message exchange may assume the role (i.e. the property http:// 421 www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/Role ) of 422 "RequestingSOAPNode". 424 o A SOAP node instantiated at the other BEEP peer may assume the 425 role (i.e. the property http://www.w3.org/2003/05/soap/ 426 bindingFramework/ExchangeContext/Role) of "RespondingSOAPNode". 428 5.5.1 Behavior of Requesting SOAP Node 430 The overall flow of the behavior of a requesting SOAP node follows a 431 state machine description consistent with Section 6.2 of [3]. 433 In order to avoid deadlock during streaming (see Section 6.2.3 of 434 [3]), the requesting SOAP node MUST be able to process incoming SOAP 435 response information while the SOAP request is still being 436 transmitted. 438 5.5.1.1 Init 440 In the "Init" state, a BEEP message is formulated according to 441 Section 3, transmission of the message begins and then the state 442 changes to "Requesting". 444 5.5.1.2 Requesting 446 In the "Requesting" state, more of the request message is 447 transmitted and the arrival of the response is awaited. When the 448 beginning of the response message is received, if it is a BEEP ERR 449 message then the state transitions to "Fail"; otherwise the state 450 transitions to "Sending+Receiving". 452 5.5.1.3 Sending+Receiving 454 In the "Sending+Receiving" state, the transmission of the request 455 message and receiving of the response message is completed. The 456 response message is assumed to contain a SOAP envelope serialized 457 according to the rules for carrying SOAP messages in the media type 458 given in the Content-Type header field. Once the receipt of the 459 response is completed, the state transitions to "Success". 461 5.5.1.4 Success and Fail 463 "Success" and "Fail" are the terminal states for the state machine. 465 5.5.2 Behavior of Responding SOAP Node 467 The overall flow of the behavior of a responding SOAP node follows a 468 state machine description consistent with Section 6.2 of [3] 470 5.5.2.1 Init 472 In the "Init" state, the binding awaits the start of the inbound 473 request. In this state, it may only generate ERR messages (in 474 accordance with Section 4.4). 476 5.5.2.2 Receiving 478 The binding begins to receive the request message and prepares the 479 start of the response, in accordance with Section 3. When ready to 480 transmit the response, the state transitions to "Receiving+Sending". 482 5.5.2.3 Receiving+Sending 484 The binding completes the receiving of the request and sending of the 485 response and then transitions to "Success" state. 487 5.5.2.4 Success and Fail 489 "Success" and "Fail" are the terminal states that indicate completion 490 of the message exchange. 492 6. URL Schemes 494 This memo defines two URL schemes, "soap.beep" and "soap.beeps", 495 which identify the use of SOAP over BEEP over TCP. Note that, at 496 present, a "generic" URL scheme for SOAP is not defined. 498 6.1 The soap.beep URL Scheme 500 The "soap.beep" URL scheme uses the "generic URI" syntax defined in 501 Section 3 of [10], specifically: 503 o the value "soap.beep" is used for the scheme component; and, 505 o the server-based naming authority defined in Section 3.2.2 of [10] 506 is used for the authority component. 508 o the path component maps to the "resource" component of the boot 509 message sent during profile initialization (if absent, it defaults 510 to "/"). 512 The values of both the scheme and authority components are case- 513 insensitive. 515 For example, the URL 517 soap.beep://stockquoteserver.example.com/StockQuote 519 might result in the example shown in Section 2.1. 521 6.1.1 Resolving IP/TCP Address Information 523 The "soap.beep" URL scheme indicates the use of the BEEP profile for 524 SOAP running over TCP/IP. 526 If the authority component contains a domain name and a port number, 527 e.g., 529 soap.beep://stockquoteserver.example.com:1026 531 then the DNS is queried for the A RRs corresponding to the domain 532 name, and the port number is used directly. 534 If the authority component contains a domain name and no port number, 535 e.g., 537 soap.beep://stockquoteserver.example.com 539 the SRV algorithm [11] is used with a service parameter of "soap- 540 beep" and a protocol parameter of "tcp" to determine the IP/TCP 541 addressing information. If no appropriate SRV RRs are found (e.g., 542 for "_soap-beep._tcp.stockquoteserver.example.com"), then the DNS is 543 queried for the A RRs corresponding to the domain name and the port 544 number used is assigned by the IANA for the registration in 545 Section 8.4. 547 If the authority component contains an IP address, e.g., 549 soap.beep://10.0.0.2:1026 551 then the DNS is not queried, and the IP address is used directly. If 552 a port number is present, it is used directly; otherwise, the port 553 number used is assigned by the IANA for the registration in 554 Section 8.4. 556 While the use of literal IPv6 addresses in URLs is discouraged, if a 557 literal IPv6 address is used in a "soap.beep" URL, it must conform to 558 the syntax specified in [12]. 560 6.2 The soap.beeps URL Scheme 562 The "soap.beeps" URL scheme is identical, in all ways, to the 563 "soap.beep" URL scheme specified in Section 6.1, with the exception 564 that prior to starting the BEEP profile for SOAP, the BEEP session 565 must be tuned for privacy. In particular, note that both URL schemes 566 use the identical algorithms and parameters for address resolution as 567 specified in Section 6.1.1 (e.g., the same service name for SRV 568 lookups, the same port number for TCP, and so on). 570 There are two ways to perform privacy tuning on a BEEP session, 571 either: 573 o a transport security profile may be successfully started; or, 575 o a user authentication profile that supports transport security may 576 be successfully started. 578 Regardless, upon completion of the negotiation process, a tuning 579 reset occurs in which both BEEP peers issue a new greeting. Consult 580 Section 3 of [1] for an example of how a BEEP peer may choose to 581 issue different greetings based on whether privacy is in use. 583 7. Registration Templates 585 7.1 SOAP Profile Feature Registration Template 587 When a feature for the BEEP profile for SOAP is registered, the 588 following information is supplied: 590 Feature Identification: specify a string that identifies this 591 feature. Unless the feature is registered with the IANA, the 592 feature's identification must start with "x-". 594 Feature Semantics: specify the semantics of the feature. 596 Contact Information: specify the electronic contact information for 597 the author of the feature. 599 8. Initial Registrations 601 8.1 Registration: The SOAP Profile 603 Profile Identification: http://iana.org/beep/soap/VERSION 605 Messages exchanged during Channel Creation: bootmsg, bootrpy 607 Messages starting one-to-one exchanges: bootmsg, a SOAP "envelope" 609 Messages in positive replies: bootrpy, a SOAP "envelope" 611 Messages in negative replies: error 613 Messages in one-to-many exchanges: a SOAP "envelope" 615 Message Syntax: a SOAP envelope 617 Message Semantics: corresponds to the relevant SOAP specification, 618 e.g., for SOAP version 1.2, c.f., [2]. 620 Contact Information: Eamon O'Tuathail , 621 Marshall Rose 623 8.2 Registration: The soap.beep URL Scheme 625 URL scheme name: soap.beep 627 URL scheme syntax: c.f., Section 6.1 629 Character encoding considerations: c.f., the "generic URI" syntax 630 defined in Section 3 of [10] 632 Intended usage: identifies a SOAP resource made available using the 633 BEEP profile for SOAP 635 Applications using this scheme: c.f., "Intended usage", above 637 Interoperability considerations: n/a 639 Security Considerations: c.f., Section 9 641 Relevant Publications: c.f., [2] for SOAP version 1.2 643 Contact Information: Eamon O'Tuathail , 644 Marshall Rose 646 Author/Change controller: the IESG 648 8.3 Registration: The soap.beeps URL Scheme 650 URL scheme name: soap.beeps 652 URL scheme syntax: c.f., Section 6.2 654 Character encoding considerations: c.f., the "generic URI" syntax 655 defined in Section 3 of [10] 657 Intended usage: identifies a SOAP resource made available using the 658 BEEP profile for SOAP after the BEEP session has been tuned for 659 privacy 661 Applications using this scheme: c.f., "Intended usage", above 663 Interoperability considerations: n/a 665 Security Considerations: c.f., Section 9 667 Relevant Publications: c.f., [2] for SOAP version 1.2 669 Contact Information: Eamon O'Tuathail , 670 Marshall Rose 672 Author/Change controller: the IESG 674 8.4 Registration: The System (Well-Known) TCP port number for SOAP over 675 BEEP 677 Protocol Number: TCP 679 Message Formats, Types, Opcodes, and Sequences: c.f., Section 2.1 681 Functions: c.f., [2] for SOAP version 1.2 683 Use of Broadcast/Multicast: none 685 Proposed Name: SOAP over BEEP 687 Short name: soap-beep 689 Contact Information: Eamon O'Tuathail , 690 Marshall Rose 692 9. Security Considerations 694 Although service provisioning is a policy matter, at a minimum, all 695 implementations MUST provide the following tuning profiles: 697 for authentication: http://iana.org/beep/SASL/DIGEST-MD5 699 for confidentiality: http://iana.org/beep/TLS (using the 700 TLS_RSA_WITH_AES_EDE_CBC_SHA cipher) 702 for both: http://iana.org/beep/TLS (using the 703 TLS_RSA_WITH_AES_EDE_CBC_SHA cipher supporting client-side 704 certificates) 706 Further, implementations may choose to offer MIME-based security 707 services providing message integrity and confidentiality, such as 708 OpenPGP [13] or S/MIME [14]. 710 Regardless, consult [1]'s Section 9 for a discussion of BEEP-specific 711 security issues. 713 10. References 715 10.1 Normative References 717 [1] Rose, M., "The Blocks Extensible Exchange Protocol Core", 718 RFC 3080, March 2001. 720 [2] Nielsen, H., Mendelsohn, N., Gudgin, M., Hadley, M., and J. 721 Moreau, "SOAP Version 1.2 Part 1: Messaging Framework", W3C 722 REC REC-soap12-part1-20030624, June 2003. 724 [3] Nielsen, H., Hadley, M., Moreau, J., Mendelsohn, N., and M. 725 Gudgin, "SOAP Version 1.2 Part 2: Adjuncts", W3C REC REC- 726 soap12-part2-20030624, June 2003. 728 [4] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., 729 Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- 730 HTTP/1.1", RFC 2616, June 1999. 732 [5] Baker, M. and M. Nottingham, "The "application/soap+xml" media 733 type", RFC 3902, September 2004. 735 [6] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", 736 RFC 3023, January 2001. 738 [7] Nottingham, M., Mendelsohn, N., Gudgin, M., and H. Ruellan, 739 "SOAP Message Transmission Optimization Mechanism", W3C 740 REC REC-soap12-mtom-20050125, January 2005. 742 [8] Nottingham, M., Mendelsohn, N., Gudgin, M., and H. Ruellan, 743 "XML-binary Optimized Packaging", W3C REC REC-xop10-20050125, 744 January 2005. 746 [9] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 747 Extensions (MIME) Part One: Format of Internet Message Bodies", 748 RFC 2045, November 1996. 750 [10] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 751 Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, 752 January 2005. 754 [11] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 755 specifying the location of services (DNS SRV)", RFC 2782, 756 February 2000. 758 [12] Hinden, R., Carpenter, B., and L. Masinter, "Format for Literal 759 IPv6 Addresses in URL's", RFC 2732, December 1999. 761 [13] Elkins, M., Del Torto, D., Levien, R., and T. Roessler, "MIME 762 Security with OpenPGP", RFC 3156, August 2001. 764 [14] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions 765 (S/MIME) Version 3.1 Message Specification", RFC 3851, 766 July 2004. 768 10.2 Non-Normative References 770 [15] Mitra, N., "SOAP Version 1.2 Part 0: Primer", W3C REC REC- 771 soap12-part0-20030624, June 2003. 773 [16] O'Tuathail, E. and M. Rose, "Using the Simple Object Access 774 Protocol (SOAP) in Blocks Extensible Exchange Protocol (BEEP)", 775 RFC 3288, June 2002. 777 [17] Box, D., Ehnebuske, D., Kakivaya, G., Layman, A., Mendelsohn, 778 N., Nielsen, H., Thatte, S., and D. Winer, "Simple Object 779 Access Protocol (SOAP) 1.1", W3C NOTE NOTE-SOAP-20000508, 780 May 2000. 782 [18] Levinson, E., "The MIME Multipart/Related Content-type", 783 RFC 2387, August 1998. 785 [19] Barton, J., Thatte, S., and H. Nielsen, "SOAP Messages with 786 Attachments", W3C NOTE NOTE-SOAP-attachments-20001211, 787 December 2000. 789 [20] Levinson, E., "Content-ID and Message-ID Uniform Resource 790 Locators", RFC 2392, August 1998. 792 [21] Palme, F., Hopmann, A., Shelness, N., and E. Stefferud, "MIME 793 Encapsulation of Aggregate Documents, such as HTML (MHTML)", 794 RFC 2557, March 1999. 796 Authors' Addresses 798 Eamon O'Tuathail 799 Clipcode.com 800 24 Thomastown Road 801 Dun Laoghaire 802 Dublin 803 IE 805 Phone: +353 1 2350 424 806 Email: eamon.otuathail@clipcode.com 807 URI: http://www.clipcode.com/ 809 Marshall T. Rose 810 Dover Beach Consulting, Inc. 811 POB 255268 812 Sacramento, CA 95865-5268 813 US 815 Phone: +1 916 483 8878 816 Email: mrose@dbc.mtview.ca.us 818 Appendix A. SOAP With Attachments (non-normative) 820 To provide compatibility with RFC3288 [16], a BEEP profile for SOAP 821 MAY allow envelopes to be transmitted as the root part of a 822 "multipart/related" [18] content, and with subordinate parts 823 referenced using the rules of Section 3 of [19] (i.e., using either 824 the "Content-ID:" [20] or "Content-Location:" [21] headers), e.g., 826 MSG 1 2 . 278 668 827 Content-Type: multipart/related; boundary="MIME_boundary"; 828 type=application/xml; 829 start="" 831 --MIME_boundary 832 Content-Type: application/xml 833 Content-ID: 835 836 840 841 842 .. 843 844 846 --MIME_boundary 847 Content-Type: image/tiff 848 Content-Transfer-Encoding: binary 849 Content-ID: 851 ...binary TIFF image... 852 --MIME_boundary-- 853 END 855 Consistent with Section 2 of [19], it is strongly recommended that 856 the multipart contain a "start" parameter, and that the root part 857 contain a "Content-ID:" header. However, because BEEP provides an 858 8bit-wide path, a "transformative" Content-Transfer-Encoding (e.g., 859 "base64" or "quoted-printable") should not be used. Further note 860 that MIME [9] requires that the value of the "Content-ID" header be 861 globally unique. 863 Appendix B. Acknowledgements 865 The authors gratefully acknowledge the contributions of: Christopher 866 Ferris, Huston Franklin, Alexey Melnikov, Bill Mills, and Roy T. 867 Fielding. 869 Appendix C. IANA Considerations 871 Previously, the IANA registered "http://iana.org/beep/soap" for use 872 with RFC3288 [16]. This memo requires that the IANA register a URI- 873 prefix of 875 http://iana.org/beep/soap/VERSION 877 to correspond to the family of profiles defined Section 8.1. 879 The IANA has registered "soap.beep" and "soap.beeps" as URL schemes, 880 as specified in Section 8.2 and Section 8.3, respectively. 882 The IANA has also registered "SOAP over BEEP" as a TCP port number, 883 as specified in Section 8.4. 885 The IANA now broadens these three registries to support the family of 886 BEEP profiles defined by this URI prefix. 888 Finally, the IANA maintains a list of SOAP profile features, c.f., 889 Section 7.1. The IESG is responsible for assigning a designated 890 expert to review the specification prior to the IANA making the 891 assignment. Prior to contacting the IESG, developers of SOAP profile 892 features must use the mailing list beepwg@lists.beepcore.org to 893 solicit commentary. 895 Appendix D. Changes from RFC3288 897 This memo differs from RFC3288 [16] in one substantive way: a URL 898 prefix is defined to support a family of BEEP profiles corresponding 899 to different versions of SOAP. Similarly, the IANA registrations in 900 Section 8.1, Section 8.3, and Section 8.4 are updated to reflect this 901 broadening. 903 Support for W3C MTOM/XOP packaging has been added. 905 A new section was added to discuss the distributed state machine of 906 the Request-Response MEP. 908 In non-substantive ways, a small number of typographical errors were 909 corrected. 911 Intellectual Property Statement 913 The IETF takes no position regarding the validity or scope of any 914 Intellectual Property Rights or other rights that might be claimed to 915 pertain to the implementation or use of the technology described in 916 this document or the extent to which any license under such rights 917 might or might not be available; nor does it represent that it has 918 made any independent effort to identify any such rights. Information 919 on the procedures with respect to rights in RFC documents can be 920 found in BCP 78 and BCP 79. 922 Copies of IPR disclosures made to the IETF Secretariat and any 923 assurances of licenses to be made available, or the result of an 924 attempt made to obtain a general license or permission for the use of 925 such proprietary rights by implementers or users of this 926 specification can be obtained from the IETF on-line IPR repository at 927 http://www.ietf.org/ipr. 929 The IETF invites any interested party to bring to its attention any 930 copyrights, patents or patent applications, or other proprietary 931 rights that may cover technology that may be required to implement 932 this standard. Please address the information to the IETF at 933 ietf-ipr@ietf.org. 935 Disclaimer of Validity 937 This document and the information contained herein are provided on an 938 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 939 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 940 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 941 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 942 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 943 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 945 Copyright Statement 947 Copyright (C) The Internet Society (2005). This document is subject 948 to the rights, licenses and restrictions contained in BCP 78, and 949 except as set forth therein, the authors retain all their rights. 951 Acknowledgment 953 Funding for the RFC Editor function is currently provided by the 954 Internet Society.