- 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