Hi all,
Sorry or the slow turnaround time to answer on this matter.
Unfortunately, I do not agree.
I _thought_ that we agreed in Washington that control fields have the exact same properties as uncompressed fields (that is, they can have attributes, can be compressed, and must be defined within a scope) but that they would be used to defined any field that is not part of the uncompressed header.
For me, persistency in the context is not something that is related to the formal notation. This is something that is up to the profile to state when defining what controls fields are used and what they are for. Pushing this further, I think that it is just as innapropriate to define a requirement related to context and persistency in the context for control fields as it would be to do this for other fields.
The problem that I see is that a declaration using "let" does not have anything to do about if the field would have a "lifetime" longer than compressing one single packet or a longer lifetime. For example, would let create a binding from a control field to a mathematical expression then the lifetime of the control field is per-packet, would the binding be using a coding method that requires the maintenance of a value in the context than suddenly it would become a "context-requiring" field.
I see three kind of fields, original fields, per-packet
created fields,
and context-requiring created fields (control-fields).
I cannot see that this distinction is useful for formally notating and parsing of packet formats, which is the objective of the FN. Context requirements is outside the scope of the FN and we have strived as much as possible so far to avoid making such distinction in the notation. Someone explains me why this is suddenly needed for the FN.
In short, I do not agree with the latest proposal.
I propose that control fields be defined as follow:
There are three types of fields: uncompressed fields, control fields and compressed fields. Control fields share the exact same properties as uncompressed fields in that they can have attributes, they can be compressed, and must be defined within their useful scope. The difference from uncompressed fields is that they are not part of the uncompressed header but rather created to help in the compression of uncompressed fields, and may be sent as part of the compressed header in packet formats. Just like other fields, profile may have to specify in some way how their value is maintain in the compressor and decompressor context (this is based on the usage of the control field - e.g. if it's definition and usage depends only of uncompressed values that are always present in the uncompressed header, or if the field can sometimes be compressed and sent along in the compressed header).
I.e. this also means that the :uncomp attribute of control fields _may_ be undefined, as long as this attribute is not used explicitly within the definition of packet formats (the use of undefined value is undefined) and as long as the control field is not compressed.
Since I cannot really grasp exactly why this discussion led to this proposal, I might be somewhat off the problem, but I feel that the above summarizes the consensus that we had in Washington and I see no need to revisit that consensus without making a change that is not right.
Best regards,
/Ghyslain
-----Original Message-----
From: rohc-bounces at ietf.org [mailto:rohc-bounces at ietf.org]On Behalf Of
Finking, Robert
Sent: den 19 april 2005 15:09
To: 'Carsten Bormann'
Cc: rohc at ietf.org
Subject: RE: [rohc] FN: default_methods and control fields
clarification/new usage
Great, is that consensus? Carsten? Eilert?
Cheers
Raffles
-----Original Message-----
From: Lars-Erik Jonsson (LU/EAB)
[mailto:lars-erik.jonsson at ericsson.com]
Sent: Tuesday, April 19, 2005 2:02 PM
To: Kristofer Sandlund; Finking, Robert
Cc: rohc at ietf.org
Subject: RE: [rohc] FN: default_methods and control fields
clarification/n ew usage
Excellent that you managed to come up with a resolution. To
me this sounds fine!
/L-E
-----Original Message-----
From: Kristofer Sandlund [mailto:kristofer.sandlund at effnet.com]
Sent: den 19 april 2005 13:41
To: Finking, Robert
Cc: Lars-Erik Jonsson (LU/EAB); rohc at ietf.org
Subject: Re: [rohc] FN: default_methods and control fields
clarification/n ew usage
Robert,
I think you covered what we discussed, but maybe we should
also say that a
reason for having the derived_fields definition is so that we
_can_ declare
these in a global scope to help with the accesses between
structures. We don't
believe that this will be used for the TCP profile, but we
don't want to rule it
out of the FN.
BR,
Kristofer
Finking, Robert wrote:
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
_______________________________________________
Rohc mailing list
Rohc at ietf.org
https://www1.ietf.org/mailman/listinfo/rohc