Henrik's media type comments

Henrik made these comments to w3c-xml-protocol-wg on June 2.  I'm
responding now, after making the changes to
draft-baker-soap-media-reg-01.txt.

Henrik wrote;
> 1) Any way to upload the draft to W3C's server and reference it from
> [0]?

Sure, if you can point me to some instructions.

> 2) I would move the 2nd paragraph starting with "Feedback or
> discussion..." in the Introduction to the status as this seems to be a
> typical status thing to say

Done.

> 3) In the introduction, I would add a paragraph saying something along
> the lines:
> 
> "This specification defines the media type "application/soap+xml" which
> can be used to identify SOAP messages carried in MIME or MIME like
> protocols that support the concept of media types for which a SOAP
> binding has been defined."

Oops, of course.  Done, plus added mention of XML.

> 4) Under "Applications which use this media type" I would refer to SOAP
> 1.2's use of the media type.

It's my understanding that "Applications which use this media type"
refers to deployed systems that use it.  The reference to SOAP 1.2 is
under the "Published specification" section above.

> 5) In section 3.1, I would refer to the SOAP 1.2 section on security
> considerations and in particular to the section on security
> considerations and underlying protocols.  In general, I am wondering
> whether it would be more useful in section 3.1 to have some text that
> talks about how SOAP can be used to carry almost any semantics and
> processing a SOAP message should only be done if the impact of doing so
> is understood? FWIW, I think we have similar text in the SOAP 1.2
> security considerations section - it also talks about man-in-the-middle
> attacks. It seems to me that the security concerns regarding the
> application defined portions of SOAP are somewhat more of interest than
> the security concerns of mU and role.

I agree, but when I first wrote it I wasn't sure what it made sense to
talk about in 3.1.  I agree that upon reading those parts of Part 1,
Section 7, that they would make a better fit than discussions about
mu/role.

I'll remove the section, but if anybody objects then I can put it back.
Technically, some information will be lost, but it wasn't really very
important IMO.

> 6) In section 3.2.1 and 3.2.2, I am wondering whether we rather than
> talking about tunneling vs. non-tunneling instead can describe the
> security considerations in terms of the possible semantics of a SOAP
> message as compared to any semantics of the underlying protocol. Maybe
> something like this:
> 
> "Because SOAP can carry application defined data whose semantics is
> independent from that of any underlying protocol, one should not expect
> to be able to understand the semantics of the SOAP message based on the
> semantics of the underlying protocol alone."
> 
> I am not sure SOAP supports tunneling any more than other protocols.
> HTTP also defines a media type for indicating an HTTP message and one
> could just as well tunnel that through HTTP itself or some other
> protocol.

I agree that SOAP doesn't support tunneling, but I think that somewhere
we need to acknowledge the security implications of common practice.
Your paragraph above is a good one to describe the dangers of
tunneling, but I personally think it's valuable to give that practice
a name (by referring to it as "tunneling").  IMO, it makes the topic
more approachable to those not well versed in application protocols.

> 7) In section 4, I think the main interoperability concerns within the
> context of defining a media type is that we say that it must be XML/1.0
> serialization and that this allows people to interoperate.

Is the addition in the intro sufficient?  It's implicit in section 5,
since we talk about XML namespaces there.

> Once we get
> to the point of talking about mustUnderstand faults and the like we have
> passed the point of interoperability. Throwing a SOAP fault is not an
> interoperability problem, not knowing that something is a SOAP message
> is.

Agreed.  I'll remove that.  Done.

> Given this, I would consider merging section 4 and 5 into one -
> given that we define the serialization as XML 1.0 then why are we not
> sure when a SOAP message is a SOAP message?

After re-reading RFC 2048, sec 2.2.5, I don't believe we have any
interoperability considerations at this time.  I was considering
saying something about SOAP 1.1, but didn't feel it necessary.

So I've cleared out the section and said basically "no known issues".

> 8) In section 6, I think we have some more text as to what the action
> can be used for. Also, I am not sure it makes sense to have a relative
> URI value in a media type - I suggest just making it absolute. What
> about adding something to the effect of:

Yah, I just realized this recently too.

> "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."

Very nice, thanks.  Done.

The new version is attached for review by the WG.

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@acm.org
http://www.markbaker.ca        http://www.idokorro.com