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 15:23:45 UTC