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

Re: New Attachments Issues

From: Marc Hadley <Marc.Hadley@Sun.COM>
Date: Wed, 11 Jun 2003 10:06:08 -0400
To: "John J. Barton" <John_Barton@hpl.hp.com>
Cc: Jacek Kopecky <jacek@systinet.com>, XMLP Dist App <xml-dist-app@w3.org>
Message-id: <D973F636-9C15-11D7-A93E-0003937568DC@sun.com>

On Tuesday, Jun 10, 2003, at 13:04 US/Eastern, John J. Barton wrote:

> Senders and receiver necessarily agree on the data formats.
> They will be designed with expectations about the data they
> exchange, including the tradeoffs in space and time embodied
> in the binary/XML issues.  Intermediates should not alter that
> tradeoff willy-nilly.  So there is a fourth option:
>         (iv) intermediates cannot alter the attachments.
> If the intermediate add some value to the exchange, the
> endpoints might allow reformatting in exchange.  But this
> would have to be under control: options involving unspecified (i)
> or by-luck (ii) rearrangement of the tradeoff won't be useful.
>
My initial list of answers was meant to apply to Q2 rather than Q1+Q2. 
I think your (iv) is an answer to my initial Q1:

>> > >> 1: "What are the semantics of attachments w.r.t. SOAP 
>> intermediaries.
>> > >> E.g. do we expect intermediaries to preserve what is serialized 
>> as
>> > >> attachments and what is serialized inside the SOAP envelope."

Clearly your POV is different to Jaceks.

Marc.

>
>
> At 04:56 PM 6/10/2003 +0200, Jacek Kopecky wrote:
>
>> Marc, I think your formulation is precisely what I'd say. 8-)
>>
>> I don't think we ever wanted to consider security mechanisms visible 
>> to
>> the application that would be aware of any optimizations not visible 
>> to
>> the application, like the optimization of binary data in SOAP 
>> messages.
>> I thought the expectation was that dig-sig or encryption would work on
>> canonical base64 representation of the data. There can still be some
>> optimizations in the implementations, e.g. only do the base64 encoding
>> on the fly for signature computation, never store the actual full 
>> base64
>> version of the data. Base64 encoding is cheap and if the signature 
>> code
>> can consume a stream, the cost of base64 encoding will be lost in the
>> cost of computing the signature, I believe (and somebody else has
>> mentioned this before me, too).
>>
>> Best regards,
>>
>>                    Jacek Kopecky
>>
>>                    Senior Architect
>>                    Systinet Corporation
>>                    http://www.systinet.com/
>>
>>
>>
>>
>>
>>
>> On Tue, 2003-06-10 at 16:35, Marc Hadley wrote:
>> > So, to paraphrase, you would say that:
>> >
>> > (1) We DO NOT expect intermediaries to preserve what is serialized 
>> as
>> > attachments and what is serialized inside the SOAP envelope.
>> >
>> > (2) The binding determines which nodes to serialize as attachments 
>> in
>> > an implementation specific manner.
>> >
>> > That's certainly a coherent answer to the two issues.
>> >
>> > Your proposed answers probably have some implications for the set of
>> > security technologies we can apply to messages containing 
>> attachments,
>> > e.g. I expect it would prevent use of S/MIME or PGP-MIME. It also 
>> means
>> > that digital signatures must always be calculated on the text data
>> > representation of attachments and verified using the same - i.e. 
>> even
>> > if you use attachments to optimize the transfer, if you are using 
>> XML
>> > security that includes the attachment data then you always need to
>> > compute the base64 transform at both sender and receiver.
>> >
>> > Marc.
>> >
>> > On Tuesday, Jun 10, 2003, at 07:46 US/Eastern, Jacek Kopecky wrote:
>> >
>> > > As we're only talking about optimization of transfer of binary 
>> data
>> > > (we're not yet talking about the other aspects of PASWA, like
>> > > swa:Representation), it is not critical from our point of view 
>> that the
>> > > optimization be preserved across intermediaries (1) or that it be 
>> done
>> > > at all (2). However, I do think we should say something, so I 
>> prefer
>> > > option (ii) below - that we say your two questions are answered in
>> > > implementations in an implementation-specific way.
>> > >
>> > > It is important that whatever we produce from PASWA emphasizes 
>> the fact
>> > > that we're providing a possible optimization of binary data 
>> transfer
>> > > and
>> > > how it may be particularly useful with the other stuff like
>> > > swa:Representation.
>> > >
>> > > Best regards,
>> > >
>> > >                    Jacek Kopecky
>> > >
>> > >                    Senior Architect
>> > >                    Systinet Corporation
>> > >                    http://www.systinet.com/
>> > >
>> > >
>> > >
>> > >
>> > >
>> > > On Fri, 2003-06-06 at 18:25, Marc Hadley wrote:
>> > >> All,
>> > >>
>> > >> Following the resolution of issue 429[1], I'd like to raise the
>> > >> following new issues:
>> > >>
>> > >> 1: "What are the semantics of attachments w.r.t. SOAP 
>> intermediaries.
>> > >> E.g. do we expect intermediaries to preserve what is serialized 
>> as
>> > >> attachments and what is serialized inside the SOAP envelope."
>> > >>
>> > >> 2: "How does the binding determine which nodes to serialize as
>> > >> attachments ?"
>> > >>
>> > >> Amongst the many possible answers, the following spring 
>> immediately to
>> > >> mind:
>> > >>
>> > >> (i) We don't specify that.
>> > >> (ii) An implementation specific mechanism (similar to (i) but we
>> > >> explicitly say so).
>> > >> (iii) Its triggered by something in the infoset - if so, what.
>> > >>
>> > >> Thanks,
>> > >> Marc.
>> > >>
>> > >> [1] http://www.w3.org/2000/xp/Group/xmlp-issues#x429
>> > >>
>> > >> --
>> > >> Marc Hadley <marc.hadley@sun.com>
>> > >> Web Technologies and Standards, Sun Microsystems.
>> > >
>> > >
>> > --
>> > Marc Hadley <marc.hadley@sun.com>
>> > Web Technologies and Standards, Sun Microsystems.
>
> ______________________________________________________
> John J. Barton          email:  John_Barton@hpl.hp.com
> http://www.hpl.hp.com/personal/John_Barton/index.htm
> MS 1U-17  Hewlett-Packard Labs
> 1501 Page Mill Road              phone: (650)-236-2888
> Palo Alto CA  94304-1126         FAX:   (650)-857-5100
>
>
--
Marc Hadley <marc.hadley@sun.com>
Web Technologies and Standards, Sun Microsystems.
Received on Wednesday, 11 June 2003 10:07:28 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:14 GMT