RE: [rohc] FN: default_methods and control fields clarification/newusage

["Lars-Erik Jonsson \(LU/EAB\)" <lars-erik.jonsson at ericsson.com>]

I actually have a hard time understanding why you even care
to argue so much about this issue. Personally, I can note that
the current FN is not consistent in defining and describing
what a control field is, but either solution presented looks
good to me.

In general, I agree with Kristofer who wants to make the FN
easier to read and understand by separating different
mechanisms, also and especially when they could be realized
with one single mechanism. However, I still believe the issue
about "let" to be more important to fight about, but that one
I have given up. Therefore I do not care so much about this
separation, which I agree looks logical in my mind, but not
essential.

Looking at the argumentation from Ghyslain, I can also buy
that one. Adopting his definition of control_field would
probably be the simplest way to move on with FN. But I can
not see why going with the proposal by Kristofer and Raffles
would be bad, wrong, or counterproductive.

So, honestly, I can not take side in this discussion, not at
this point, then someone has to bring more convincing
arguments.

Finally, a comment on the following:

> 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.

I do not agree that this was the cause of the problem we
could not agree on "let". As you say yourself, let can be used
to bind the value of a field attribute, or it can be used as
a simple assertive statement. Every time I see a let, I have
to figure out which usage it is, and I still believe having
these two separated had been the right thing(tm). A toolbox
becomes easier to use and understand if you have different
tools for different things, where each have a name that 
represents what it is good/used for.

Actually, in the FN example on page 51, the following let
statement is not correctly written, I think. 

       let(scaled_seq_no:uncomp_value
             == ((mod(15 - sequence_no:uncomp_value, 3) * 16
                  + sequence_no:uncomp_value) / 3));
 
Is == the proper syntax here? Then this would be a simple
assertion that would just always be false. Or have I missed
something? The overloading of let makes it an ambiguous 
mechanism. Yes, I have agreed not to argue about that again,
but since you brought it up, I thought I had the right to
respond.

/L-E

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