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

From: "Ghyslain Pelletier \(LU/EAB\)" <[email-masked]>
Date: Wed, 20 Apr 2005 12:15:10 +0200

...at one point in my previous posting it should've read "bits"... oups.

: )

/Ghyslain

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Ghyslain Pelletier (LU/EAB)
> Sent: den 20 april 2005 12:00
> To: Kristofer Sandlund; Carsten Bormann
> Cc: Finking, Robert; [email-masked]
> Subject: RE: [rohc] FN: default_methods and control fields
> clarification/newusage
> 
> 

_______________________________________________
Rohc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc

---

From: "Lars-Erik Jonsson \(LU/EAB\)" <[email-masked]>
Date: Wed, 20 Apr 2005 15:22:21 +0200

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

---

From: "Ghyslain Pelletier \(LU/EAB\)" <[email-masked]>
Date: Wed, 20 Apr 2005 15:27:56 +0200

> but since you brought it up, I thought I had the right to

Yes, because we looked at the statement above together and wondered what it actually really meant in light of the "==". However, in the FN draft, it is not said anywhere explicitly how attributes should be used as a left-hand side of an expression, which I believe should be using the "=".

However, I did not want to re-open the question on the let statement - I just what us to _clarify_ the FN properly in its current state (not change or split syntax that allows us to reach our objectives with the notation), then conciliate the packet formats and the FN text and move on with the ******* thing so that we can do proper (and wider) review of the TCP profile and packet formats.

Frankly, I am tired of having everything being revisited 20 times just because we actually don't have a unified view on the FN...

/Ghyslain