RE: [rohc] Updated FN Draft - Appendix A

["Finking, Robert" <robert.finking at roke.co.uk>]

>To me, let can never be false,
>while a condition (assertion,
>"if") of course can, as that
>is the purpose of it.

Right, I think this is the sticking point. "let" can be wrong! If I say in a
co_format:

  let(x == 6);

and x is not given a value anywhere else, then it can't be wrong. However if
x is given a value somewhere else (e.g. in a uc_format) like this:

  let(x == y);

you now have two possibilities - either the two agree (i.e. y is 6), or they
contradict each other. If they contradict each other then they're wrong and
you can't use that packet format.

I can see what you're getting at though. To achieve what you want, I think
we'd have to say that in was an error for "let" statements to be false -
which would mean you could assume they'd always succeed. Then "if"
statements would have the possibility of being wrong, but would not bind
anything.

However this approach may be problematic because at present it's possible to
use "let" statements without knowing in advance whether the "let" will be
the only thing binding the expression. To put it simply, you currently don't
have to know whether you are writing an "if" or a "let" and in fact the same
statement may work equally well for both. The sort of time this becomes
useful is when you have multiple uc_formats some of which may define a field
and others not. I don't know if there is any usage of this within the TCP
profile?

It does put a burden on the profile writer to be clear about exactly what is
meant by forcing them to pick between the two options, and I'm not convinced
that the restriction on "let" statements always having to be true isn't
going to prevent ordinary usage and result in confusing notation. Worth
thinking about for a minute though.

Regards

Raffles

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