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.