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

Jean-Jacques, others,

there are two different views of the world competing here. The views
concern in particular how a sender node views the message path in terms
of nodes and roles:

1) (status quo) the message path contains some nodes and some roles, and
the mapping from a role to a node is unambiguous. In other words, a role
name identifies at most one node (from the POV of the sender) and the
contract is between the sender and that node.

2) (after proposed default flip) the message path contains some roles,
the contract is between the sender and the role (anyone playing the
role).

I think Henrik assumes the first view but wants to make an exception for
a specific scenario.

I think the specific scenario is very close to the second view so I
thought that view was being adopted here.

Best regards,

                   Jacek Kopecky

                   Senior Architect, Systinet Corporation
                   http://www.systinet.com/




On Thu, 2002-10-17 at 14:05, Jean-Jacques Moreau wrote:
> Ah, ok, I think this is the crux of the issue.
> 
> A long time ago, Noah insisted that targetting a header block to 
> a node was essentially drawing a contract between the sender and 
> the receiver, and NOT with any other node (at least that's what I 
> think he said). Hence the default for removing the header block 
> before forwarding; the block was not any other node's business.
> 
> I think we are now discovering the contract is in fact sender 
> imposed; the receiver had no say in its redaction and it can only 
> rebel as far as ignoring unwanted headers (except in the 
> dictatorial mU="true" case).
> 
> In fact, the receiver may be genuinely trying to fulfill his part 
> of the contract, but it may not have the software to process some 
> of the header blocks. If it does not understand the header block, 
> how could it know if the header requires forwarding or not?
> 
> Henrik is right: it is not (always) possible to determine whether 
> a header block needs forwarding based solely on the header 
> itself. There has to be some other information, whether in the 
> message or out-of-band.
> 
> Jean-Jacques.
> 
> Henrik Frystyk Nielsen wrote:
> > I think the place where we run into problems is where we have an
> > ignored/unprocessed header block rather than an understood/processed
> > header block. This makes it hard to associate header block processing
> > with the forwarding behavior if forwarding is not desired.
>

Received on Thursday, 17 October 2002 08:32:52 UTC