RE: [rohc] Role and approach of the ROHC formal notation

["Price, Richard" <richard.price@roke.co.uk>]

Hi,

A minor point - I think that this conflicts with the definition of a
"rule" as used in Prolog.  Our "encoding methods" are a subset of
"Prolog rules" - every encoding method can be represented as a Prolog
rule, but there are plenty of Prolog rules that don't define encoding
methods.

Regards,

Richard

> -----Original Message-----
> From: Carsten Bormann [mailto:cabo@tzi.org]
> Sent: Thursday, March 06, 2003 2:37 PM
> To: Price, Richard
> Cc: 'Lars-Erik Jonsson (EAB)'; rohc@ietf.org
> Subject: RE: [rohc] Role and approach of the ROHC formal notation
> 
> 
> I liked "rule".  Short, sweet, but does not mean to much (i.e., does not
> get in the way of understanding).  (For the same reason, I prefer "label" or
> maybe "binding" over "variable".)  It is completely OK to define a *small*
> number of "new" terms for *core* concepts of the FN.
> 
> Some typical mistakes when choosing terminology:
> 1) trying to be super-precise and inventing a whole new alphabet soup of
> abbreviations which you *have* to memorize before you can understand
> anything (unfair example: MPLS).
> 2) adopting terms from a different domain and using them in an
> ever-so-slightly different sense so casual readers knowing the original
> domain are misled to no end (unfair example: SIP).
> 
> Applied to the question how to call the component statements of the FN:
> Example for error number one: FDER.
> Example for error number two: production.
> 
> Gruesse, Carsten
> 
> On Thu, 6 Mar 2003, Price, Richard wrote:
> 
> > In this case we may need to pick a more general term to avoid
> > confusion with 3095.  What we're looking for is a term to describe
> > a general "compression function", which converts uncompressed
> > data into compressed data (relative to a context).  It shouldn't
> > matter whether the function compresses a single field, a whole
> > protocol header, or even the entire packet.  Also, it shouldn't
> > matter whether the function outputs compressed bits that are
> > considered to lie in the "discriminator" or in the "compressed
> > body" part of the header.
> >
> > In particular, the term must be equally suitable for describing
> > all of the following:
> >
> > * LSB encoding
> > * Self-describing variable-length values
> > * List encoding
> > * EPIC-lite
> >
> > Any ideas for a good term to use?  Once we have one, I suspect
> > that the scope of the formal notation will be *much* easier to
> > define.
> 
_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc