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

From: "Ghyslain Pelletier (LU/EAB)" <[email-masked]>
Date: Thu, 30 Sep 2004 16:32:10 +0200

Inline.

/Ghyslain

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Finking, Robert
> Sent: den 30 september 2004 15:04
> To: [email-masked]
> Subject: [rohc] RE: Annotoations - was (RE: ROHC-FN Snapshot -
> Wednesday's update )
> 
> 
> OK, I don't know if I'm going to help with this, or make 
> things worse, but...
> 
> The original concern was that the  "% xxx bits" comments, 
> which describe the bits on the wire would be more heavily 
> relied on than the formal part of the notation, since they 
> are easier for humans to read. That is not a problem, as long 

Fair enough, but this is the reader's problem. The definition of comments using % notation is already a warning that this is not a formal part of the definition.

Our responsability is to make sure that these comments are not wrong before publication, so that this situation does not happen. It does not belong to the notation itself to provide a solution to the problem to mention imho. 

> as they are correct. The worry is that a profile gets 
> updated, but the comments do not, and the two become 
> inconsistent, or else that some error is made in producing 
> the comments. I think Kristofer had an example of this 
> already happening once.

This means that we wouldn't be doing our work right. It seems for me obvious that an update to a spec must be verified before publication. Kristofer's example was about a work-in-progress, which obviously a spec is not.
 
> The basic idea was simply that it would be good to _be_able_ 
> to check if the comments were correct (i.e. consistent with 
> the formal part of the notation). The annotation is basically 
> just that. It's still a comment at heart, but it has a well 
> defined syntax that *can* easily be checked for consistency. 

You mean "parsed"... for me, this still has nothing to do with the final spec and annotations as formal comments do not belong to the FN.

> Note however that it is not a requirement of any 
> implementation that it does do the checking, just to 
> facilitate the possibility.

We are defining packet formats. We are not specifying how implementations are supposed to handle them, nor write text that imho is too specificly targeted at a specific implementation manner.
 
> I hope this helps

I always does : )
 
> Raffles

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

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 30 Sep 2004 17:17:50 +0200

Ghyslain,

I think the disconnect we have is that (on this set of issues) you 
think like a printer and I think like a software builder.

Printers traditionally threw away everything when the book was printed.
A new edition had to be built (typeset, laid out) from scratch.
So each new edition had a new set of errata.
Because people spent great amounts of time and worked very carefully, 
there was a limited set of errata.
(And book production was expensive.)

Computers changed the way we build things, both software and books.
Software builders tend to think "I must be able to type 'make' at any 
time and I will get a complete build".
So we have things (documents, software) in source form and in object 
form.
This makes no sense whatsoever if you are in a printer mindset.

Protocol specifications are never finished.  They get fixed at all 
kinds of stages.
So I genuinely believe the software builder mindset is the more 
appropriate one here.

Gruesse, Carsten