Subject: RE: [rohc] Updated FN Draft - Appendix A

From: "Lars-Erik Jonsson \(LU/EAB\)" <[email-masked]>
Date: Wed, 23 Mar 2005 15:06:33 +0100

> > Regarding the Appendixes, how outdated is their contents?
> > Personally, I don't think that the appendix is needed
> > to understand the FN, but the question is why was it put
> > there from the beginning? I'd like to hear a clear purpose.
> 
> The reason is that since the FN is formal, it needs defining
> formally.

Well, it is a more formal approach than we have previously
used, but I really think the proper level of formality is
what we have in section 4. 

> Without a formal syntax definition it's not possible
> to determine exactly what is legal notation and what isn't.
> More importantly it's needed to define a unique parsing of
> a given piece of notation. I'm not talking about tools here,
> but the actual meaning of the FN. If I write down 1 + 4 * 5,
> because your brain knows how to parse maths expressions, you 
> know this means "multiply 4 by 5 and add 1 to the result"
> (21) rather than "add 1 to 4 and multiply the result by 5".

Of course, the mechanisms of ROHC-FN must be well-defined,
but can you give an example where something is not well-defined
enough to be unambiguous in section 4?

> The same is true of the notation - without a set of rules
> to parse it by it is not possible to nail down the meaning of
> a profile. I guess I'm arguing that it's normative - so maybe 
> we should have syntax fragments associated with each
> subsection of section 4?

I fully agree with you that each subsection of section 4 should
have what is needed to correctly interpret its content. But
that does not mean we need syntax to be inserted from appendix A.

Looking at appendix A, section by section:

A.1 Reserved words

  I do not believe this adds anything, more than that it summarizes
  the mechanism defined by ROHC-FN. To me it is obvious that if you
  define packet formats with ROHC-FN, you can not use the same words
  with a different meaning without explicitly stating that you have
  overridden it.

  Summary: It could be useful with a summary of all keywords, in
           the beginning of the document, but it is not needed.

A.2 Characters

  This is not needed for humans!

  Summary: The world would be a better place if this is removed!

A.3 Literals

  If this is needed, it should be part of section 4, but I think
  the way we write literals is common practice, so it should not
  be needed at all.

And so on, I really have problems with seeing the point with
the content of this appendix.

/L-E

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

---

From: "Finking, Robert" <[email-masked]>
Date: Wed, 30 Mar 2005 11:56:22 +0100

Hi L-E, All,

Sorry for the delay, answers in line.

I am going to be out for a week after today. It would be great if you guys
could thrash this out (and also let-statements) whilst I'm away, so that we
can press on with this when I get back. I'll maybe release an updated
version later today with the more minor changes that have come up.

Hope you had a good Easter!

Regards

Raffles

> From: Lars-Erik Jonsson (LU/EAB) 
> Sent: Wednesday, March 23, 2005 2:07 PM
> 
> 

See below. However, the nature of these things is that you don't notice the
ambiguity until somebody uses it one way and somebody else interprets it
another. Therefore I think it is a mistake to just provide "patches" for
ambiguities that we can spot now - better instead to give a complete formal
description of the syntax.

>            the beginning of the document, but it is not needed.

OK, I understand what you're saying. Part of the problem here is the fact
that we're using ABNF (more on this below), but the reserved words do have a
formal meaning, which we can't state explicitly if we don't identify them
formally. This is an example of an ambiguity actually - is it possible to
have a field called "lsb" like this:

zero_low_word_16 ===
{
   uc_format = lsb, msb;
   co_format = lsb, msb
   {
     lsb  ::= uncompressed_value(8, 0);
     msb  ::= irregular(8);
   };
};

Your intuition may so "no", but somebody else's "yes". I agree with you that
this particular problem could be solved by an explicit reserved words
section elsewhere in the draft.

>   Summary: The world would be a better place if this is removed!

I agree - this section is utterly ludicrous and only needs to be present
because we're currently using ABNF to represent the syntax. I'd far rather
revert to EBNF which doesn't have this problem.

>   the way we write literals is common practice, so it should not

The problem is that that "common practice" varies from language to language,
so I think that we do need to specify it explicitly. Again your common
practice may be different to mine.

> the content of this appendix.

This I disagree with. The bulk of the most useful stuff is in the rest of
the appendix which you haven't commented on - it builds on top of trivia
like literals, that's why the first three sections are really needed;
because they're used in the remainder of the appendix. It is these
subsequent areas where you most need the formal clarification. I can
understand you not wanting to read the whole of section A, but I think your
comments stop a little too early at Literals!

---

From: "Finking, Robert" <[email-masked]>
Date: Wed, 30 Mar 2005 14:25:10 +0100

> the description of let must at
> least be improved so that it can be read without a mathematical
> mindset. The example appendix B must then also be expanded to cover
> also the assertion usage of let, both when used separately and in
> combination with a definition. Currently only the definition usage,
> which I find fully intuitive, is exemplified.

OK, whilst the discussion is going on (thanks guys for engaging on this),
why don't I also update the description of "let"? I'll try and get an
improved (but not intended to be final) set of words out to the I-D editor
before I leave today. I have been avoiding doing any updates in case the
syntax changes as a result of this discussion, but I can see that in order
to make progress we're probably going to have to try a few ideas out, so
I'll start with an improved (hopefully) description, to see how much that
helps.

If anybody is in disagreement with this, shout up quick!

Regards

Raffles

---

From: "Lars-Erik Jonsson \(LU/EAB\)" <[email-masked]>
Date: Wed, 30 Mar 2005 15:55:46 +0200

> On Mar 30 2005, at 13:46 Uhr, Lars-Erik Jonsson ((LU/EAB)) wrote:
> 
> > I had preferred a let statement that was only used for the
> > purpose of making definitions, while having a separate mechanism
> > for assertions.
> 
> The problem here is that we don't seem to be communicating very well 
> between the different mindsets.

Agree!

> Given that I'm looking at FN from a relational mindset, I'm still not 
> sure what the distinction is.

So, let's look at the examples you've given...

> Example 1:
> 
> variable_length_32_enc(flag) ===
> {
>          uc_format = field; %[ 32 ]
> 
>          co_format_not_present = field, %[ 0 ]
>          {
>             let(flag == 0);
>             field ::= static;
>          };
>          co_format_8_bit = field, %[ 8 ]
>          {
>             let(flag == 1);
>             field ::= lsb(8, 63);
>          };
>          co_format_16_bit = field, %[ 16 ]
>          {
>             let(flag == 2);
>             field ::= lsb(16, 16383);
>          };
>          co_format_32_bit = field, %[ 32 ]
>          {
>             let(flag == 3);
>             field ::= irregular(32);
>          };
> };

This is what I call a typical assertion, in non-matematical
English I would express this as an "If"-condition.
 
> Example 2:
> 
> irreg_tos_tc ===
> {
>          uc_format = tos_tc; %[ 6 ]
> 
>          co_format_tos_tc_present = tos_tc, %[ 6 ]
>          {
>             let(ecn_used:uncomp_value == 1);
>             tos_tc  ::= irregular (6);
>          };
> 
>          co_format_tos_tc_not_present = tos_tc, %[ 0 ]
>          {
>             let(ecn_used:uncomp_value == 0);
>             tos_tc  ::= static;
>          };
> };

This is what I call a typical assertion, in non-matematical
English I would express this as an "If"-condition.

> Example 3:
> [...]
>          co_format_ipv6_innermost_irregular =
>          {
>                  let(ip_inner_ecn:uncomp_value ==
>                      ip_ecn_flags:uncomp_value);
>          };
> [...]

I'm not sure about the context here! I guess this is also an "if".

> Example 4:
> [...]
>          co_format_eol_irregular =
>          {
>                  let(nbits - 8 == pad_len:uncomp_value);
>          };
> [...]

I'm not sure about the context here! I guess this is also an "if".

> Example 5:
> [...]
>          co_format_sack1_list_item = discriminator,
>                                      block_1,
>          {
>                  let(length:uncomp_value == 10);
>                  discriminator ::= '00000001';
>                  block_1 ::= tcp_opt_sack_block (ack_value);
>          };
> [...]

This also seems to be what I call a typical assertion, in
non-matematical English I would express this as an "If"-condition.

> Example 6:
> [...]
>        let (seq_number_scaled:uncomp_value ==
>                 seq_number:uncomp_value / payload_size);
>        let (seq_number_residue:uncomp_value ==
>                 mod(seq_number:uncomp_value, payload_size));
>        let (ack_number:uncomp_value ==
>                 (ack_stride:uncomp_value * 
> ack_number_scaled:uncomp_value) +
>                 ack_number_residue:uncomp_value);
>        let (ack_number_residue:uncomp_value ==
>                 mod(ack_number:uncomp_value, 
> ack_stride:uncomp_value));
> [...]

This is what I call a definition, also what I believe is
the intuitive meaning of let. This usage of let is what is
exemplified in appendix B. To me, let can never be false,
while a condition (assertion, "if") of course can, as that
is the purpose of it.

/L-E

---

From: "Finking, Robert" <[email-masked]>
Date: Wed, 30 Mar 2005 15:46:05 +0100

>To me, let can never be false,

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

---

From: "Lars-Erik Jonsson \(LU/EAB\)" <[email-masked]>
Date: Thu, 31 Mar 2005 10:53:48 +0200

Robert,

I think you have summarized very well, at least we seem to agree to
some degree on what we disagree about. 

So, can "let" be wrong? Yes, if you define it that way, while if it
only defined to constitute a definition, an assignment, then it
can't. I would prefer to let let constitute exactly that, an
assignment. You do not need to put a restriction on let to make it
so, but the definition of let would of course not include anything
but a "define/assign" mechanism. 

You say that sometimes you do not know whether it will be only an
"if", but I have not seen an example of when this is really needed.
I'm still waiting for a realistic example of when one would have
to have that. Just because the current definition of let allows that
does not mean it is really needed.

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

I think it is reasonable to require the profile writer to be
clear about what is meant, my whole point of bringing this up
is to improve clarity and not have functionality that can not
be justified. Through the step-by-step build-up of appendix B, 
all functionality is also motivated when exemplified. What let
currently provides through its combination of let and if is 
from what I have seen hard to *really* justify by realistic needs.

/L-E

> -----Original Message-----
> From: Finking, Robert [mailto:[email-masked]]
> Sent: den 30 mars 2005 16:46
> To: Lars-Erik Jonsson (LU/EAB); Carsten Bormann
> Cc: [email-masked]
> Subject: RE: [rohc] Updated FN Draft - Appendix A
> 
> 
> 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
> 
> -- 
> 
> Visit our website at www.roke.co.uk
> 
> Roke Manor Research Ltd, Roke Manor, Romsey, Hampshire SO51 0ZN, UK.
> 
> The information contained in this e-mail and any attachments 
> is proprietary to
> Roke Manor Research Ltd and must not be passed to any third 
> party without
> permission. This communication is for information only and 
> shall not create or
> change any contractual relationship.
> 
>