- From: Jacek Kopecky <jacek@systinet.com>
- Date: Fri, 4 Jan 2002 11:51:37 +0100 (CET)
- To: Mark Baker <distobj@acm.org>
Mark,
I'm not sure the wording "envelope URI" is clear.
Do you mean the access URI or the root element namespace URI?
Even though I don't object to the envelope parameter, I still
think action is inappropriate for "intenet" and "type" are two
different orthogonal things and should be kept as such. Envelope
version is part of the type but intent may vary for one message
on different servers.
Regards,
Jacek Kopecky
Senior Architect, Systinet (formerly Idoox)
http://www.systinet.com/
On Thu, 3 Jan 2002, Mark Baker wrote:
> Here it is. It has *not* been submitted to as an internet draft yet,
> so it should not be referred to using internet-draft naming. i.e. it
> will continue to be called draft-baker-soap-media-reg-00.txt until
> such time as it is published as a draft.
>
> The security section is likely going to be the hot topic. We've managed
> to avoid these issues so far, but that had to come to an end at some
> point. 8-)
>
> Also, the "envelope" parameter is in there, but not one relating to
> encoding.
>
> ==snip==
>
>
> Internet-Draft Mark Baker
> Planetfred, Inc.
> Mark Nottingham
>
> January XX, 2002
>
> The "application/soap+xml" media type
> draft-baker-soap-media-reg-00.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.
>
> 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 1.2 is an XML Infoset[INFOSET] based protocol at the core of
> which is an envelope that defines a framework for describing what is
> in a message and how to process it, and a binding framework for
> exchanging messages using an underlying protocol.
>
> By being based on the XML Infoset, and not XML 1.0 [XML] itself, SOAP
> permits alternate serializations of messages. The
> "application/soap+xml" media type can be used to describe those SOAP
> messages produced with the XML 1.0 serialization.
>
> 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.
>
> envelope
> This parameter can be used to specify the SOAP envelope URI,
> permitting SOAP processors to decide whether they can attempt to
> process the envelope or not.
>
> 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 serialization of the SOAP
> envelope may be recognized.
>
> File extension:
> SOAP messages are not required or expected to be stored as
> files.
>
> Macintosh File Type code: TEXT
>
> Person & email address to contact for further information:
> Mark Baker <mbaker@planetfred.com>
>
> 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
>
> From a security perspective, SOAP can be seen to be used in two
> different ways; tunneled, and non-tunneled.
>
> 3.1 Non-tunneled
>
> The non-tunneled use of SOAP is as an XML 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 security model.
> 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 security implications are the same as for any other
> HTTP POST, up to the point where the SOAP processing model takes over.
>
> The SOAP processing model itself is entirely innocuous from a security
> perspective. The semantic extensions it provides, in addition to the
> syntactic ones provided by the envelope, are;
>
> o "actor", used to target headers to SOAP intermediaries that
> understand its URI value
> o "mustUnderstand", used to require that a SOAP header must be
> understood by a SOAP intermediary, or the message is rejected
>
> "actor" values are URIs, however there are no requirements that a SOAP
> processor attempt to resolve them, so no security issues should result
> from their use. Hostile or broken SOAP intermediaries that don't
> conform to the processing model may break the end-to-end contract
> formed by the use of the "actor" attribute, but that is a known
> problem in all environments with intermediaries. There is no known
> security problem specific to the "actor" attribute in this respect.
>
> "mustUnderstand" has no known security issues, outside the generic
> ones about intermediaries discussed previously in regards to "actor".
>
> 3.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 security model 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 POST is already fairly
> common (including IPP [IPP], 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 several factors affecting a SOAP processor's ability to
> successfully process a SOAP message. These are itemized in Section
> 4.4.5 of [SOAP12P1].
>
> One of these factors, the SOAP envelope namespace, is optionally
> made available to processors through the parameter "envelope"
> described in Section 2.
>
> 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/2001/12/soap-envelope". However,
> this may be expressed in a couple of 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
>
> SOAP 1.1 [SOAP11] introduced the HTTP SOAPAction header, which was
> designed to be used to indicate the "intent" of the SOAP message. Its
> value is a URI reference, and its existence was to be used to
> unambiguously identify SOAP messages tranferred with HTTP. It was
> required because SOAP 1.1 used the generic "text/xml" media type,
> preventing that same information from being communicated on the media
> type where it might normally reside.
>
> As SOAP 1.2 is defining its own media type, the possibility of using
> a parameter on that media type to convey the same information as is
> done with SOAPAction, now exists. "action" is that parameter.
>
> Its semantics are identical to that of the SOAPAction header of SOAP
> 1.2, not SOAP 1.1 (a key difference being that it is optional in SOAP
> 1.2). The following is a mapping of the meanings of the various uses
> of SOAPAction (as described in [SOAP12P2]) to the "action" parameter;
>
> SOAPAction use | "action" parameter
> ------------------------------+------------------------
> |
> SOAPAction: "http://foo/bar" | action="http://foo/bar"
> |
> SOAPAction: "myapp.sdl" | action="myapp.sdl"
> |
> SOAPAction: "" | action=""
> |
> 7. Fragment identifiers
>
> No meaning is associated with fragment identifiers for content
> described by the "application/soap+xml" media type.
>
> 8. Authors' Addresses
>
> Mark A. Baker
> Planetfred, Inc.
> 44 Byward Market, Suite 240
> Ottawa, Ontario, CANADA. K1N 7A2
> tel:+1-613-789-1818
> mailto:mbaker@planetfred.com
>
> Mark Nottingham
> mailto:mnot@mnot.net
>
> 9. References
>
> [XML] "Extensible Markup Language (XML) 1.0", W3C Recommendation,
> February 1998. Available at <http://www.w3.org/TR/REC-xml>
> (or <http://www.w3.org/TR/2000/REC-xml-20001006>).
>
> [INFOSET] "XML Information Set", W3C Recommendation, 24 October 2001,
> Available at <http://www.w3.org/TR/xml-infoset> (or
> <http://www.w3.org/TR/2001/REC-xml-infoset-20011024>).
>
> [XMLMIME] Murata, M., St.Laurent, S., Kohn, D., "XML Media Types",
> RFC 3023, January 2001.
>
> [SOAP11] Box, D., Ehnebuske, D., Kakivaya, G., Layman, A., Mendelsohn,
> N., Nielsen, H., Thatte, S. and D. Winer, "Simple Object Access
> Protocol (SOAP) 1.1", May 2000, <http://www.w3.org/TR/2000/
> NOTE-SOAP-20000508>.
>
> [SOAP12P1] TBD.
> [SOAP12P2] TBD.
>
> [XMLBASE] "XML Base", W3C Recommendation, 27 June 2001. Available at
> <http://www.w3.org/TR/xml-base/> (or
> <http://www.w3.org/TR/2001/REC-xmlbase-20010627/>).
>
> [IPP] Herriot, R., Butler, S., Moore, P., Turner, R. and J. Wenn,
> "Internet Printing Protocol/1.1: Encoding and Transport",
> RFC 2910, September 2000.
>
> MB
>
Received on Friday, 4 January 2002 11:58:48 UTC