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

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

Thanks Kristoffer,

Well, I agree with your proposal since this is in substance where I am trying to get at.

But I don't agree with how it should look like:

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

What I'd want to get at is the following:

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

Hence, the annotation is there (for tool-minded people) but it is formally only a mere comment.
Otherwise, it is still embedded into the formalized notation (and the annotation comes before the ',').
AND I will gladly remove any mention of tools in the draft if everyone agrees.

Does this not make more sense?

///Ghyslain

--
 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
 [email-masked]
 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.
-----------------------------------

> -----Original Message-----
> From: Kristofer Sandlund [mailto:[email-masked]]
> Sent: den 1 oktober 2004 09:00
> 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: Kristofer Sandlund <[email-masked]>
Date: Fri, 01 Oct 2004 13:20:22 +0200

For the, it does not matter if these are written as

        uncompressed_format  =   discriminator     [  8 ],
or
        uncompressed_format  =   discriminator,    [  8 ]
or
        uncompressed_format  =   discriminator,    %[  8 ]
or
        uncompressed_format  =   discriminator     /*[  8 ]*/,
or
        uncompressed_format  =   discriminator,     /*[  8 ]*/

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 ;)

BR,
  Kristofer

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 1 Oct 2004 13:32:36 +0200

>        uncompressed_format  =   discriminator     [  8 ],

fine

>        uncompressed_format  =   discriminator,    [  8 ]

this "field width comment" is not directly after a field name in a 
field list -- not fine

>        uncompressed_format  =   discriminator,    %[  8 ]

fine (but won't be checked by tool)

>        uncompressed_format  =   discriminator     /*[  8 ]*/,

ditto

>        uncompressed_format  =   discriminator,     /*[  8 ]*/

ditto.

Gruesse, Carsten