Subject: RE: [rohc] FN draft review

From: "Finking, Robert" <[email-masked]>
Date: Thu, 9 Nov 2006 14:01:43 -0000

Great OK, we'll go with that then =)

> -----Original Message-----
> From: Ghyslain Pelletier (LU/EAB) 
> [mailto:[email-masked]] 
> Sent: Thursday, November 09, 2006 1:58 PM
> To: Finking, Robert; West, Mark
> Cc: [email-masked]
> Subject: RE: [rohc] FN draft review
> 
> 
> Finking, Robert wrote:
> 
> > 
> > I don't think we should weaken this to a recommendation. I 
> think Mark 
> > was just wanting an explicit line saying that the FN is case 
> > sensitive... however we already have that in the first paragraph of 
> > section 4.1: "ROHC-FN specifications are case sensitive", 
> so I don't 
> > think any addition is needed.
> > 
> 
> Ah, ok ... I thought we were trying to remove the "FN is 
> case-sensitive but not all the time" confusion?
> 
> For me, this is not a big deal one way or another, so I guess 
> I'll just revert back that particular text in section 4.2.
> 
> I also see from Carsten's ABNF that he seems to be fine with 
> the old text too.
> 
> ///Ghyslain
> 

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

---

From: "Finking, Robert" <[email-masked]>
Date: Thu, 9 Nov 2006 14:12:30 -0000

I mean I think it is fine as it is. Carsten's exceptions are:

>There also is no subscript, member selection via object name (but see
field
>attributes above), member selection via pointer, dereference, address
>of, type cast, sizeof, function call, ...

However most of these are not what you intuitively think of as
expressions and are implicitly unavailable. There is no "subscript"
operator for example since there are no arrays or other indexible data
structures, there is no "member selection via pointer",  "dereference"
or "address of" operator because the FN doesn't have any concept of
pointers or addresses etc. mentioning these things explicitly makes the
text more precise but harder to understand. This is the point of using
the word "generally" instead of "exactly" or some similar.

Anyhow, bottom line: I don't think it needs changing =)

Cheers

Raffles

> Sent: Thursday, November 09, 2006 2:02 PM
> I am not sure I understand your answer on that one!!!
> 
> 1) we leave the exceptions list in the draft
> 2) ??? should we complete it ??? with what ???
>    I haven't touched that section yet,
>    so I don't know what you mean by
>    "Carsten's examples are all addressed now"
> 
> ///Ghyslain
> 
> 
> Finking, Robert wrote:
> > I think that it gives the reader a good immediate feel for the way 
> > expressions work so should be left in. If I remember correctly 
> > Carsten's examples are all addressed now? If not, I think 
> it's close 
> > enough to be useful - once again broad brush to help reader 
> > understanding with detail given afterwards.
> > 
> > Cheers
> > 
> > Raffles
> > 
> >> Sent: Thursday, November 09, 2006 1:23 PM
> >> Some more thoughts inline ...
> >> 
> >> ///Ghyslain
> >> 
> >> Finking, Robert wrote:
> >> 
> >>>> 
> >>>> Section 4.7
> >>>> 
> >>>> * I can't believe that the list of exclusions is exhaustive? 
> >>>> However, this probably doesn't matter too much.
> >>> 
> >>> I believe it is complete, but if you find anything 
> missing, do feel 
> >>> free to shout up!
> >>> 
> >> 
> >> Carsten had the same comment, and listed a number of examples.
> >> 
> >> I have to admit that working by exclusion wrt to another 
> language is 
> >> not the best practice we've come up with. Either we think 
> that this 
> >> is not important, or we take another approach. I am not 
> sure this is 
> >> interesting to increase the list of exclusions.
> >> 
> >> Please provide a suggestion (I can't think of how to resolve this
> >> one)
> 
>

---

From: "Finking, Robert" <[email-masked]>
Date: Fri, 10 Nov 2006 09:15:41 -0000

Hi Carsten,

Thanks.

> Sign extension *can* be done in FN:
> 
> foo {
>    UNCOMPRESSED { fe [9]; fv[7]; }
>    COMPRESSED {fe[1]; fv =:= irregular(7);
>      ENFORCE(fe.UVALUE == fe.CVALUE * -1);
>    }
> }
> 
> (In contrast to the zero extended example, this does not actually  
> truncate in the compression direction.)

Bingo =) And more to the point you can do arbitrary things instead of
just "* -1", you might for example want to encode a 4 bit value that
ranges between -5 and 10. Of course you'd normally use a control field
to do this. Anyway, this is the underlying reason why I don't think this
needs changing - the default case is exactly what you want almost all
the time, and when you want something else you can notate it explicitly
(however weird and wonderful it is). Therefore I don't think we should
change this.

Regards

Raffles

---

From: "Finking, Robert" <[email-masked]>
Date: Fri, 10 Nov 2006 09:27:11 -0000

> From: Carsten Bormann [mailto:[email-masked]] 
> Sent: Thursday, November 09, 2006 5:06 PM
> 
> On Nov 09 2006, at 05:23, Ghyslain Pelletier ((LU/EAB)) wrote:
> 
> Just clarify that the exclusions given are examples, and that the  
> definitive list of what's in FN follows.
> (This is just an editorial fix, I think.)
> 

OK, sounds good!