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

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

>-----Original Message-----
>From: noah_mendelsohn@us.ibm.com [mailto:noah_mendelsohn@us.ibm.com] 
>Sent: Wednesday, October 16, 2002 12:58
>To: Martin Gudgin
>Cc: Henrik Frystyk Nielsen; Jacek Kopecky; XMLP Dist App
>Subject: RE: Proposal for new last call issue: Some 
>unprocessed headers should stay
>
>
>I agree with the table, but with the caveat that as always a processed 
>header can change the rules.  Thus, I might have a header that is 
>processed, that uses data in another header addressed to 
>"none", and the 
>semantics of the processed header might call for removal or 
>change to the 
>contents of the "none" header.  So, from that point of view. the real 
>answer is that many of the entries are "maybe", but I think 
>the spirit of 
>your table is right.
>
>I still am unconvinced by Henrik's use case for putting in a 
>header that 
>must be dropped by the next node (or next node with the chosen 
>role) if 
>not processed.  Furthermore, I believe that if necessary that could be 
>implemented by an mU header addressed to the same role that 
>means "you may 
>not have to understand the other headers addressed to this 
>role, but you 
>do have to understand this one:  it tells you to drop the 
>other headers if 
>you don't process."
>
>So, I still have some inclination to support those who would like to 
>change the default.  It's always seemed too tricky to me to 
>have to rely 
>on dropping then reinserting in the case that you do process.  In any 
>case, I think the spirit of the table below is correct:  it 
>just doesn't 
>convince me that changing the default is a mistake.
>
>------------------------------------------------------------------
>Noah Mendelsohn                              Voice: 1-617-693-4036
>IBM Corporation                                Fax: 1-617-693-8676
>One Rogers Street
>Cambridge, MA 02142
>------------------------------------------------------------------
>
>
>
>
>
>
>
>"Martin Gudgin" <mgudgin@microsoft.com>
>10/16/2002 03:23 PM
>
> 
>        To:     "Jacek Kopecky" <jacek@systinet.com>, "Henrik 
>Frystyk Nielsen" 
><henrikn@microsoft.com>
>        cc:     "Noah Mendelsohn" 
><noah_mendelsohn@us.ibm.com>, "XMLP Dist App" 
><xml-dist-app@w3.org>
>        Subject:        RE: Proposal for new last call issue:  
>Some  unprocessed   headers  should 
>stay
>
>
>Jacek,
>
>Henrik and I were talking about this yesterday. Here is the 
>matrix we came up with:
>
>|------------------|---------------------------|
>| Role             | Header will be forwarded? |
>|------------------|---------------------------|
>| relay            | Y |       Maybe           |
>|                  |---|-----------------------|
>|                  | N |       Yes             |
>|------------------|---|-----------------------|
>| next             | Y |       Maybe           |
>|                  |---|-----------------------|
>|                  | N |       No              |
>|------------------|---|-----------------------|
>| ultimateReceiver | Y |       Not applicable  |
>|                  |---|-----------------------|
>|                  | N |       Not applicable  |
>|------------------|---|-----------------------|
>| none             | Y |       Yes             |
>|                  |---|-----------------------|
>|                  | N |       Yes             |
>|------------------|---|-----------------------|
>
>
>The Y/N column indicates whether the SOAP node understands the 
>header block ( note this is independent of the value of 
>soap:mustUnderstand ).
>
>
>A 'Yes' indicates that the header will always be forwarded.
>A 'No' indicates that the header will never be forwarded.
>A 'Not applicable' means the forwarding never occurs.
>A 'Maybe' indicates that whether the header block is forwarded 
>or not depends on the spec for the header. I realise that this 
>is not *really* a 'forward' but rather a 're-insert'
>
>Does this help at all?
>
>Gudge
>
>> -----Original Message-----
>> From: Jacek Kopecky [mailto:jacek@systinet.com]
>> Sent: 16 October 2002 11:32
>> To: Henrik Frystyk Nielsen
>> Cc: Noah Mendelsohn; XMLP Dist App
>> Subject: RE: Proposal for new last call issue: Some 
>> unprocessed headers should stay
>> 
>> 
>> 
>> Henrik,
>> 
>> I don't (yet?) see how changing the default is going to
>> affect negatively any application (a few role name redesigns 
>> may be necessary, but I believe that's not many).
>> 
>> With the changed default, if a module doesn't specify
>> anything about relaying, none is done on processed headers, 
>> unprocessed headers would be passed along believing that 
>> other node acting the same role would do better.
>> 
>> On the other hand a module can include relaying in its
>> specification and it would work. My preference to push the 
>> relaying specification into modules is based on my opinion 
>> that relaying is tied to a header's semantics and therefore 
>> it is not an undue burden on the module's designer.
>> 
>> Best regards,
>> 
>>                    Jacek Kopecky
>> 
>>                    Senior Architect, Systinet Corporation
>>                    http://www.systinet.com/
>> 
>> 
>> 
>> 
>> On Wed, 2002-10-16 at 19:54, Henrik Frystyk Nielsen wrote:
>> > 
>> > >In this situation, I would prefer changing the default to keep 
>> > >unprocessed header entries, and deferring the relaying 
>into modules 
>> > >where I think it really belongs; but I see how this might be 
>> > >perceived as a big change.
>> > 
>> > I think there are scenarios that call for both ignored
>> header blocks
>> > to be removed and for them to be forwarded. An example of
>> the former
>> > is some hop-by-hop oriented feature, and an example of the
>> latter is
>> > some feature that isn't hop-by-hop specific.
>> > 
>> > IMO, it is not really a question of whether changing the
>> default is a
>> > big change or not but rather that it doesn't address both
>> cases. For
>> > example, having ignored header blocks be preserved would
>> not allow me
>> > to deploy an optional hop-by-hop compression algorithm.
>> > 
>> > A nice thing about the "relay" role proposal is that I get both
>> > capabilities. This means that I can deploy an optional hop-by-hop 
>> > "compression" header block which is removed if ignored AND 
>> a "trace"
>> > header block which is not removed if ignored.
>> > 
>> > Henrik
>> 
>> 
>> 
>
>
>
>

Received on Wednesday, 16 October 2002 16:46:25 UTC