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

From: "Finking, Robert" <[email-masked]>
Date: Thu, 30 Sep 2004 12:28:25 +0100

Yes that's correct, annotations are an addition to, not a replacement for
comments.

-----Original Message-----
From: Carsten Bormann [mailto:[email-masked]] 
Sent: Thursday, September 30, 2004 12:24 PM
To: Ghyslain Pelletier (LU/EAB)
Cc: Eilert Brinkmann; Carsten Bormann; Finking, Robert; [email-masked]';
West, Mark; 'Kristofer Sandlund'; Lars-Erik Jonsson (LU/EAB)
Subject: Re: Annotoations - was (RE: ROHC-FN Snapshot - Wednesday's update )

On Sep 30 2004, at 13:02 Uhr, Ghyslain Pelletier (LU/EAB) wrote:

> Human readability, and then the packet formats can also be commented.
> Originally, these were added by Mark (by automated means) to improve 
> readbility of the specs.
> Comments are also useful in general.

I believe the % comments are still in.
(Section 4.7.1, end-of-line comments.)

Gruesse, Carsten

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

---

From: "Finking, Robert" <[email-masked]>
Date: Thu, 30 Sep 2004 14:03:42 +0100

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

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. Note however that it is not a requirement of any implementation that it does do the checking, just to facilitate the possibility.

I hope this helps

Raffles

-----Original Message-----
From: Ghyslain Pelletier (LU/EAB) [mailto:[email-masked]] 
Sent: Thursday, September 30, 2004 1:56 PM
To: 'Carsten Bormann'
Cc: Eilert Brinkmann; Finking, Robert; [email-masked]'; West, Mark; 'Kristofer Sandlund'; Lars-Erik Jonsson (LU/EAB)
Subject: RE: Annotoations - was (RE: ROHC-FN Snapshot - Wednesday's update )

> Annotations have the single advantage that it is easy to check them.
> So why make life hard?

Are we not going to use the FN to create a specification???

/Ghyslain

---

From: "Finking, Robert" <[email-masked]>
Date: Thu, 30 Sep 2004 14:48:38 +0100

]What is the objective we are trying to achieve? Make sure that the packet
]formats can be parsed by prolog or make sure that we produce a clear spec
for
]implementers? What is the redundancy for? For better understanding for the 
]readers or for automated sanity checks?

Both ;-) The whole point is to avoid tripping up implementers with
inconsistencies between the "bits on the wire" comments and the notation.
The reason for the automated sanity checks *is* for better understanding for
the readers. That's the only reason they exist =)

]If you want annotations to verify that we produce the right output, than it
is 
]up to your own impementation of the parser to use such annotations

Totally! We don't want to specify something that puts out restrictions on
the way people do things. But we do want to *allow* people to automatically
check the "bits on the wire" comments if they want to. We want it to be "up
to your own implementation". But unless we specify a way of describing bits
on the wire, it isn't "up to your own implementation", since you can't rely
on it being in any particular format - there's no way for you to do any kind
of checking.

Does that make sense?

Raffles

---

From: "Finking, Robert" <[email-masked]>
Date: Thu, 30 Sep 2004 15:15:25 +0100

]We had agreed at the Luleå workshop that we'd skip that part,
]the obvious danger being that there could be no profile at all in the end.

You're right, we did now you come to mention it - I'd forgotten about that
(sorry)! However this is very simple checking, the sole point of which is to
*help* in profile production.

]There might very well be things that adds a lot of complexity to the FN
that 
]could be clarified with a comment here and there using a more intuitive
version 
]of the FN.
Yes that's true, but we're not talking about adding a lot of complexity.
It's a short paragraph, and still fairly intuitive I think?

]> 
]> >  What is the redundancy for? For better understanding for 
]> the readers 
]> > or for automated sanity checks?
]> 
]> Both.
]
]I think that you cannot bite on having redundancy for sanity checks as part
of 
]the FN specification. This is something that you can do on the side as part
of 
]your parser implementation without adding this to the FN. So I think that 
]annotations can be removed and comments for number of bits reinstated using
%,
]without giving these a formal meaning.
]
]Where is the flaw in my reasoning?

The flaw is that this isn't "something that you can do on the side...
without adding this to the FN". You need a set syntax to be defined in the
FN, otherwise there's nothing for the parser to go on. However, please note
it's not compulsory. The way the FN is at present, there is no requirement
to use annotations. However if we remove them from the draft then we CAN'T
use them. I therefore propose that we leave them in the FN draft - it would
be a big waste of time rejigging all the examples that use them - and
instead just make a decision on whether to use them in the TCP profile or
not.

I hope this helps =)

Raffles

PS I keep copying this stuff to the list - we are supposed to be discussing
stuff on the list now aren't we?

---

From: "Lars-Erik Jonsson (LU/EAB)" <[email-masked]>
Date: Thu, 30 Sep 2004 16:20:53 +0200

> PS I keep copying this stuff to the list - we are supposed to 
> be discussing stuff on the list now aren't we?

Yes, thanks, please try to get all the stuff there. Maybe it is
time to re-start the threads.

/L-E

---

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

> It's a short paragraph, and still fairly intuitive I think?

I was also meaning as a general approach when making changes from 03...

> FN, otherwise there's nothing for the parser to go on. 

Parsing is not a requirement. Clarity and packet format correctness is.

> However, please note

That's not a big deal for me. I can do it.
 
> instead just make a decision on whether to use them in the 

Use them for what? You can standardize a sanity check in a specification...

---

From: "Finking, Robert" <[email-masked]>
Date: Thu, 30 Sep 2004 16:34:32 +0100

](BTW, when I bite hard on something, it is because of principles. I 
]know some peopleare bound to be pissed by that, but hey... convince me 
]that I need this then I will update my principles)

OK, I think the obstacles here are threefold.

1. There seems to be a misunderstanding about when tools would be applied - they're for use by us RoHCers during the development process, not for after the publication.
2. (this is the main one) Formal specifications are practically impossible to get right without tools. If you don't accept this then I can understand your viewpoint. Please consider the possibility though that the use of tools A. speeds up development and B. leads to a better end product. We have gone from having a formal Prologue definition which allowed you to test a whole profile down to the bits on the wire level, to a semi-formal English definition. The chances of us producing a correct formal spec without any machine checking are close to zero. If we do manage it, it will take a lot longer than with tools
3. The syntax of [ ] is apparently not intuitive to a human reader. I must admit that although I didn't like it much when Carsten first suggested it, I find that it's actually useful to have a different syntax for bits-on-the-wire comments, because they stand out, and have a kind of ASCII-art feel about them that says "we define the bit level structure". The only thing I can say to convince you here is that having used it myself I find it very readable - try using it yourself and see what you think. It's interesting that the people here arguing in favour of annotations are the ones who've had to spend time reading the FN over the past few months! Having said that, would you be happier with some alternative syntax that's easier for humans to read (e.g. Richard's original could be had by globally replacing "[" with ":" and "]" with "bits")?

Are there any obstacles that I have missed?

Raffles

---

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

> 1. There seems to be a misunderstanding about when tools 
> would be applied - they're for use by us RoHCers during the 
> development process, not for after the publication.

Agreed.

> 2. (this is the main one) Formal specifications are 
> practically impossible to get right without tools. If you 
> don't accept this then I can understand your viewpoint. 

I also agree.

> Please consider the possibility though that the use of tools 
> A. speeds up development and B. leads to a better end 
> product. We have gone from having a formal Prologue 
> definition which allowed you to test a whole profile down to 
> the bits on the wire level, to a semi-formal English 
> definition. The chances of us producing a correct formal spec 
> without any machine checking are close to zero. If we do 
> manage it, it will take a lot longer than with tools

I still agree.

> 3. The syntax of [ ] is apparently not intuitive to a human 
> reader. I must admit that although I didn't like it much when 
> Carsten first suggested it, I find that it's actually useful 
> to have a different syntax for bits-on-the-wire comments, 
> because they stand out, and have a kind of ASCII-art feel 
> about them that says "we define the bit level structure". The 
> only thing I can say to convince you here is that having used 
> it myself I find it very readable - try using it yourself and 
> see what you think. It's interesting that the people here 
> arguing in favour of annotations are the ones who've had to 
> spend time reading the FN over the past few months! Having 
> said that, would you be happier with some alternative syntax 
> that's easier for humans to read (e.g. Richard's original 
> could be had by globally replacing "[" with ":" and "]" with "bits")?

I still still agree.

The point is that annotations have been suggested as extendable, that's no good imho, and second tool helpers for tools used when developping profiles don't belong to the specifications imho. 

> Raffles
> 
> -- 
> 
> Visit our website at www.roke.co.uk
> 
> Roke Manor Research Ltd, Roke Manor, Romsey, Hampshire SO51 0ZN, UK.
> 
> The information contained in this e-mail and any attachments 
> is confidential to
> Roke Manor Research Ltd and must not be passed to any third 
> party without
> permission. This communication is for information only and 
> shall not create or
> change any contractual relationship.
>