Subject: RE: [rohc] RE: Annotoations - was (RE: ROHC-FN Snapshot - Wednesd ay's update )

From: "Finking, Robert" <[email-masked]>
Date: Fri, 1 Oct 2004 08:49:13 +0100

I'd be happy to settle for that. Thanks for mediating =)

-----Original Message-----
From: Kristofer Sandlund [mailto:[email-masked]] 
Sent: Friday, October 01, 2004 8:00 AM
To: Finking, Robert
Cc: 'Ghyslain Pelletier (LU/EAB)'; [email-masked]; Carsten Bormann
Subject: Re: [rohc] RE: Annotoations - was (RE: ROHC-FN Snapshot - Wednesd
ay's update )

Hi,

since this discussion seems to deteriorate into religious warfare, let me 
suggest a compromise. If I have managed to misunderstand the points of
conflict 
after 100s of mail of the subject, please do hit me over the head with a
mail 
swarm and I'll butt out of this issue forever.

We have all agreed that the annotations don't actually have a normative
meaning 
so why not do the following:
- Relax the text around them to clearly show that this is actually just a 
comment and does not mean anything formal.
- Remove all mention of tools. If someone wants to write parsers or use
tools, 
then fine, but why mention it in the specification? If a profile writer
happens 
to abuse these for some reason, they are still just comments.
- Rename them from Annotations to "Field Width Comments" to emphasize that
these 
are COMMENTS

Can Ghyslain agree on keeping them then? And also, can Carsten and Robert
agree 
to this kind of reduction of them?

My suggestion for a replacement text is the following:

4.7  Comments

    Comments do not affect the formal meaning of what is
    notated, but can be used to improve readability.  Their use is
    optional.

    ......<rest of the section is unmodified>..........

<I simply removed any mention of annotations>

4.7.3  Field Width Comments

    A special type of comment that can be used to help the reader interpret 
packet formats is bitfield width comments. As all comments, these have no
formal 
meaning, but normally only appears immediately after a field name. These 
comments use a "[" and "]" as delimiters. Enclosed within these brackets, a 
number indicating the width of the preceding field should be written.

  For example:

       uncompressed_format  =   discriminator     [  8 ],
                                tcp.seq_number    [ 32 ],
                                tcp.flags.ecn     [  2 ],

<Now, it should be clear to the reader that these do not mean anything, and 
there is no mention of tools or other "offending" words. There is no
description 
of what happens if they are "wrong" etc which also makes it clear that these
do 
not have any kind of meaning. The text can be improved if you accept what
I'm 
trying to suggest>

Can they really offend anyone now? If the problem is the use of brackets,
then 
the same person should also be offended by the fact that we can have both
"%" 
and "/* ... */" comments. And this does in no way stop the use of parsing
tools.

/Kristofer Sandlund, Effnet AB

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

---

From: "Ghyslain Pelletier (LU/EAB)" <[email-masked]>
Date: Fri, 1 Oct 2004 12:44:41 +0200

> Ah, OK, so is the sticking point this:
> 
>    That you think it is possible to have tools without the 
> spec providing
> the syntax they need to work on, whereas I (and I assume 
> Carsten) don't?

Yes. This is my opinion.

---

From: "Ghyslain Pelletier (LU/EAB)" <[email-masked]>
Date: Fri, 1 Oct 2004 13:29:06 +0200

> now that we have agreed on what we actually want them to do. 
> Fight it out among 
> yourselves, but please agree in less than 100 mails this time ;)
> 

What I'd like to make sure that we have agreed, is that annotations are not to be formal - meaning that they cannot either be extended in the future to specify e.g. attributes to be used my coding methods etc such as it was suggested before (expanding annotations is currently explicitly allowed in the text Robert sent us this week). Do we all agree on this view?

Maybe I was not clear before, but I don't care much about that they are included (although the printer in me does prefer the % x bits comment) in the spec, as long as they have no formal meaning and that it does not open up a mechanism for specifying other things (and mainly things targeted towards verification tools).

So, in this respect, in the ROHC-FN draft - the only thing that we need to define are comments using % or /**/. In the ROHC-TCP spec we can have a comment just before the FN spec of the packet formats that explain what the % [ x] means and its purpose, nothing more.

Is it possible to agree on this?

/Ghyslain

---

From: "Ghyslain Pelletier (LU/EAB)" <[email-masked]>
Date: Fri, 1 Oct 2004 13:37:51 +0200

> >        uncompressed_format  =   discriminator,    %[  8 ]
> 
> fine (but won't be checked by tool)

Why can't it be checked by a tool?
Doesn't the [ 8 ] only apply to the right-hand side of the statement?

/Ghyslain

---

From: "Ghyslain Pelletier (LU/EAB)" <[email-masked]>
Date: Fri, 1 Oct 2004 14:41:10 +0200

> Is the issue here that you don't want a third kind of comment 
> (which is all it will be from a human reader's point of 
> view)? Or is it something else? I feel I'm not quite 
> understanding your objection! Please explain =)

Again - I don't believe that there should be things included in a specification for the purpose of verification tools that in turn are not even specified themselves (not that I want to do that either ; ), and if we start adding such things why not start adding other stuff for other type of verifications then?

But hey, I'm sick of this discussion (surely just like everyone else), you and Carsten can have it the way you want - so I ain't saying anything else on that stupid topic. I'll just bend and shut up [everyone - cheer now!].

Then I'll just restrict the text of the annotation to make it a parseable comment (thus I give up that these should not be formal) that has the fixed meaning as to meaning the number of bits of the field BUT will include text to restrict their use to that sole purpose, i.e. can't/won't be extended.

And for the record, I perfectly understand why you think this needs to be in, how it works and how you want to use it, but it is still of my opinion that this is not appropriate in a spec since it is very much dependant on what Carsten wants to do with his parser and how he want to make verifications - IT HAS NOTHING TO DO WITH SPECIFYING PACKET FORMATS (sanity checks don't specify anything, only redundancy, and then you need to keep text in the FN to state what happens if these disagree and so on - bleuh).

/Ghyslain

PS: The reason why I am _very_ annoyed by all this is that I spent a whole week of my summer vacations to try to make the final touch to the FN spec and make it for the IETF 60th deadline (and we've done most of these updates together) following the week in Luleå during the TCP/FN WS, and all those present we agreeing that -03 was very very close to the way we wanted this to be. At IETF, someone just started throwing everything out and now we are far from done it seems. We had decided to drop the Prolog verification. It feels like we could have nailed the whole thing in time by then in a satisfactory manner but hey... why stop the fun so early [everyone - boo now...].

And I thought we had agreed on the deadline which is already almost passé!

Call me a printer experiencing a paper jam if you want, that does not even bother me anymore.

---

From: "Finking, Robert" <[email-masked]>
Date: Fri, 1 Oct 2004 15:02:42 +0100

Hi superstars,

Comments in line =)

]
]But hey, I'm sick of this discussion (surely just like everyone else), you
and Carsten 
]can have it the way you want - so I ain't saying anything else on that
stupid topic. 
]I'll just bend and shut up [everyone - cheer now!].

=O no wait, don't capitulate! We don't want you to resign yourself to this.
We want you to realise that our way is best  =)  Just kidding - thanks for
being happy to resolve this!

]
]Then I'll just restrict the text of the annotation to make it a parseable
comment (thus 
]I give up that these should not be formal) that has the fixed meaning as to
meaning the 
]number of bits of the field BUT will include text to restrict their use to
that sole 
]purpose, i.e. can't/won't be extended.

Sounds good to me =)

]
]And for the record, I perfectly understand why you think this needs to be
in, how it 
]works and how you want to use it, but it is still of my opinion that this
is not 
]appropriate in a spec since it is very much dependant on what Carsten wants
to do with 
]his parser and how he want to make verifications - IT HAS NOTHING TO DO
WITH SPECIFYING 
]PACKET FORMATS (sanity checks don't specify anything, only redundancy, and
then you need 
]to keep text in the FN to state what happens if these disagree and so on -
bleuh).
]

OK, point taken - thanks =)

]PS: The reason why I am _very_ annoyed by all this is that I spent a whole
week of my 
]summer vacations to try to make the final touch to the FN spec and make it
for the IETF 
]60th deadline (and we've done most of these updates together) following the
week in Luleå 
]during the TCP/FN WS, and all those present we agreeing that -03 was very
very close to 
]the way we wanted this to be. At IETF, someone just started throwing
everything out and 
]now we are far from done it seems. We had decided to drop the Prolog
verification. It 
]feels like we could have nailed the whole thing in time by then in a
satisfactory manner 
]but hey... why stop the fun so early [everyone - boo now...].

No I agree. I was pretty shocked by what came back from IETF60. I'm not
saying it isn't an improvement, but I did kind of feel as though the
agreement we had in Luleå had gone out the window... and the deadline with
it!

---

From: "Lars-Erik Jonsson (LU/EAB)" <[email-masked]>
Date: Mon, 4 Oct 2004 10:27:49 +0200

> Doesn't the [ 8 ] only apply to the right-hand side of the statement?

I have the same question. Maybe it can't be checked by your tool
because of the way you have written it, but I fail to understand
why it should not be possible to write a tool that would check it.

/L-E

---

From: "Ghyslain Pelletier (LU/EAB)" <[email-masked]>
Date: Mon, 4 Oct 2004 11:45:49 +0200

Comments Inline...

///Ghyslain

> From: Carsten Bormann [mailto:[email-masked]]
> Sent: den 4 oktober 2004 11:22
> To: Finking, Robert
> Cc: Carsten Bormann; [email-masked]'; 'Kristofer Sandlund'; Ghyslain
> Pelletier (LU/EAB); Lars-Erik Jonsson (LU/EAB)
> Subject: Re: [rohc] RE: Annotoations - was (RE: ROHC-FN Snapshot -
> Wednesd ay's update )
> 
> 
> On Oct 04 2004, at 10:57 Uhr, Finking, Robert wrote:
> 
> > I guess it depends if you're hand coding the parser or not, 
> and also 
> > whether
> > you want to stick to single character lookahead or not (which makes 
> > things a
> > lot simpler of course).
> >
> > Probably I better let Carsten answer this anyway!
> 
> Our tool is written in Prolog.
> Prolog DCGs can do unlimited look-ahead (without these we would never 
> have been able to parse the near-unparseable Lulea syntax...).
> 
> It is unsavory, but not particularly hard to implement, to change the 
> syntax to look for special comments after delimiter symbols 
> and relate 
> the contents of these comments to what was before the 
> delimiter symbol. 
>   I'll certainly bow to any rough consensus that emerges.

I know I am not going to impress anyone with this, but my printer-like understanding of parsing and design of parsing tools come from Lex/YaCC (I kwnow, it's a dinosaur whose asteroid still hasn't fallen - every lol at me!) that I have used 10 years ago to program an interpreter language specialised in automation of tele switch testing for E///. I sort of remember Lex being capable of doing a single look-ahead to e.g. conciliate comments and the line continuation character, and could not see that the situation mentioned here was a problem for parser design in general...

But then, I don't consider stuff I even did last month as recent enough to based my understanding of things onto... but it's good to know that I did not seemed to be that wrong about this all along.

---

From: "Lars-Erik Jonsson (LU/EAB)" <[email-masked]>
Date: Tue, 5 Oct 2004 09:39:43 +0200

> > To me, this is a non-valid argument. I've writen a few 
> > parsers in my life, and I cannot see why any parser
> > cannot have one treatment (use this) for a comment
> > starting with %[ and another one (throw this away) 
> > for a comment that starts with % followed by anything
> > other than [ .
> 
> That is the easy part. 
> I just implemented the unsavory part: relating back 
> information from an annotation that is written *after*
> some construct-terminating delimiter.
> 
> 	uncompressed_format = protocol; %[16]
> 
> 	format_ether_v4 = discriminator, %[ 1 ]
> 	                  next_protocol, %[ 0 ]
> ...
> 
> Yech.  I need some kimchi to get the bad taste out of my mouth...

But the important thing is not the potential bad taste of 
implementing a verification tool for protocol development,
but that it is doable also with comment-based annotations.
This way we can avoid having to modify the notation just for
verification purposes in the profile development.

/L-E