Hi kristoffer,
So, instead I'll just point towards what is actually in the
ROHC-TCP draft right now.
In general, I don't think that the fact that some text already exists is a motivation to move on with a specific solution. As you've mainly work with the packet formats (which provide one interpretation of the Washington agreement) and I mainly worked on the text in FN than it is of no surprise that these contradicts. At least we agree on this. On the other end, I don't think that reviews of the packet formats focused on that part at all so I would not understand this as representing any agreement.
For that reason, as well as the lack of _clear_
documentation for what we had consensus on, it
is not only valid, but important to re-open the
discussion.
I am certainly in favor of discussing this and clarifying this.
That's why I have proposed a simple definition that I hope was clear enough.
clearly, the fields that _I_ refer to as
control_fields need to be treated differently
than "simple flags" in the PROFILE.
I don't know that we have consensus on this "clearly".
I actually agree that in the implementation, they will be treated differently, but I firmly believe that it is not of the FN to define such difference. The FN specifies packet formats formally, e.g. how to compress each field based on coding methods and assertive statements to generate the butts on the wire, but I believe it is of the scope of the profile definition to define where and how the context information required to choose and generate the actual packets.
So, I'd rather say that for the FN to fullfil its goals there is no need to handle the two types that you defined in a different ways. In terms of properties, controls fields (including what you call simple flags) are no different than uncompressed fields, also as uncompressed fields can be used themselves as simple flags and as control fields may be compressed themselves and be sent in the compressed header.
As a sideline, and this is maybe why Lars-Erik and myself couldnot agree regarding the "overloading" of the "let" statement in a previous discussion, it clarifies I believe that a let cannot be used to define a field, but can be used to bind the value of a field attribute or can be used as a simple assertive statement.
this separation. If the FN provides this separation, it still
does NOT mean that it messes with "context updating" or other
concepts, it is just a separation of fields to provide
readability and consistency.
I don't really get you here. I am not talking about context updating, I am talking about properties related to their persistency in the context, what you previously referred to as "fields" with requirements on the context.
Further, I think that this messes up much more than it helps, because the requirements that a field as with respect to the context is in large part related to coding methods and/or the presence of information onto which it depends within the uncompressed header. That is, you'd introduce rules as to that a field used as a flag cannot be the left-hand side of an assignment that has state, such as a binding to a stateful coding method or a binding to an expression that requires state to be kept.
I believe that the definition that I have provided is much cleaner (and clearer for that matter) as all fields not part of the uncompressed header are treated the same manner, only that those that you'd like to use as flags would have some attributes being undefined (which is ok by FN) as long as you don't use these attributes in expression (would lead to an undefined result, which is not allowed).
I'd welcome also more input in this discussion as I feel that, with the distinction that has been proposed, we are stepping over the scope of the FN into the scope of the profiles. And that I want to avoid.
/Ghyslain
-----Original Message-----
From: Kristofer Sandlund [mailto:kristofer.sandlund at effnet.com]
Sent: den 20 april 2005 11:30
To: Ghyslain Pelletier (LU/EAB)
Cc: Finking, Robert; Carsten Bormann; rohc at ietf.org
Subject: Re: [rohc] FN: default_methods and control fields
clarification/new usage
Hi Ghyslain,
predictably, I'm not in agreement with you. Resoning follows:
First of all, I have a very different opinion on what the
consensus in
Washington was. I just read the slides and the minutes from
the meeting, but
from that I cannot read it one way or the other.
So, instead I'll just point towards what is actually in the
ROHC-TCP draft
right now. The nottion that control_fields were meant to
include "all fields not
in the uncompressed header" is not supported by section 6.3
(tcp-09), which
lists the actual control fields that "have context", which is
tha same
separartionas in the packet formats in the draft. I know that
the FN text
contradicts this, but it seems like we simply did not know
what we had consensus
on. For that reason, as well as the lack of _clear_
documentation for what we
had consensus on, it is not only valid, but important to
re-open the discussion.
Like I said to you offline yesterday, to me it is important
that the TCP spec
becomes as readable as possible to the implementer and that
the text and packet
format definitions are consistent with each other. And
clearly, the fields that
_I_ refer to as control_fields need to be treated differently
than "simple
flags" in the PROFILE. And the packet formats included in the
rohc-tcp draft
_are_ a part of the profile, and therefore should separate
the same way as the
text. Therefore, the FN needs to provide provisions for "FN
code" to provide
this separation. If the FN provides this separation, it still
does NOT mean that
it messes with "context updating" or other concepts, it is
just a separation of
fields to provide readability and consistency.
So, I guess we need input on this from more people to be able
to resolve things,
so please jump in even if you're not in agreement with me :)
BR,
Kristofer Sandlund, Effnet AB
Ghyslain Pelletier (LU/EAB) wrote:
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