doc: Add RFC documents

1 files changed, 283 insertions, 0 deletions

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 <web-human@w3.org>
+   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]
+