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:00:28 UTC