Re: [rohc] Formal notation, combined thread

["Richard Price" <ellyptic@hotmail.com>]

> > Both approaches have their advantages - the EPIC-
> > lite approach is always more efficient, but the self-
> > describing values approach is simpler and less
> > memory-intensive.  From the notation perspective
> > we should therefore make sure that both approaches
> > are supported, and leave it up to profile writers to
> > select the correct approach for a given situation.
> 
> I envision it like this:
> 
> Given a set of rules like:
> 
> a --> b | c.
> b --> d | e.
> c --> f | g.
> and so on,
> 
> you would wrap this whole thing into something like:
> 
> z --> epic(a).
> 
> Now this would collect the information in the notation tree opened by 
> the above rules and prefix the values generated by a to g with an EPIC 
> discriminator.  I.e., a discriminator value is a value still to be 
> compressed, and you have to use a meta-encoding method (an encoding 
> method that is supplied an encoding method as a parameter) to convert 
> it into actual compressed values.  It would be an error to have 
> discriminator values left at the root encoding method.
> 
> If you want to use a different discriminator encoding method, just say
> 
> z --> huffman(a).
> or
> z --> arith(a).
> 
> Does that work?

I certainly hope so!  This is exactly how I'm
hoping to invoke the discriminator encoding
methods.  I can't foresee any problems in doing
this - it's similar to the mechanism that we
already use to invoke list encoding, which
seems to work ok.

Regards,

Richard
_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc