RE: Henrik's media type comments

Thanks for sending this out, Mark, many good improvements... A couple of
follow-up points:

Reading the draft again, I think the encoding question (UTF-8 etc.) that
Noah raised is well-covered in section 2 by referring to RFC 3023,
section 3.2.

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

I agree with this direction but I think it may be better to put these
considerations in places where SOAP is actually bound to underlying
protocols, preferably in the security considerations of those bindings.
Given that the media type doesn't really talk about the application
semantics, it makes it hard to relate to without a lot of background
knowledge.

For example, it would be perfectly valid to define a binding that simply
ships SOAP messages around as pure data using this media type. The
security implications of this would be different from using it as "live"
protocol data in, say, our HTTP binding.

The important thing here, I think, is to point people at the security
implications using this media type and that they involve both the
protocol binding *and* the application specific semantics. I agree that
the paragraph doesn't capture this, maybe it could be extended to
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. 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-defined semantics of the data carried in the SOAP
message."

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

Hmm, given that we require XML 1.0 serialization for this media type, I
am not sure what the purpose of the first paragraph in section 5 is:
isn't the purpose of the media type to identify the message as a SOAP
message?

Regarding the second paragraph, I am wondering whether it would be
better to have a reference to SOAP part 1, section on message construct
as this provides all the information about how to recognize a SOAP
message and what to do if it is malformed? 

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

Just a minor nit: Rather than "SOAP HTTP request messages", I would just
say "SOAP messages" as this presumably covers more than just HTTP.

Minor Issues
------------

* Shouldn't there be normal IETF header/footer stuff with page number
etc.?

* A ToC would also be nice

* I think normally the expiration time is stated in the left-upper
corner as part of the front page header rather than in the status
section.

* I would consider deleting the last sentence in the first paragraph in
section 1. I think it is going a bit too deep and I think the second
paragraph follows more naturally without that sentence.

Thanks for the quick follow-up!

Henrik Frystyk Nielsen
mailto:henrikn@microsoft.com

Received on Wednesday, 19 June 2002 11:39:19 UTC