RE: [rohc] FN: default_methods and control fields clarification/n ew usage

["Finking, Robert" <robert.finking at roke.co.uk>]

Hi L-E, All,

I've just had a phone call with Kris to clarify a few things from a TCP profile point of view, but OK yes I basically agree to your suggestion. Comments in-line below to include the clarifications from the phone call - Kris please feel free to add anything I've forgotten (which I must have done).

Regards

Raffles

> -----Original Message-----
> From: Lars-Erik Jonsson (LU/EAB)
>
> To me it looks really useful to make this distinction. Fields that 
> are "created" and used only on a per-packet basis do not require an
> explicit control-field declaration, but would be declared as part of
> the compressed header, with a let declaration that creates the
> mapping between the created field and original uncompressed field(s).
> 
> However, control fields are different because they are not
> necessarily created directly out of uncompressed fields, at least not
> on a per-packet basis, and they do require context. This is why we
> agreed they should be explicitly declared as "control fields".
> 
> I see three kind of fields, original fields, per-packet 
> created fields,
> and context-requiring created fields (control-fields).
>

Yes OK, I've been convinced that we can stick with just these three.
We already have syntax for "original" fields: "uc_format". We also
have syntax for "context-requiring" fields: "control_fields". We don't
have syntax for "created" fields. These are very important and need
defining explicitly in the FN draft, because they are like no other
kind of field: they can be compressed using "static", "lsb" etc. but
*without* using context of their own - they use the context of the
field(s) which they are derived from. I suggest that we call these
"derived_fields". This then is the only new syntactical element which
we need.

"default_methods" can then be used exclusively for storing defaults,
as described in the current FN draft.


 
>  
> > * It strikes me that there are quite a few different types of field,
> > (e.g. "inferred" fields), which we are currently not being explicit
> > about, either in the FN or in the TCP draft. The notation 
> > (and hence the TCP draft) would be easier to read if we were
> > explicit about these things. At present we are disguising them as
> > other things, which is confusing (to me at least). To bring this
> > discussion full circle one such example is a non-default statement
> > appearing in a default list.
> 
> I see what you mean, but this also worries me, as I think we would
> open up the classic can of worms if we start doing these things. We
> are *very* close to finalizing the FN, and I do not want to run
> another round of redefining things that we have actually agreed are
> ok. Just sort out the control-fields and default-methods stuff, and
> then let's try to close this document once and for all.

Yes, I agree, my boss was asking me only this morning about how much
more effort this was going to take to get finished!

Hopefully we can all agree on the above solution? This is a good step
forward for both the TCP profile and also the FN I think. Thanks!

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