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

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

]> 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?

OK, I'll agree to that =)

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

Phew! Well that's the main hurdle then! 

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

I certainly agree it has no formal meaning - and as to what it specifies, my understanding is that it's just plain number of bits and nothing more - is that what you mean?

]
]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?

Ag, no this is a sticking point. If that was OK, then we wouldn't be having this discussion. The whole point of this syntax is that it enables a tool to do something different from what it does with the other two kinds of comments.

We need the tool to be able to differentiate between the comments it should always ignore and those it can interpret. Ordinary comments are completely ignored, you just throw them away before you even start. They are invisible if you like.

So, for you suggestion to be OK, it would mean a tool would have to start parsing all the comments along with the rest of the formal notation, which is a complete nightmare. The whole point of the [ ] syntax is that we need something special that's *different* to ordinary comments, so that the tool doesn't throw the content away before it starts, but can easily pick it out and process it.

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

Thanks in advance

Raffles

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

---

From: Kristofer Sandlund <[email-masked]>
Date: Fri, 01 Oct 2004 14:32:40 +0200

Comments below.

> 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 objecti…

I agree with Robert here, in that I don't see why Ghyslain is so vehemently 
against the "["-style comments. Like I said earlier, if you object to those, 
then you should also object to "/*" comments for crying out loud. If there are 
two or three different deliminators for comments should not make any difference 
to you or to anyone else.

As for the other camp, I can't see why on earth you would object to the /*[2]*/ 
way of writing them. If you cannot write a parser that looks for "/*[" instead 
of "[", then the problem does not really lie in the notation ;)
(yes, this would make "non-bitfield" comments unable to start with "[" but when 
would this happen? And If you think this is an issue, let's ban it then).

So once again, I think both camps are fighting over something that is not an 
issue. Someone please yield so we can move on to things that actually are issues.

/Kristofer (trying to mediate as Bad Cop when Good Cop did not work)