Interoperability considerations: n/a
Security Considerations: cf. Section 9
Relevant Publications: cf. [2] for SOAP version 1.2
Contact Information: Eamon O’Tuathail <eamon.otuathail@clipcode.com>,
Marshall Rose <mrose@dbc.mtview.ca.us>
Author/Change controller: the IESG
8.3. Registration: The soap.beeps URL Scheme
URL scheme name: soap.beeps
URL scheme syntax: cf. Section 6.2
Character encoding considerations: cf. the "generic URI" syntax
defined in Section 3 of [10]
Intended usage: identifies a SOAP resource made available using the
BEEP profile for SOAP after the BEEP session has been tuned for
privacy
Applications using this scheme: cf. "Intended usage", above
Interoperability considerations: n/a
Security Considerations: cf. Section 9
Relevant Publications: cf. [2] for SOAP version 1.2
Contact Information: Eamon O’Tuathail <eamon.otuathail@clipcode.com>,
Marshall Rose <mrose@dbc.mtview.ca.us>
Author/Change controller: the IESG
8.4. Registration: The System (Well-Known) TCP Port Number for SOAP
over BEEP
Protocol Number: TCP
Message Formats, Types, Opcodes, and Sequences: cf. Section 2.1
Functions: cf. [2] for SOAP version 1.2
Use of Broadcast/Multicast: none
Proposed Name: SOAP over BEEP
Short name: soap-beep
Contact Information: Eamon O’Tuathail <eamon.otuathail@clipcode.com>,
Marshall Rose <mrose@dbc.mtview.ca.us>
9. Security Considerations
Although service provisioning is a policy matter, at a minimum, all
implementations MUST provide the following tuning profiles:
for authentication: http://iana.org/beep/SASL/DIGEST-MD5
for confidentiality: http://iana.org/beep/TLS (using the
TLS_RSA_WITH_AES_EDE_CBC_SHA cipher)
for both: http://iana.org/beep/TLS (using the
TLS_RSA_WITH_AES_EDE_CBC_SHA cipher supporting client-side
certificates)
Furthermore, implementations may choose to offer MIME-based security
services providing message integrity and confidentiality, such as
OpenPGP [13] or S/MIME [14].
Regardless, consult [1]’s Section 9 for a discussion of BEEP-specific
security issues.
10. IANA Considerations
Previously, the IANA registered "http://iana.org/beep/soap" for use
with RFC 3288 [16]. This memo requires that the IANA register a
URI-prefix of
http://iana.org/beep/soap/VERSION
to correspond to the family of profiles defined Section 8.1.
The IANA has registered "soap.beep" and "soap.beeps" as URL schemes,
as specified in Section 8.2 and Section 8.3, respectively.
The IANA has also registered "SOAP over BEEP" as a TCP port number,
as specified in Section 8.4.
The IANA now broadens these three registries to support the family of
BEEP profiles defined by this URI prefix.
Finally, the IANA maintains a list of SOAP profile features, cf.
Section 7.1. The IESG is responsible for assigning a designated
expert to review the specification prior to the IANA making the
assignment. Prior to contacting the IESG, developers of SOAP profile
features must use the mailing list beepwg@lists.beepcore.org to
solicit commentary.
11. Changes from RFC 3288
This memo differs from RFC 3288 [16] in one substantive way: a URL
prefix is defined to support a family of BEEP profiles corresponding
to different versions of SOAP. Similarly, the IANA registrations in
Section 8.1, Section 8.3, and Section 8.4 are updated to reflect this
broadening.
Support for W3C MTOM/XOP packaging has been added.
A new section was added to discuss the distributed state machine of
the Request-Response MEP.
In non-substantive ways, a small number of typographical errors were
corrected.
12. Acknowledgements
The authors gratefully acknowledge the contributions of: Christopher
Ferris, Huston Franklin, Alexey Melnikov, Bill Mills, and Roy T.
Fielding.
13. References
13.1. Normative References
[1] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC
3080, March 2001.
[2] Nielsen, H., Mendelsohn, N., Gudgin, M., Hadley, M., and J.
Moreau, "SOAP Version 1.2 Part 1: Messaging Framework", W3C REC
REC-soap12-part1-20030624, June 2003.
[3] Nielsen, H., Hadley, M., Moreau, J., Mendelsohn, N., and M.
Gudgin, "SOAP Version 1.2 Part 2: Adjuncts", W3C REC REC-
soap12-part2-20030624, June 2003.
[4] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol --
HTTP/1.1", RFC 2616, June 1999.
[5] Baker, M. and M. Nottingham, "The "application/soap+xml" media
type", RFC 3902, September 2004.
[6] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types",
RFC 3023, January 2001.
[7] Nottingham, M., Mendelsohn, N., Gudgin, M., and H. Ruellan,
"SOAP Message Transmission Optimization Mechanism", W3C REC
REC-soap12-mtom-20050125, January 2005.
[8] Nottingham, M., Mendelsohn, N., Gudgin, M., and H. Ruellan,
"XML-binary Optimized Packaging", W3C REC REC-xop10-20050125,
January 2005.
[9] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Bodies",
RFC 2045, November 1996.
[10] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986,
January 2005.
[11] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782,
February 2000.
[12] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986,
January 2005.
[13] Elkins, M., Del Torto, D., Levien, R., and T. Roessler, "MIME
Security with OpenPGP", RFC 3156, August 2001.
[14] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions
(S/MIME) Version 3.1 Message Specification", RFC 3851, July
2004.
13.2. Informative References
[15] Mitra, N., "SOAP Version 1.2 Part 0: Primer", W3C REC REC-
soap12-part0-20030624, June 2003.
[16] O’Tuathail, E. and M. Rose, "Using the Simple Object Access
Protocol (SOAP) in Blocks Extensible Exchange Protocol (BEEP)",
RFC 3288, June 2002.
[17] Box, D., Ehnebuske, D., Kakivaya, G., Layman, A., Mendelsohn,
N., Nielsen, H., Thatte, S., and D. Winer, "Simple Object
Access Protocol (SOAP) 1.1", W3C NOTE NOTE-SOAP-20000508, May
2000.
[18] Levinson, E., "The MIME Multipart/Related Content-type", RFC
2387, August 1998.
[19] Barton, J., Thatte, S., and H. Nielsen, "SOAP Messages with
Attachments", W3C NOTE NOTE-SOAP-attachments-20001211, December
2000.
[20] Levinson, E., "Content-ID and Message-ID Uniform Resource
Locators", RFC 2392, August 1998.
[21] Palme, J., Hopmann, A., and N. Shelness, "MIME Encapsulation of
Aggregate Documents, such as HTML (MHTML)", RFC 2557, March
1999.
Appendix A. SOAP with Attachments (Informative)
To provide compatibility with RFC3288 [16], a BEEP profile for SOAP
MAY allow envelopes to be transmitted as the root part of a
"multipart/related" [18] content, and with subordinate parts
referenced using the rules of Section 3 of [19] (i.e., using either
the "Content-ID:" [20] or "Content-Location:" [21] headers), e.g.,
MSG 1 2 . 278 657
Content-Type: multipart/related; boundary="MIME_boundary";
type=application/xml;
start="<claim061400a.xml@claiming-it.com>"
--MIME_boundary
Content-Type: application/xml
Content-ID: <claim061400a.xml@claiming-it.com>
<?xml version=’1.0’ ?>
<env:Envelope
xmlns:env="http://www.w3.org/2003/05/soap-envelope">
..
</env:Header>
<env:Body>
<theSignedForm href="cid:claim061400a.tiff@claiming-it.com" />
..
</env:Body>
</env:Envelope>
--MIME_boundary
Content-Type: image/tiff
Content-Transfer-Encoding: binary
Content-ID: <claim061400a.tiff@claiming-it.com>
...binary TIFF image...
--MIME_boundary--
END
Consistent with Section 2 of [19], it is strongly recommended that
the multipart contain a "start" parameter, and that the root part
contain a "Content-ID:" header. However, because BEEP provides an
8bit-wide path, a "transformative" Content-Transfer-Encoding (e.g.,
"base64" or "quoted-printable") should not be used. Further note
that MIME [9] requires that the value of the "Content-ID" header be
globally unique.
Authors’ Addresses
Eamon O’Tuathail
Clipcode.com
24 Thomastown Road
Dun Laoghaire
Dublin
IE
Phone: +353 1 2350 424
EMail: eamon.otuathail@clipcode.com
URI: http://www.clipcode.com/
Marshall T. Rose
Dover Beach Consulting, Inc.
POB 255268
Sacramento, CA 95865-5268
US
Phone: +1 916 483 8878
EMail: mrose@dbc.mtview.ca.us
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).