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!