A WORK IN PROGRESS. NOT YET PUBLISHED!! Internet-Draft Mark Baker Idokorro Mobile, Inc. Mark Nottingham May XX, 2002 The "application/soap+xml" media type draft-baker-soap-media-reg-01.txt Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire in July, 2003. Feedback or discussion about this draft should be directed to the XML Protocol Working Group public mailing list, xml-dist-app@w3.org with archives at http://lists.w3.org/Archives/Public/xml-dist-app/ Abstract This document defines the "application/soap+xml" media type which can be used to describe SOAP 1.2 messages serialized as XML. 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. The framework has been designed to be independent of any particular programming model and other implementation specific semantics. This specification defines the media type "application/soap+xml" which can be used to identify SOAP messages serialized with XML 1.0, carried in MIME or MIME like protocols that support the concept of media types for which a SOAP binding has been defined. 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 [XMLMIME]. action See Section 6 of this document. Encoding considerations: Identical to those of "application/xml" as described in [XMLMIME], Section 3.2. Security considerations: See Section 3 of this document. Interoperability considerations: See Section 4 of this document. Published specification: See [SOAP12P1] and [SOAP12P2]. Applications which use this media type: No known applications currently use this media type. Additional information: Magic number: There is no single initial byte sequence that is always present for SOAP messages. Section 5 below gives some context for why recognizing a SOAP message without any metadata is problematic, and some guidelines on how the XML 1.0 [XML] serialization of the SOAP envelope may be recognized. 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 [XMLMIME], Section 5. Macintosh File Type code: TEXT Person & email address to contact for further information: Mark Baker 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 The following subsection describes different types of security considerations as they relate to SOAP. See also SOAP 1.2 Part 1 [SOAP12P1], Section 7, for a more in depth look at SOAP specific security considerations. Also, as this media type uses the "+xml" convention, it has the same security considerations as described in [XMLMIME], Section 10. 3.1 Considerations of the different uses of SOAP From a security perspective, SOAP can be seen to be used in two different ways; tunneled, and non-tunneled. 3.1.1 Non-tunneled The non-tunneled use of SOAP is as an XML Infoset [INFOSET] based envelope whose hop-by-hop transfer semantics are inherited from the application protocol used for that hop. In this use, the binding of SOAP to that protocol extends the application semantics of the protocol without modifying or otherwise disrupting the existing semantics. This includes the safety provided by the fixed interface of the application protocol. For example, when bound to HTTP using the SOAP 1.2 default HTTP binding, the transfer of a SOAP envelope is performed with HTTP POST semantics, and the safety implications are the same as for any other HTTP POST. 3.1.2 Tunneled Another use of SOAP is as a framework for building and deploying new protocols, tunneled over the underlying protocol to which it is bound. If the underlying protocol is an application protocol, then any safety afforded by the fixed interface of that protocol would be disregarded (by definition of "tunnel"). It will be up to the designer of the new protocol to ensure that its semantics are safe. That SOAP explicitly supports tunneling would at first glance appear to be a problem. However, as tunneling over application protocols is already fairly common (including IPP, RFC 2910) , on the IETF Internet standards track), the possibility of consolidating future tunneling practice within a framework such as SOAP should help security in the long run. As a worst case from a security perspective, if SOAP were used only for tunneling, it would be no worse than the tunneling that exists today. 4. Interoperability considerations There are no known interoperability issues. 5. Recognizing SOAP messages SOAP 1.2 does not require or assume that SOAP 1.2 messages have any particular serialization, making it impossible to determine (in the absence of other information) when a chunk of data is a SOAP 1.2 message or not. However, for the case of the XML 1.0 serialization of SOAP 1.2 messages, the following best describes how these messages may be recognized. The root element of the message will always be named "Envelope" with the namespace "http://www.w3.org/2002/06/soap-envelope". However, this may be expressed in two ways; o with an xmlns declaration on the root element o with a prefix-adorned xmlns declaration on the root element where "envelope" is so prefixed 6. The "action" parameter 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 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. 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. The presence and content of the SOAPAction header field MAY be used by servers such as firewalls to appropriately filter SOAP HTTP request messages and it may be used by servers to facilitate dispatching of SOAP messages to internal message handlers etc. It SHOULD NOT be used as an insecure form of access authorization. 7. Base URI As specified in RFC 3023, Section 6. Also see [SOAP12P1] Section 6. 8. Authors' Addresses Mark A. Baker Idokorro Mobile, Inc. 44 Byward Market, Suite 240 Ottawa, Ontario, CANADA. K1N 7A2 tel:+1-613-789-1818 mailto:mbaker@idokorro.com Mark Nottingham mailto:mnot@mnot.net 9. References [XML] "Extensible Markup Language (XML) 1.0", W3C Recommendation, February 1998. Available at (or ). [INFOSET] "XML Information Set", W3C Recommendation, 24 October 2001, Available at (or ). [XMLMIME] "XML Media Types", RFC 3023, January 2001. Murata, M., St.Laurent, S., Kohn, D. [SOAP12P1] "SOAP Version 1.2 Part 1: Messaging Framework", W3C Working Draft (work in progress), December 2001. Gudgin, M., Hadley, M., Moreau, JJ., Nielsen, H. . [SOAP12P2] "SOAP Version 1.2 Part 2: Adjuncts", W3C Working Draft (work in progress), December 2001. Gudgin, M., Hadley, M., Moreau, JJ., Nielsen, H. .