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

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:04:49 UTC