W3C home > Mailing lists > Public > xml-dist-app@w3.org > October 2002

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

From: Martin Gudgin <mgudgin@microsoft.com>
Date: Wed, 16 Oct 2002 12:23:13 -0700
Message-ID: <92456F6B84D1324C943905BEEAE0278E02F44323@RED-MSG-10.redmond.corp.microsoft.com>
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>

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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:11 GMT