Subject: RE: [rohc] Re: ROHC FN updated, soon to be resubmitted to move forward

From: "Finking, Robert" <[email-masked]>
Date: Mon, 20 Nov 2006 08:51:01 -0000

Hi Carsten,

Thanks for the update. Answers inline

Regards

Raffles

> -----Original Message-----
> From: Carsten Bormann [mailto:[email-masked]] 
> Sent: Sunday, November 19, 2006 9:49 PM
> 
> On Nov 09 2006, at 10:52, Carsten Bormann wrote:
> 
> >    It is still possible that the language of this ABNF is larger
> > than the one specified by ROHC-FN.
> >    (It certainly is as there are no semantic checks.)  I do think  
> > the syntax is reasonably minimal.
> 
> I made one mistake:
> The ABNF I checked in (in 1.84) contains C language conditional  
> expressions (of the form: cond ? trueexpr : falseexpr).
> These are not explicitly listed in -11, only what I thought to be  
> implicitly included by the introduction text in 4.7.
> I believe we have now decided that this text in 4.7 is introductory  
> and not normative.

That's correct =)

> Conditional expressions are not used by TCP-13 or ROHCv2, 
> either. So this was a case of "the language of this ABNF is 
> larger than the  
> one specified by ROHC-FN".
> I'm now reasonably certain this was the last such case (of course,  
> within the limits that you can express syntax by a notation like the  
> ABNF).
> 
> I have checked in a 1.86 on the authors' CVS.
> This also adds a small clarification in the introductory sentence  
> ("fnspec" is the start rule of the grammar).
> The fixed ABNF continues to:
> -- parse TCP-13 (with the 8_bit etc. change discussed here) and  
> ROHCv2-00 (using a home-grown ABNF compiler, though);
> -- be accepted by Bill Fenner's ABNF checker http://rtg.ietf.org/ 
> ~fenner/abnf.cgi;
> -- be accepted by Jutta Degener's abnfgen.

Great =) The ABNF checkers are good, but the successful parsing of
TCP-13 and ROHCv2 are what buys it for me. It would be useful to check
the examples in the FN draft too?

> PPS.: Jutta Degener's abnfgen is a nice tool to check ABNF 
> grammars. Here is one example of "valid FN syntax" generated 
> by that tool for  
> your amusement.
> Those who have tools that parse FN, I'd like to hear about your core- 
> dumps :-)
> 
> CONTROL
> 	{ENFORCE (	//
> !P ^J^L-
> 
>    N^T *N*!M^W   -!false ^!J^D !=!TG^!THIS.UVALUE ^R^O||	
> H^E/ !V^A-W/ 
> P^Y+J- !Y^E%!false^M^E
>  >!S^N  %  !(N) ^T^Z+
> !(U)^ J^Q	%!F^!Q^M!=	//
> O^N % P/E/!R^H	
>    <	  W^I% !Q^C
>    -K^V- !Z^E*M^C %!(G) ^ D^Q!=	//
>    ! Z  ^ !J^Q+//
> 	! (V)^ !P^E
> 
> *! 0B0
> ^ !(N)^ X^H&&
> !false ^U^G
> %  !Z^Y *!THIS.UVALUE^!D^Z	
> 	  -!J^E  *  I^T/ Y/L/!false ^L^E-		O^C % N%!T^O
> -! THIS.UVALUE^!H^P*
> !(U)^H^M
> %	!TI
> ^!(N) ^C^E//		
> 	//
> 	
> == //
> !SX   ^	  !N ^ Z^C<=	! false^  !Q^Y*!  7^  !(X) 
> ^V^I+!  W7^!K ^ A^D *! 
> THIS.ULENGTH ^
> ! false ^  !J^Q
> )	;  v  ://
> //
> V=:='0101'[
> C*J^Z<   T-C*J <=  T >= H^P -Q%B+ !U^I&&	  O/U 
> ==Y+Y==U%S +M^J 		  &&  
> P-G <=F>J-Z&&
> !U^A 	
> ==
> 
> !F^Z%  H^Q *!Z^ Z^S]  ;   }w3_(
> NVbs_3_ZE	,	Sq__	//
> //
> ,	m ,v//
> 	,hX6//h
> 	)	" "	//
> //,
> //
> ; 	  Q8(	K	 ,	 	//
> z){//	
> UNCOMPRESSED	r8//J	
> 		{}UNCOMPRESSED		V_e_9z4C{
> ENFORCE(P<=I<H-A!= B > R>=H-J 	
>    || 	
> X+N*S%B^C	);}} J(
> k_,x){UNCOMPRESSED	 	k__{
> }	}

Wonderful - exactly the sort of stuff we expect notators to produce ;-)

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

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 20 Nov 2006 16:20:31 +0100

On Nov 20 2006, at 09:51, Finking, Robert wrote:

> It would be useful to check

Great point.
I checked the examples in the draft, supplying what I considered to  
be appropriate scaffolding to make them a "complete FN spec"  
syntactically.
(Compare http://www.tzi.org/~cabo/extract.orig [which was created  
from the XML using http://www.tzi.org/~cabo/extract.rb] and http:// 
www.tzi.org/extract.out to see what I mean.)

The examples in the draft pass the ABNF, with one exception:

In 4.9, "ENFORCE" Statements/Normative Definition of ROHC-FN,
the syntax of "ENFORCE" Statements is given as:

      ENFORCE(<boolean expression>)

This is missing the final semicolon.
(In the above scaffolding, I have added this by hand to make the rest  
pass.)

So I would like to add the editorial comment that this needs to be  
changed into:

      ENFORCE(<boolean expression>);

Gruesse, Carsten

---

From: "Ghyslain Pelletier \(LU/EAB\)" <[email-masked]>
Date: Mon, 20 Nov 2006 17:26:25 +0100

Carsten,

I am looking at the ABNF. 
I have the following questions.
Sorry if some are naive, this is quite compact to read.

///Ghyslain

===============================
methdef = id S [parmlist S] "{" S 1*(formatdef S) "}"
        / id S [parmlist S] STRQ *STRCHAR STRQ S ";"
// I assume the second line is for english defined methods?
// I assume this refers to e.g.:
// list_tcp_options               "defined in Section 6.3.3";
// This would anyway match the following definition
STRCHAR = SP / HTAB / %x21 / %x23-7E
// which means anything except the control chars and quote (")

globctl = CONTROL S formbody
// Do we need to be clearer in FN about that
// we allow empty formbody {}, and that not having
// a formbody is the same as having an empty one?

encspec = "'" *("0"/"1") "'"
        / id [ S "(" S expn S *( "," S expn S ) ")"]
// Does it make sense to allow an empty ''?
// Should it not be at least one: 
//        "'" 1*("0"/"1") "'" 
// otherwise CLENGTH is bound to 0 and
// CVALUE is bound to undef, which I guess is ok
// but has no meaning.
// I know we don't disallow it in FN text currently ...

expn = *(expnc S "?" S expn S ":" S ) expnc
// we don't define this one.
// should we delete it or keep it?

expn = *(expnc S "?" S expn S ":" S ) expnc
// Is this above a clever way to make recursive this definition?
// (I've sort of gone cross-eyed back to expn->expnc->expn0->expn->...)

expn0 = "(" S expn S ")" / VARIABLE
// Is "VARIABLE" there ok?
// it can only occur in lenspec, not in expressions in general?
// right now it appears at multiple other places (any expn)

expn1 = expn0 / attref / constname / litval / id
// Why do we have "id" above?
// does that mean we allow fieldname in expressions?
// (seems to me that if so, this doesn't work)

fielddef = fieldgroup S ["=:=" S encspec S] [lenspec S] ";"
// does a:b [x]; means anything?
// I guess it requires a proper coding method somewhere else
// and that this is still ok.

Carsten Bormann wrote:
> I checked the examples in the draft, supplying what I
> considered to be appropriate scaffolding to make them a "complete FN
> spec" syntactically.
> (Compare http://www.tzi.org/~cabo/extract.orig [which was
> created from the XML using
> http://www.tzi.org/~cabo/extract.rb] and http://
> So I would like to add the editorial comment that this needs
> to be changed into:
>

---

From: "Ghyslain Pelletier \(LU/EAB\)" <[email-masked]>
Date: Mon, 20 Nov 2006 17:36:17 +0100

Carsten,

I've just looked at the CVS and noticed:
ABNF: Remove (a ? b : c) that should not have been there.

I had missed that you had already removed it, I was looking at preview
1.84.

///Ghyslain

Ghyslain Pelletier (LU/EAB) wrote:
> // This would anyway match the following definition STRCHAR =
> SP / HTAB / %x21 / %x23-7E // which means anything except the control
> chars and quote (") 
> 
> // Do we need to be clearer in FN about that // we allow
> empty formbody {}, and that not having // a formbody is the same as
> having an empty one? 
> 
>         / id [ S "(" S expn S *( "," S expn S ) ")"] // Does
> it make sense to allow an empty ''?
> // CVALUE is bound to undef, which I guess is ok // but has
> no meaning.
> expn = *(expnc S "?" S expn S ":" S ) expnc // we don't
> define this one.
> expn = *(expnc S "?" S expn S ":" S ) expnc // Is this above
> a clever way to make recursive this definition?
> expn1 = expn0 / attref / constname / litval / id // Why do we have
> "id" above? // does that mean we allow fieldname in expressions?
> // I guess it requires a proper coding method somewhere else // and
> that this is still ok. 
> 
> Carsten Bormann wrote:
>> syntactically. (Compare http://www.tzi.org/~cabo/extract.orig [which
>> was created from the XML using http://www.tzi.org/~cabo/extract.rb]
>> and http:// www.tzi.org/extract.out to see what I mean.)
>> 
>> In 4.9, "ENFORCE" Statements/Normative Definition of ROHC-FN, the
>> syntax of "ENFORCE" Statements is given as:
>> 
>> (In the above scaffolding, I have added this by hand to make the
>> rest pass.) 
>>

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 20 Nov 2006 18:21:48 +0100

> // I assume the second line is for english defined methods?

Yes.

> // which means anything except the control chars and quote (")

Yes.  I assume there is no need to allow quotes within these strings,  
which would then need an escape mechanism etc.

> // a formbody is the same as having an empty one?

What do you mean by "not having a formbody"?
As in "not having the formatdef"?

UNCOMPRESSED weirdformat {}

in a method definition actually does mean something (most useful  
where defaults are involved).

> // Does it make sense to allow an empty ''?

Not much, but there is no reason to exclude it, either.

f =:= '';
is a short form of
f =:= compressed_value(0,0);
which we aren't really excluding either.

> // Should it not be at least one:

Actually, CVALUE is bound to 0, but this has no effect when CLENGTH  
is 0 (modulo arithmetic).
Binding CLENGTH to 0 does have a meaning, which is useful in an  
alternative format.
E.g., in TCP-13 method "optional32", format "not_present", we could  
replace
     item =:= compressed_value(0, 0) [ 0 ];
by
     item =:= '';
and so on.

> // I know we don't disallow it in FN text currently ...

I don't care that much, except that this would be a technical change  
IMHO.

> // should we delete it or keep it?

My mistake, deleted in 1.86.

> // (I've sort of gone cross-eyed back to expn->expnc->expn0->expn- 
> >...)

That's an interesting property of C conditional expressions:
x = 1 ? 2 ? 3 : 4 : 5;  // sets x to 3
As we don't have them, we can ignore it.

> // right now it appears at multiple other places (any expn)

It is hard to enforce this semantic constraint in the syntax.

We need to allow:
          field  [ 8 * (5 + VARIABLE) ];

(It would be possible to have a second parallel definition for  
expressions that disallow VARIABLE, but it is more economic to put  
this restriction into semantics.)

Besides, since a lenspec is just an abbreviated enforcer, it would  
not be consistent to not allow VARIABLE in enforcers.
I'm not sure the FN really disallows or allows this, but I can live  
with semantic borderline cases here.

(You can always replace an encoding method that uses VARIABLE by one  
that uses a named parameter -- which then needs to be added to all  
encoding methods that use the method and so on, so there is no  
difference in power between a notation that allows VARIABLE and one  
that doesn't.  In other words: VARIABLE is the _ of Prolog...)

> // (seems to me that if so, this doesn't work)

As above: there is no way to enforce in the syntax that fieldnames  
and parameter names are different things.
(I do believe they come from different namespaces.)

> // does a:b [x]; means anything?

I'd say it is an abbreviation for
   a:b;
   ENFORCE(a._LENGTH + b._LENGTH == x);
where _ is U or C depending on context.

> // and that this is still ok.

Yes. This encoding method could come from a DEFAULT.

Thanks for the review!

Gruesse, Carsten

---

From: "Ghyslain Pelletier \(LU/EAB\)" <[email-masked]>
Date: Tue, 21 Nov 2006 10:10:04 +0100

Carsten,

Ok, I am happy with your answers to my review. Thanks.

///Ghyslain

Carsten Bormann wrote:
>> // This would anyway match the following definition STRCHAR = SP /
>> HTAB / %x21 / %x23-7E // which means anything except the control
>> chars and quote (")
> 
> Yes.  I assume there is no need to allow quotes within these
> strings, which would then need an escape mechanism etc.
> 
>> // Do we need to be clearer in FN about that // we allow empty
>> formbody {}, and that not having // a formbody is the same as having
>> an empty one?
> 
> in a method definition actually does mean something (most
> useful where defaults are involved).
> 
>>         / id [ S "(" S expn S *( "," S expn S ) ")"] // Does it make
>> sense to allow an empty ''?
> 
>> // otherwise CLENGTH is bound to 0 and // CVALUE is bound to undef,
>> which I guess is ok // but has no meaning.
> 
> Actually, CVALUE is bound to 0, but this has no effect when
> CLENGTH is 0 (modulo arithmetic).
> alternative format. E.g., in TCP-13 method "optional32", format
>      "not_present", we could replace item =:= compressed_value(0, 0)
>      [ 0 ]; by item =:= '';
> and so on.
> 
>> expn = *(expnc S "?" S expn S ":" S ) expnc // we don't define this
>> one. // should we delete it or keep it?
> 
>> expn = *(expnc S "?" S expn S ":" S ) expnc // Is this above a clever
>> way to make recursive this definition?
> (It would be possible to have a second parallel definition
> for expressions that disallow VARIABLE, but it is more
> economic to put this restriction into semantics.)
> 
> Besides, since a lenspec is just an abbreviated enforcer, it
> would not be consistent to not allow VARIABLE in enforcers.
> I'm not sure the FN really disallows or allows this, but I
> can live with semantic borderline cases here.
> 
> (You can always replace an encoding method that uses VARIABLE
> by one that uses a named parameter -- which then needs to be
> added to all encoding methods that use the method and so on,
> so there is no difference in power between a notation that
> allows VARIABLE and one that doesn't.  In other words:
> VARIABLE is the _ of Prolog...)
> 
> As above: there is no way to enforce in the syntax that
> fieldnames and parameter names are different things.