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

Re: PASWA, Include and Protocol Bindings

From: Marc Hadley <Marc.Hadley@Sun.COM>
Date: Thu, 08 May 2003 15:24:17 -0400
To: Mark Nottingham <mark.nottingham@bea.com>
Cc: Martin Gudgin <mgudgin@microsoft.com>, noah_mendelsohn@us.ibm.com, xml-dist-app@w3.org
Message-id: <A8FAF858-818A-11D7-9596-0003937568DC@sun.com>

On Thursday, May 8, 2003, at 14:58 US/Eastern, Mark Nottingham wrote:

>> Also note that messages are transmitted in lexical space so verifying 
>> a
>> sig would require base64 decoding.
>
> Huh? If they're included, they certainly won't be base64-encoded; 
> that's
> the whole point. If you have a "dumb" hop (one that doesn't doInclude, 
> or
> if Noah has his way, one that doesn't support this binding), you would
> need to decode, of course. What am I missing here?
>

You're missing the context ;-). This was a response to your question:

> Your original question was:
>
>> 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 was a reference Gudge's scenario:

> However, consider the following case:
>
> A -> B -> C ->D -> E
>
> where C does NOT understand PASWA. The serialization stream would be as
> follows:
>
> A -PASWA-> B -SOAP1.2HTTP-> C ->SOAP1.2HTTP-> D -PASWA-> E
>
> So, the ultimate receiver ( E ) gets a PASWA message, but along the 
> way,
> it was at some point serialized accordings to the HTTP binding we have
> in SOAP 1.2 today.

Too much snipping !

So yes, C and D are after dumb hops. I thought the promise of PASWA was 
supposed to be that the on the wire serialization was transparent ;-).

Marc.

--
Marc Hadley <marc.hadley@sun.com>
Web Technologies and Standards, Sun Microsystems.
Received on Thursday, 8 May 2003 15:25:36 GMT

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