Subject: RE: [rohc] ROHC FN review

From: "Finking, Robert" <[email-masked]>
Date: Wed, 8 Nov 2006 15:58:30 -0000

Hi,

inline =)

Raffles

> -----Original Message-----
> From: Ghyslain Pelletier (LU/EAB) 
> Carsten Bormann wrote:
> 
> > On Nov 08 2006, at 00:25, Finking, Robert wrote:
> 
> > -- (re Mark on section 4.2:) Would it be better to say FN 
> identifiers 
> > are "case insensitive"?
> >     We could add "it is an error if multiple case spellings of the 
> > same case insensitive identifier occur in an FN specification.  For 
> > the purposes of this rule, all reserved words and 
> identifiers (e.g., 
> > encoding method names) defined in this specification are assumed to 
> > have occurred in the case spelling given here.".
> 
> Irrespective the question about having an ABNF definition of 
> the FN in an appendix or not, my understanding is that the 
> intent of the current text is the following:
> 
> - FN is case sensitive
> - for identifiers, I think we only want to state that one should not
>   have identifiers that differ from each other only in capitalization.
> 
> Robert can correct me if I am wrong here, but I think that it 
> is the usage of the word "illegal" that is unfortunate here, 
> I don't think that there is any compelling need to make an 
> exception for identifiers or for reserved words. Otherwise, 
> if there is a compelling reason to have this exception, than 
> I think that Carsten's proposed text above seems right.

Regarding the suggestions from Carsten, I had looked at this the
other way around but I think the end result
is the same. Personally I find it odd to consider something as case
insensitive and then make stipulations about its case, but I
understand the meaning. I would rather it be framed in the terms
currently used, that it is case sensitive and that alternative
capitalisations are forbidden, including alternative capitalisations
of reserved words etc.

> 
>  
> > -- We currently don't have operators for binary (bitwise) and, or, 
> > xor, negate (&, |, ^, ~ in C).  As HC is often about bit 
> fiddling, I 
> > find this somewhat surprising (but then we didn't need it for the
> > ROHCv2 profiles).  We would need to find a new name for ^, as
> > we took this for exponentiation.  Also, << and >> are missing
> > from C (but less essential). (My ABNF has placeholders for
> > these; see the ABNF
> > comments.)
> 
> Again, irrespective of the ABNF question ...
> 
> We did not include binary operators because there are not 
> needed (and I cannot see that they would) but more 
> importantly my understanding is that these are not reversible 
> and thus are not suited for the notation. If you think 
> otherwise please explain how those fit in the FN.

Yes, well summarised - the only binary bitwise op which is
reversible is XOR. We did briefly consider including that
but decided against having a single bitwise operator since
it is not needed.

Thanks for all the work you're putting in at the mo =)

Raffles

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

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 9 Nov 2006 07:29:03 -0800

> but decided against having a single bitwise operator since

While this observation is true for the bitwise operators, we have  
lots of non-reversible operators in other places already.

What's the difference between

     ENFORCE(residue_field.UVALUE == (unscaled_value % stride_value));

and

     ENFORCE(residue_field.UVALUE == (unscaled_value & (stride_value  
- 1)));

?

(Similarly, we today use / for shifts.)

Gruesse, Carsten