[rohc] Formal notation - Variables (was: Updating the Formal Notation draft)

["Lars-Erik Jonsson (EAB)" <Lars-Erik.Jonsson@epl.ericsson.se>]

Hi,

This was a good summary, and I think we will have to look at
each case and see how it can be best expressed. References
could be expressed as references. Control fields could be
defined as control fields, and then handles exactly as all
uncompressed fields. Regarding the other values, these 
are details that we should discuss further what they really
are, and come up with ways to handle. I think it is worth
a lot not to group all these together but consider each of
them separately, that should make the notation both clearer
and more correct.

BR
/L-E


> -----Original Message-----
> From: Price, Richard [mailto:richard.price@roke.co.uk]
> Sent: den 6 mars 2003 11:07
> To: Lars-Erik Jonsson (EAB); rohc@ietf.org
> Subject: RE: [rohc] Updating the Formal Notation draft
> 
> 
> > I'm still not sure "Variable" is the right word for this at
> > the notation level, and as you say we should investigate if
> > we can avoid having this at all. The examples you have shown
> > seem to be about compressing fields together, i.e. using
> > another field as a reference for compressing a field. Would
> > "Reference" be a potential word if we have to keep this?
> 
> Hi,
> 
> Referencing fields is certainly the main use of "temporary
> variables", but there are some others that might be worth
> taking into account.
> 
> In general, we use the variables to store any miscellaneous
> information that an encoding method needs to compress a field,
> but which isn't available in the uncompressed packet or in
> the context.  I've had a go at listing all of the places where
> temporary variables come in handy below:
> 
> 1.  Using another field as a reference to compress a field
> 
> This is the example mentioned above.  Currently we store the
> actual value of the field in a temporary variable, but it
> would be ok to instead store a pointer to where the field can
> be found in the uncompressed packet.  So the term "reference"
> would be fine in this case.
> 
> 2.  Using a "control" field to compress a field
> 
> In some cases the field that we want to use might be a
> control field, i.e. one created by the compressor and not
> found in the uncompressed packet.  An example for TCP/IP
> compression would be the "Master Sequence Number".  I'm not
> sure how we could do this as a reference, since the control
> fields aren't stored anywhere in the uncompressed packet.
> 
> 3.  Other values that might be needed for compression.
> 
> We also use temporary variables to store other values, which
> can't really be considered to be "fields" at all (since they're
> not part of the compressed or uncompressed packets).  Here are
> some examples:
> 
>    a.  Remaining_Data : The number of bits remaining in the
>        uncompressed packet.
> 
>    b.  Index : A pointer to the current context entry.
> 
>    c.  No_Update : Set to 1 if the encoding method is not
>        supposed to update the context.
> 
> I'm not sure that "references" captures all of the above, but
> there are probably better terms than "variables" which we could
> use.  Comments welcome!
> 
> Regards,
> 
> Richard
> 
_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc