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

From: "Finking, Robert" <[email-masked]>
Date: Fri, 10 Nov 2006 09:29:29 -0000

Hi again,

Inline

> Ed.:
> The intro of 4.7 can still be confused with a normative list of what  
> the differences between C90 and FN are, which it isn't.

OK, I guess it wouldn't hurt to make it clear that this is C90
expressions we're talking about, not the entire language... we will of
course be relying on the reader to be sensible at this point since C
expressions do cover quite a lot of things not normally thought of as
expressions (such as assignment for example), but I'm assuming the
context of the FN (e.g. having no side effects) should make this plain.

> 
> There are still a few instances of "perfectly allowable", but 
> the RFC  
> editor is likely to fix those.

I guess a search and replace wouldn't take long - it's nice that we're
down to this level of comment now! ;-)

> 
> Technical:
> I'd still like to have non-empty identifiers on formats... (already  
> mentioned in parent.)

Has been discussed and agreed on list. If anybody else also objects to
empty identifiers shout now - my understanding is that we have
consensus.

> 
> I'm not sure I have an answer to my comment on 4.12.3.2.
> 
> 
> In summary:
> -- We have a fully baked spec of the FN language (just needs to be  
> pulled out of the oven)
> -- We have two non-trivial profiles that make use of the FN
> 
> Color me happy...

=)

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

---

From: "Finking, Robert" <[email-masked]>
Date: Fri, 10 Nov 2006 10:47:46 -0000

Hi Ghyslain,

Many many thanks for your continued support of the WGLC process - apologies that I'm not putting more in right now.

Regarding ABNF here is my take. Whilst the draft is OK without it, it would be much better with it. There are two reasons:
1. When defining any formal language it is useful to have a formal definition of that language, because... however precisely you try to write the English it will always have ambiguities in it.
2. Since the whole point of the FN is exactly this (i.e. point 1.), it seems a bit crazy for the FN to provide formality to ROHC, and then not have a formal definition of its own syntax.

We used to have an ABNF appendix a while back, but I ran out of time to maintain it and regrettably had to bin it. Now that Carsten has put the hard work in of producing it and has verified it against the ROHCv2 and TCP drafts, it seems mad not to use it.

My only concern is that it might on it's own trigger another WGLC, which I definitely want to avoid as I have very little time left that I can spend on this! If L-E could manage a mini-LC (e.g. a week long) that would be fine by me. I really would like to have the ABNF in.

One final note. Although very much in favour of a formal syntax, I am somewhat perturbed that it appears to have been added to the XML source of the draft without agreement from the authors - especially as we don't even have consensus on the list yet! Carsten, even though the FN draft is hosted on your server, please ask before making edits to it! Thanks.

Regards

Raffles

> -----Original Message-----
> From: Ghyslain Pelletier (LU/EAB) 
> [mailto:[email-masked]] 
> Sent: Thursday, November 09, 2006 4:11 PM
> To: Carsten Bormann; Finking, Robert; West, Mark
> Cc: [email-masked]
> Subject: ROHC FN updated, soon to be resubmitted to move forward
> 
> 
> Carsten, Mark, all,
> 
> First, I'd like to thank once again Mark and Carsten for 
> their excellent reviews.
> 
> From my point of view, all the comments of relevance to the 
> correctness of the FN specification have been addressed as 
> agreed; the draft is updated and checked into the CVS: 
> http://www.dmn.tzi.org/cgi-bin/cvsweb.cgi/fn/draft-ietf-rohc-f
> ormal-notation.xml
> 
> Please review carefully as I would like to resubmit the draft shortly.
> 
> With respect to the comment on ABNF - I am not entirely sure 
> about the relevance of the motivation and/or purpose of 
> including ABNF into an Appendix in the FN draft, as it seems 
> to be the proposal from Carsten. What I mean with this is 
> that I don't see that it has any significant impact of the 
> correctness and the quality of the FN specification, 
> actually. The text already defines the syntax properly and 
> nothing is missing, and this seems to be confirmed by the 
> general consensus and by the reviewers as well. As far as I 
> understand, some of the comments received were derived from 
> the exercise of translating the FN into ABNF, but now these 
> comments have been addressed. Point being, I think this is 
> too small an addition to the draft to put more efforts on 
> this, plus the necessary review of that additional information.
> 
> So, as I'd _really_ like to expedite this draft (as well as 
> RoHC-TCP), I suggest that we leave it at this, or 
> alternatively I suggest that Carsten writes a complete 
> formatted appendix, gets it verified asap, and gets asap 
> consensus to include it. The word here being asap.
> 
> And to clarify my personal opinion here -- I have actually 
> really appreciated Carsten serious and comprehensive review, 
> I think it's been very helpful, I've also looked at the ABNF, 
> and I would like to thank him once more for this. It's just 
> that I think that the timeframe for changes/addition is way 
> overdue, so that we have to draw the line and move on with 
> this one, and since no one else seems to want to do this ... 
> and if this is really deemed useful by some, what about a 
> separate informational draft so that this appendix does not 
> simply become a new bottleneck for FN and RoHC-TCP?
> 
> So, dear reviewers and working group members, please review 
> the changes checked into the CVS and give us a shout if we've 
> missed something.
> 
> Best regards,
> 
> ///Ghyslain
> 
> > It would be appreciated by the authors if you could as well 
> prepare a 
> > complete formatted appendix IF this is your proposal 
> regarding ABNF in 
> > FN. This would also surely help in discussing the relevance 
> of having 
> > such appendix and facilitate any agreement as I am not currently 
> > convinced that this is something that is 
> necessary/compelling to have.
> > 
> 
> 
> 
> --
>  Ghyslain Pelletier, Dipl. Ing.
>  Wireless IP Optimizations
>  Ericsson Research, Corporate Unit
> 
>  Ericsson AB, Laboratoriegränd 11
>  Box 920, S-97128 Luleå, SWEDEN
>  Phone : +46 (0)  8 404 29 43
>  Mobile: +46 (0) 70 264 83 14
>  Ghyslain.Pelletier at ericsson.com
>  http://www.ericsson.com
> 
> -----------------------------------
>  The opinions expressed in this
>  message are my personal opinions.
>  These opinions are not
>  necessarily those of my employer,
>  unless stated otherwise.
> -----------------------------------
>

---

From: "Finking, Robert" <[email-masked]>
Date: Fri, 10 Nov 2006 10:53:54 -0000

To clarify, I think the ABNF should be normative - I can't see any point in having an informative formal definition.

Now I've just got to re-read the draft!

Cheers

Raffles

> From: Finking, Robert [mailto:[email-masked]] 
> Sent: Friday, November 10, 2006 10:48 AM
> To: Ghyslain Pelletier (LU/EAB); Carsten Bormann; West, Mark
> Cc: [email-masked]
> Subject: [rohc] RE: ROHC FN updated, soon to be resubmitted 
> to move forward
> 
> 
> Hi Ghyslain,
> 
> Many many thanks for your continued support of the WGLC 
> process - apologies that I'm not putting more in right now.
> 
> Regarding ABNF here is my take. Whilst the draft is OK 
> without it, it would be much better with it. There are two 
> reasons: 1. When defining any formal language it is useful to 
> have a formal definition of that language, because... however 
> precisely you try to write the English it will always have 
> ambiguities in it. 2. Since the whole point of the FN is 
> exactly this (i.e. point 1.), it seems a bit crazy for the FN 
> to provide formality to ROHC, and then not have a formal 
> definition of its own syntax.
> 
> We used to have an ABNF appendix a while back, but I ran out 
> of time to maintain it and regrettably had to bin it. Now 
> that Carsten has put the hard work in of producing it and has 
> verified it against the ROHCv2 and TCP drafts, it seems mad 
> not to use it.
> 
> My only concern is that it might on it's own trigger another 
> WGLC, which I definitely want to avoid as I have very little 
> time left that I can spend on this! If L-E could manage a 
> mini-LC (e.g. a week long) that would be fine by me. I really 
> would like to have the ABNF in.
> 
> One final note. Although very much in favour of a formal 
> syntax, I am somewhat perturbed that it appears to have been 
> added to the XML source of the draft without agreement from 
> the authors - especially as we don't even have consensus on 
> the list yet! Carsten, even though the FN draft is hosted on 
> your server, please ask before making edits to it! Thanks.
> 
> Regards
> 
> Raffles
> 
>

---

From: "Finking, Robert" <[email-masked]>
Date: Mon, 13 Nov 2006 08:42:23 -0000

My understanding was that we'd agreed to leave it as it is, but update
the text to clarify.

Raffles

> From: Carsten Bormann [mailto:[email-masked]] 
> Sent: Friday, November 10, 2006 2:27 PM
> To: Finking, Robert
> Cc: Carsten Bormann
> Subject: Re: [rohc] ROHC FN updated, soon to be resubmitted 
> to move forward
> 
> 
> On Nov 10 2006, at 01:29, Finking, Robert wrote:
> 
> > consensus
> 
> Explain?
> I don't know whether you think one way or the other.
> 
> Gruesse, Carsten
> 
>

---

From: "Finking, Robert" <[email-masked]>
Date: Tue, 21 Nov 2006 08:38:53 -0000

Great. Thanks Carsten - good catch. Apologies for not mailing you my
extracted examples file last night, but looks like you got on fine
without it =)

Raffles

> Sent: Monday, November 20, 2006 3:21 PM
> To: Finking, Robert
> Cc: Carsten Bormann; West, Mark; [email-masked]; Ghyslain 
> Pelletier (LU/EAB)
> Subject: Re: [rohc] Re: ROHC FN updated, soon to be 
> resubmitted to move forward
> 
> 
> On Nov 20 2006, at 09:51, Finking, Robert wrote:
> 
> > It would be useful to check
> > the examples in the FN draft too?
> 
> 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: "Finking, Robert" <[email-masked]>
Date: Tue, 21 Nov 2006 08:40:59 -0000

Thanks for looking at these =) About the compactness, Carsten is it
possible to have blank lines between the productions? That would help I
think!

Raffles

> Sent: Monday, November 20, 2006 4:26 PM
> To: Carsten Bormann; Finking, Robert
> Cc: West, Mark; [email-masked]
> Subject: RE: [rohc] Re: ROHC FN updated, soon to be 
> 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://
> > 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.)
> >