Subject: RE: [rohc] Comments on ROHC-FN -05 (draft-ietf-rohc-formal-notation-05.txt)

From: "Lars-Erik Jonsson \(LU/EAB\)" <[email-masked]>
Date: Tue, 1 Mar 2005 09:22:04 +0100

One clarification to my own comment...
 
> > > > > - Last sentence in 3.2.1 says "Otherwise, the binding will 
> > > > >   fail and an alternative encoding method must be used".
> > > > >   However, the text is in the decompressor text, but should
> > > > >   instead be part of the compressor text. The consequence
> > > > >   of an unsuccessful binding at the decompressor is rather
> > > > >   that the packet will have to be discarded, and the context
> > > > >   probably invalidated (but that is part of the profile
> > > > >   logic to specify).
> > > > 
> > > > This is not correct is it? If you have 5 different packet 
> > > > formats and the first one you try to decompress your packet
> > > > with has static encoding for a particular field, and that
> > > > fails, then you just try one of the other four packet formats
> > > > don't you? 
> > > 
> > > As a decompressor, you never have a choice, you get ONE single
> > > format and has to decompress it. If it fails, you are screwed.
> > > The compressor on the other hand, of course has to pick a proper
> > > format, as you describe above.
> > 
> > OK, lets take a step back. How do you know what that single 
> > format is? You have to have a mechanism for selecting that single
> > format. 
> 
> Yes, the compressor selects format, the decompressor interprets it.
> It is the same condition that tells the compressor "this is the
> format you have available since the context disables the alternative",
> as tells the decompressor, "the header you just got is this one - 
> based on discriminator+context".
> 
> > Normally you'd use a discriminator. The way you then select the
> > right format is that when the decompressor tries each of the
> > alternatives it finds that the compressed_value encoding for
> > the discriminator field fails for all but that one correct
> > format. 
> 
> Yes, that is the same thing expressed in other words. 
> 
> > However, in theory you don't have to use a discriminator, you
> > could use any mechanism at all that allows the correct packet
> > format to be selected i.e. any mechanism that causes incorrect
> > formats to be rejected - there is no theoretical reason why 
> > this shouldn't be the presence or absence of context data
> > needed by lsb and static encoding methods. Of course to be of
> > practical use, it would be necessary for the compressor to
> > know exactly what context information was available at the
> > decompressor.
> 
> True, much theory here. Are we seriously aiming at implicitly
> indicating different packet formats, i.e. have different
> packet formats being indicated by anything but discriminator?
> I do not think so, and if that is the case, I strongly object...=)

Here I meant "within the header being sent", then of course we
have the use of context information that can enable/disable
different formats (as written above), i.e. the same discriminator
could be used for more than one format, but only one would ever
be active at each point in time. For e.g. IP-ID, a context
parameter would tell whether the active format sends IP-ID in
full or compressed.

If this is to be captured with the notation, I would prefer to
see that "assertion" being written as a pre-condition to the
format, not hidden within the format, and not combined with the
let statement (which I like the intuitive use of, as in B.7).

/L-E

_______________________________________________
Rohc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc