Re: Proposed resolution of issue 101: relationship between headerand body blocks

[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:23:48 UTC