From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc3902.txt | 283 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 283 insertions(+) create mode 100644 doc/rfc/rfc3902.txt (limited to 'doc/rfc/rfc3902.txt') diff --git a/doc/rfc/rfc3902.txt b/doc/rfc/rfc3902.txt new file mode 100644 index 0000000..ea22a7c --- /dev/null +++ b/doc/rfc/rfc3902.txt @@ -0,0 +1,283 @@ + + + + + + +Network Working Group M. Baker +Request for Comments: 3902 Independent +Category: Informational M. Nottingham + BEA Systems + September 2004 + + + The "application/soap+xml" media type + +Status of this Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2004). + +Abstract + + This document defines the "application/soap+xml" media type which can + be used to describe SOAP 1.2 messages serialized as XML 1.0. + +1. Introduction + + SOAP version 1.2 (SOAP) is a lightweight protocol intended for + exchange of structured information between peers in a decentralized, + distributed environment. It defines an extensible messaging + framework that contains a message construct based on XML technologies + that can be exchanged over a variety of underlying protocols. + + This specification defines the media type "application/soap+xml" + which can be used to identify SOAP 1.2 message envelopes that have + been serialized with XML 1.0. Such serializations are useful as the + basis of "wire formats" for SOAP 1.2 Protocol Binding Specifications + [W3C.REC-soap12-part1-20030624], or in other situations where an XML + serialization of a SOAP envelope is required. + + The "application/soap+xml" media type explicitly identifies SOAP 1.2 + message envelopes that have been serialised with XML 1.0; message + envelopes with a different SOAP namespace version or using another + XML serialisation MUST NOT use it. + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC2119]. + + + + +Baker & Nottingham Informational [Page 1] + +RFC 3902 The "application/soap+xml" media type September 2004 + + +2. Registration + + MIME media type name: application + MIME subtype name: soap+xml + Required parameters: none + Optional parameters: + + "charset": This parameter has identical semantics to the charset + parameter of the "application/xml" media type as specified in + RFC 3023 [RFC3023]. + + "action": This optional parameter can be used to specify the URI + that identifies the intent of the message. In SOAP 1.2, it + serves a similar purpose as the SOAPAction HTTP header field + did in SOAP 1.1. Namely, its value identifies the intent of + the message. + + The value of the action parameter is an absolute URI-reference + as defined by RFC 2396 [RFC2396], which MUST be non-empty. + SOAP places no restrictions on the specificity of the URI or + that it is resolvable. Although the purpose of the action + parameter is to indicate the intent of the SOAP message there + is no mechanism for automatically computing the value based on + the SOAP envelope. In other words, the value has to be + determined out of band. It is recommended that the same value + be used to identify sets of message types that are logically + connected in some manner, for example part of the same + "service". It is strongly RECOMMENDED that the URI be globally + unique and stable over time. + + Use of the action parameter is OPTIONAL. SOAP Receivers MAY + use it as a hint to optimize processing, but SHOULD NOT require + its presence in order to operate. + + Encoding considerations: Identical to those of "application/xml" as + described in RFC 3023 [RFC3023], section 3.2, as applied to the + SOAP envelope infoset. + + Security considerations: Because SOAP can carry application defined + data whose semantics is independent from that of any MIME wrapper + (or context within which the MIME wrapper is used), one should not + expect to be able to understand the semantics of the SOAP message + based on the semantics of the MIME wrapper alone. Therefore, + whenever using the "application/soap+xml" media type, it is + strongly RECOMMENDED that the security implications of the context + within which the SOAP message is used is fully understood. The + security implications are likely to involve both the specific SOAP + binding to an underlying protocol as well as the application- + + + +Baker & Nottingham Informational [Page 2] + +RFC 3902 The "application/soap+xml" media type September 2004 + + + defined semantics of the data carried in the SOAP message (though + one must be careful when doing this, as discussed in SOAP 1.2 Part + 1 [W3C.REC-soap12-part1-20030624], section Binding to + Application-Specific Protocols). + + Also, see SOAP 1.2 Part 1 [W3C.REC-soap12-part1-20030624], the + entire section Security Considerations. + + In addition, as this media type uses the "+xml" convention, it + shares the same security considerations as described in RFC 3023 + [RFC3023], section 10. + + The action parameter is not a security mechanism, and SHOULD NOT + be used for authentication. If the action parameter is used to + make decisions (e.g., dispatch, filtering), it is RECOMMENDED that + the basis for such decisions should be confirmed by examining the + SOAP Envelope. + + Interoperability considerations: There are no known interoperability + issues. + + Published specification: SOAP 1.2 Part 1 + [W3C.REC-soap12-part1-20030624] and SOAP 1.2 Part 2 + [W3C.REC-soap12-part2-20030624]. + + Applications which use this media type: Various SOAP 1.2 conformant + toolkits use this media type. + + Additional information: + File extension: SOAP messages are not required or expected to be + stored as files. + Fragment identifiers: Identical to that of "application/xml" as + described in RFC 3023 [RFC3023], section 5. + Base URI: As specified in RFC 3023 [RFC3023], section 6. Also see + SOAP 1.2 Part 1 [W3C.REC-soap12-part1-20030624], section Use of + URIs in SOAP. + Macintosh File Type code: TEXT + Person and email address to contact for further information: + World Wide Web Consortium + Intended usage: COMMON + Author/Change controller: The SOAP 1.2 specification set is a work + product of the World Wide Web Consortium's XML Protocol Working + Group. The W3C has change control over these specifications. + +3. Security Considerations + + See the "Security Considerations" section of the registration + template found in Section 2. + + + +Baker & Nottingham Informational [Page 3] + +RFC 3902 The "application/soap+xml" media type September 2004 + + +4. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform + Resource Identifiers (URI): Generic Syntax", RFC 2396, + August 1998. + + [RFC3023] Murata, M., St.Laurent, S., and D. Kohn, "XML Media + Types", RFC 3023, January 2001. + + [W3C.REC-soap12-part1-20030624] + Hadley, M., Mendelsohn, N., Moreau, J., Nielsen, H., and + M. Gudgin, "SOAP Version 1.2 Part 1: Messaging + Framework", W3C REC REC-soap12-part1-20030624, June 2003. + + [W3C.REC-soap12-part2-20030624] + Moreau, J., Nielsen, H., Gudgin, M., Hadley, M., and N. + Mendelsohn, "SOAP Version 1.2 Part 2: Adjuncts", W3C REC + REC-soap12-part2-20030624, June 2003. + +5. Authors' Addresses + + Mark A. Baker + Independent + 37 Charles St. + Ottawa, Ontario K1M 1R3 + CA + + EMail: distobj@acm.org + + + Mark Nottingham + BEA Systems + 235 Montgomery St., Level 15 + San Francisco, CA 94010 + US + + EMail: mnot@pobox.com + + + + + + + + + + + +Baker & Nottingham Informational [Page 4] + +RFC 3902 The "application/soap+xml" media type September 2004 + + +6. Full Copyright Statement + + Copyright (C) The Internet Society (2004). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and at www.rfc-editor.org, 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/S HE + 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 ISOC's procedures with respect to rights in ISOC 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 currently provided by the + Internet Society. + + + + + + + +Baker & Nottingham Informational [Page 5] + -- cgit v1.2.3