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 17:32:51 +0200

Carsten,

I can take that critic, but I'd rather say that this has nothing to do with printers or your nice story. Annotations, has you suggested yourself offline with CRC static/dynamic split issue, can evolve to hide things we can't seem to be capable of defining in the coding library - i.e. it has been suggested that they are not only for sanity checks. This worries me, as it since we know that we can't come up with coding methods that will for sure work in the future profiles and we know we'll have to evolve the spec, then tehre is a risk that annotations be abused in their purpose (hopefully this can correspond to sofware builder thinking)

This is my concern. Does it not make sense?

Reminding you the offline suggestion:

> Explanation by example:
> 
> uncompressed_format = checksum [16][crc_prio = CRC_DYNAMIC],
> 
> This is shorthand for		      ...
> 
> uncompressed_format = checksum [annotation = 16][crc_prio = CRC_DYNAMIC],
> 		      ...
> 
> It creates two attributes, uncomp_annotation and uncomp_crc_prio,
> setting the first one to 16 and the second one to CRC_DYNAMIC (a
> constant that might, e.g., evaluate to 1).

while it seem that instead we should be looking into using our well-defined coding methods to tackle this without using annotations, example using

> crc_s = crc_static(initial_val, .......)
> crc = crc_dynamic(crc_s)

(This I have discussed with Kristoffer offline as well.)

Now, since sanity checks using annotations anyway should not impact how the spec will look like (the printer thinking), then I think I'd rather not have the thing at all.

///Ghyslain-the-printer-seeing-an-offending-mechanism ; )

--
 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: Carsten Bormann [mailto:[email-masked]]
> Sent: den 30 september 2004 17:18
> To: Ghyslain Pelletier (LU/EAB)
> Cc: 'Finking, Robert'; Carsten Bormann; [email-masked]
> Subject: Re: [rohc] RE: Annotoations - was (RE: ROHC-FN Snapshot -
> Wednesd ay's update )
> 
> 
> 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
> 

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

---

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

Ah, but my offline suggestion was about my mirage FN', not the version 
we are defining right now.
(My brain needs FN' to keep its balance in the presence of the 
limitations of FN. :-)
We might come up with a completely different way to do this in FN'.
Things I might want to do with annotations in FN' don't invalidate 
annotations in FN, except if they somehow show that we dug ourselves in 
a hole -- the whole point of my little offline missive was to point out 
that we didn't (the hole has at least one exit, but it most likely has 
many).

Gruesse, Carsten