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

I think this argues for treating role identification and header 
removal/propagation as orthogonal matters.

#g
--

At 01:45 PM 10/16/02 -0700, 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
>
> >-----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
> >>
> >>
> >>
> >
> >
> >
> >

-------------------
Graham Klyne
<GK@NineByNine.org>

Received on Thursday, 17 October 2002 05:13:02 UTC