[no subject]

The way I visualise encoding methods is just as "subroutines" that can
be called in the ROHC-FN language. Each subroutine is designed to
compress some or all of the bits in the header, and, naturally, the
more complex subroutines are defined in terms of simpler ones. Thus, a
typical set of packet formats is created using layers of progressively
more complex encoding methods, e.g:

Whole header:             Ordinary Huffman
                                / \
Part of header:                /  List
                              /    /\
Individual fields:       IP-ID  NBO  Irregular
                          / \
Partial fields:     Offset   LSB

In this layered approach it's difficult to find a single property
that defines whether an encoding is a field encoding, a discriminator
encoding or something else entirely. It's not the case that only the
discriminator encodings offer implementation-specific choices, because
a number of field encodings offer them as well (e.g. NBO). Similarly,
it's not the case that discriminator encodings need to be applied to
the whole header, because the discriminator encodings such as list
are applied to part of the header only. Unless of course we make list
encoding into a special case (which would be peculiar, because it
generates discriminator bits no differently from, say, OH or HH).

Any other suggestions for what is actually meant when we talk about
"discriminator encodings"?

> Further, I strongly believe that there is a difference in how you
> choose discriminator encoding, compared to how you pick field encoding
> methods. The latter is (almost) purely based on field behavior, while
> the former choice is not as obvious, it is a more subjective profile
> designer choice.

I don't believe that this is the case. For example, in the proposed
TCP packet formats we're already making a subjective choice to simplify
the field encodings, by using LSB encoding instead of the more powerful
but more complicated LSP encoding. Similarly, our choice of which
version of list encoding to use, whether to allow NBO encoding and so
on are all subjective decisions that must be made independently of the
decision on whether to use OH, HH etc.

> > > > We originally used the term "EPIC-lite" to mean
> > > > the entire notation-based solution, including
> > > > the notation itself and the complete library of
> > > > encoding methods.  The algorithm for generating
> > > > the discriminator bits is actually nothing more than
> > > > ordinary Huffman encoding, so perhaps we could
> > > > just call it that instead?
> > > 
> > > Ok, "Ordinary Huffman" (OH), and "Hierarchical Huffman" (HH) then?
> > 
> > Sounds ok to me!
> 
> Fine, let's try to use those then.
> 
> /L-E
> _______________________________________________
> Rohc mailing list
> Rohc@ietf.org
> https://www1.ietf.org/mailman/listinfo/rohc
> 
_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc