W3C home > Mailing lists > Public > xml-dist-app@w3.org > May 2003

Re: PASWA, Include and Protocol Bindings

From: Mark Nottingham <mark.nottingham@bea.com>
Date: Thu, 8 May 2003 10:53:48 -0700
Message-ID: <012701c3158b$7b508da0$a502200a@mnotlaptop>
To: "Marc Hadley" <Marc.Hadley@Sun.COM>, "Martin Gudgin" <mgudgin@microsoft.com>
Cc: <noah_mendelsohn@us.ibm.com>, <xml-dist-app@w3.org>

> 1) With the current data model, how does D decide which parts of the
> SOAP message to serialize as attachments ? Some possible answers are:
> - All instances of base64 typed data (assuming I have a schema, which
> is not necessarily the case for an intermediary, or I can spot base64
> encoded data another way).
> - All instances of base 64 data whose parent EII contains a
> xmime:MediaType attribute.
> - All instances of base64 typed data that is larger than some threshold
> size.

I'd say all of these are reasonable (although #2 makes me wonder whether
some people think that the parent EII of an Include is REQUIRED to carry
xmime:MediaType, which I don't think it a good thing). Serializing binary
data into attachments is an optimisation, and therefore must be
functionally equivalent to base64'ing the data; as a result, it's up to
each node to make these decisions.

I'd add to the list that this information might be carried in a header,
which brings its own tradeoffs; it's likely to be more brittle (especially
if it uses XPath; perhaps associating types with QNames would be more
resilient), but isn't as intrusive into the body.

> 2) If A wants to incorporate message security including the attachments
> then it has a couple of obvious options:
> - Generate signatures based on the base64 encoded version of the data
> (requires base64 encoding step)
> - Use an attachment/xninc:Include aware C14N algorithm that allows
> signing of the raw attachment octets (base64 encoding not required).
> If A uses the latter case, how do C or D determine which instances of
> base64 encoded data to decode prior to signature verification ? This is
> related to the problem described in 1) above.
> If A uses the former case then D better be careful about which parts of
> the message it turns into attachments otherwise it could make
> additional work for E base64 encoding attachments prior to signature
> verification.

An alternative is to use a signature algorithm that (perhaps selectively)
operates on the value space of the content, rather than the lexical space.
This sidesteps the problem by making the attachment mechanism transparent,
as intended.

> A solution to this would be addition of some marker (e.g. an attribute)
> to the parent EII of an xbinc:Include when performing the literal
> inclusion. This would maintain the information that 'this stuff was an
> attachment in a previous hop' that would otherwise be lost in the
> current formulation.

That would be one way of hinting for reserialization. I'm somewhat wary of
mandating a single way of doing this, as I think there are a variety of
use cases, each with its own requirements.

Received on Thursday, 8 May 2003 13:59:01 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:01:23 UTC