RE: Proposal for new last call issue: Some unprocessed headers should stay

Henrik, 

if the semantics of the header are such that it can be applied on the
back link breaking the application if it was not also applied on the
previous node on its forward link, what prevents the application from
breaking at B? Unless, of course, B and C can understand a header
differently, which would be insane. 8-)

As for the store and forward semantics, why doesn't the node that knows
it's before a weak link play a special role, like "weakLinkProxy"? I
would then probably want to address all weakLinkProxies to store and
forward anyway.

So basically I haven't been persuaded that the changed default and a
thoughtful design of role names cannot do a realistic scenario.

Best regards,

                   Jacek Kopecky

                   Senior Architect, Systinet Corporation
                   http://www.systinet.com/



On Wed, 2002-10-16 at 22:45, Henrik Frystyk Nielsen wrote:
> 
> Ok, here is a scenario that uses a request/response message exchange
> pattern as follows: The request follows a message path that looks like
> this:
> 
>      A    --->    B   --->    C
> 
> and the response path look like this:
> 
>      A    <---    B   <---    C
> 
> Node A wants to deploy a new feature that allows it to introduce a
> hop-by-hop deflate compression of the SOAP message in a manner similar
> to HTTP transfer-encoding. Another similar feature could be a request
> for a "store and forward" mode by the next hop that would support the
> bad connectivity of my mobile device. 
> 
> As the semantics in both cases is hop-by-hop, A can use the "next" role.
> However, as the feature is not commonly understood, making it mandatory
> is likely to generate a mU Fault by B. In order not to punish smart
> applications, it would be nice to allow A to use a mU=false, so that it
> wouldn't cost a SOAP fault and additional RTTs to see whether B
> understands the new feature(s).
> 
> However, we also want to avoid a situation where the feature reaches C
> and C understands it and starts using it on the B<-->C link. This would
> confuse B in case B didn't understand it. As a result, even though it
> was A who started the request for the new feature, the impact would be
> on the B<-->C link where it would break interoperability.
> 
> The benefits of the current model is that it supports this scenario AND
> at the same time, I can support a scenario with a feature that indeed IS
> intended to flow through an intermediary using the "relay" role.
> 
> Simply flipping the default would mean that we would loose support for
> these scenarios UNLESS we also changed the "next" role to explicitly
> take out all header blocks regardless of whether they were processed or
> ignored. That, IMO, would be a bigger change as we not only flip the
> default but apply it unevenly to existing roles.
> 
> Hope this makes sense,
> 
> Henrik Frystyk Nielsen
> mailto:henrikn@microsoft.com
>

Received on Wednesday, 16 October 2002 17:08:41 UTC