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