Subject: [rohc] Annotations, underscores and the remaining TCP/FN stuff

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

ROHCers,

Ok, I give up [more cheers!] : )

Let me summarize what comes out of the mess I seem to have created on the list since yesterday:

1) We'll leave the underscore, we can leave the annotations in.

In addition, I will make the following changes to the FN:

2) modify section 4.8.7 as follow:

4.8.7. Profile-specific Encoding Methods

   The library of encoding methods provides a basic and
   generic set of coding methods. Some additional encodings 
   specific to a particular protocol may however be needed, 
   such as for methods that infer the value of a field from 
   other values. These methods are defined based on the 
   properties of the protocol being compressed.

   Profiles may define additional encoding methods; the 
   scope of these methods is then local to the profile 
   definition itself, and they can be used as part of the 
   formal definition of the profile as any other methods 
   from the library (see section xxxx).

   Profile-specific encoding methods must be rigorously
   defined using either the ROHC-FN syntax or in plain
   text, as long as its definition provides enough
   information to unambiguously implement the encoding
   method in the compressor and the decompressor. These
   methods should be no less complete than the methods
   provided herein.

   [will add the underscore notation text here]

3) Annotations will be clarified as to:
   - cannot be extended to mean else than number of bits for field 
   - if in conflict with other part of the specs, they are not to
     prevail over the spec
   - will look like this:
     > uncompressed_format  =   discriminator     [  8 ],
   
4) CRC encoding method a la -03 will be reinstated and will
   now have the following signature:

field   ::=   crc (num_bits, bit_pattern, initial_value, 
                   block_data_value, block_data_length)

5) Since I have the token, I will make a round of edits to
   clean up the document so that I make sure it looks like
   a specification.

In the meantime, we need to find a way to fix the packet formats, have Carsten (in)validate them and then move on to wglc.

Everyone savvy and in agreement with the above?
Great - at least this will have almost been useful.

Have a great weekend,

///Ghyslain

PS: The first ROHC wg draft describing a ROHC-TCP profile came out on November 17, 2000.

--
 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 14:33
> 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 )
> 
> 
> Comments below.
> 
> > ]
> > ]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 =)
> > 
> 
> 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)
> 
> > Thanks in advance
> > 
> > Raffles
> > 
> 

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