- From: Jacek Kopecky <jacek@systinet.com>
- Date: Thu, 22 Nov 2001 17:34:37 +0100 (CET)
- To: Jean-Jacques Moreau <moreau@crf.canon.fr>
Jean-Jacques, IIRC the question of whether a processor could just decide to process headers that are not explicitly targetted at it has already been discussed. I don't know where the discussions ended, but it was always my feeling that (in absence of an extension saying otherwise) a node must not process headers that are not targetted at it. Best regards, Jacek Kopecky Senior Architect, Systinet (formerly Idoox) http://www.systinet.com/ On Thu, 22 Nov 2001, Jean-Jacques Moreau wrote: > [Responding to your second point.] > > I think this is an issue, and that we should either disallow the > combination mU+none, or explicitely state in the processing model > that we only consider blocks _explicitely_ targetted at the current > node. > > Jean-Jacques. > > Jacek Kopecky wrote: > > > [...] As for mU on a header targeted to .../none, you are right, it > > is > > ignored. At least I understand it as though it must be ignored > > (unless some extension says otherwise but then extensions can do > > just about anything anyway). > > About failing on referencing into an not understood mU header: > > this is a matter of layering. As it is now, the Encoding layer > > comes in _after_ the processing model so all mU failures will be > > resolved before the encoding rules are applied to the data. > > Therefore no mU fault can be generated as a result of some block > > referencing a not understood header because when we talk > > "referencing", we don't care about "understanding" any more. > > Just my understanding, I may be mistaken, of course. 8-) > > > > Jacek Kopecky > > > > Senior Architect, Systinet (formerly Idoox) > > http://www.systinet.com/ > > > > On Wed, 14 Nov 2001, Jean-Jacques Moreau wrote: > > > > > I am feeling somewhat incomfortable with point b), > > > especially if the next step is to disallow multiple body > > > blocks. Unless there is strong evidence that this is a > > > necessary restriction, I would suggest that we remove b) > > > from the proposal. > > > > > > On a related note, I am have been wondering recently about > > > the processing model and mU blocks. Am I correct in > > > thinking that, today, we allow body blocks to reference > > > hearder blocks, and vice-versa? Does it make sense for an > > > mU header block to be targetted at none? Does it make sense > > > for a body block to reference an mU header block? Is an > > > intermediary supposed to abort processing if it finds a > > > non-mU header block that references an mU header block it > > > does not understand (i.e. is section 2.5 meant to be > > > recursive?)? > > > > > > Jean-Jacques. > > > > > > >
Received on Thursday, 22 November 2001 11:34:53 UTC