Subject: RE: [rohc] FN draft review

From: "Finking, Robert" <[email-masked]>
Date: Thu, 9 Nov 2006 13:51:49 -0000

Hi Ghyslain,

All looks good except for...

Thanks for tackling this - much appreciated =)

Raffles

> -----Original Message-----
> From: Ghyslain Pelletier (LU/EAB) 
> 
>    All identifiers may be of any length and may contain any 
> combination
>    of alphanumeric characters and underscores, within the restrictions
>    defined in this section.
> 
>    All identifiers must start with an alphabetic character.
> 
>    Identifiers are case-sensitive; however it is RECOMMENDED that
>    identifiers differ from each other by more than only their
>    capitalisation, and in particular within the same scope.
> 
>    All letters in identifiers for constants must be upper case.
> 
>    It is illegal to use any of the following as identifiers (using
>    alternative capitalisations in NOT RECOMMENDED):
> 
>    o  "false", "true"
>    o  "ENFORCE", "THIS", "VARIABLE"
>    o  "ULENGTH", "UVALUE"
>    o  "CLENGTH", "CVALUE"
>    o  "UNCOMPRESSED", "COMPRESSED", "CONTROL", "INITIAL" or "DEFAULT"
> 

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.

> >> 
> >> Section 4.5
> >> 
> >> * Can you do the reverse (i.e. separate compressed 
> representations)?
> > 
> > Yes of course - using the same mechanism. It's the same 
> thing. Or am I 
> > missing something? If you want the converse (combining several 
> > compressed fields into a single uncompressed one), that's very 
> > straightforward - you just split the field up into artificial 
> > subfields in the uncompressed header.
> > 
> > [Mark] I don't think you're missing something.  I was just checking 
> > that it would be /possible/ (ignoring whether or not it's remotely 
> > /desirable/) to take 12 compressed bits and split that field into 
> > (say) 8 + 4 disjoint bits.  Yes, it's probably silly.  No, I don't 
> > care if you can't do it.  I was just curious ;-)
> 
> I don't think it is possible to split the result of an 
> encoding method (the compressed bits).
> 
> I don't think that this is possible with grouping (if that 
> was the question). I think that we can leave with not having 
> it and relying on english defined methods for this, otherwise 
> it would be a mess to build that into the notation.

It is possible, but I won't bother going into it now as it's
academic!

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

---

From: "Ghyslain Pelletier \(LU/EAB\)" <[email-masked]>
Date: Thu, 9 Nov 2006 14:58:16 +0100

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

---

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

> I also see from Carsten's ABNF that he seems to be fine with the old

The way FN is defined in -11 it is

-- case-sensitive with an error if two distinct identifiers with the  
same case-insensitive interpretation turn up
-- case-insensitive with an error if two equivalent identifiers with  
different case-sensitive spelling turn up

Note that both are equivalent.  I was just suggesting to use the  
latter way of saying it.  But if this confuses people I can stick  
with the former.
I don't like RECOMMENDED (which is teethless in a language spec),  
which would mean that FN is now fully case-sensitive and processors  
have to cope with multiple identifiers with the same case-insensitive  
mapping.

Why is this even important?  Life if easier in certain target  
languages if an FN tool can just downcase/upcase all identifiers  
(depending on what the target language wants).  RECOMMENDED makes  
this impossible.

Gruesse, Carsten

---

From: "Ghyslain Pelletier \(LU/EAB\)" <[email-masked]>
Date: Thu, 9 Nov 2006 16:36:28 +0100

Carsten,

I was perfectly fine with the text from -11, which is what I have now
reverted too, and was the text I preferred too. This was agreed in a
previous mail today by the way.

I guess I misinterpreted what I thought was comments received by you and
Mark.

///Ghyslain

Carsten Bormann wrote:
> -- case-sensitive with an error if two distinct identifiers
> with the same case-insensitive interpretation turn up
> -- case-insensitive with an error if two equivalent
> identifiers with different case-sensitive spelling turn up
> 
> Note that both are equivalent.  I was just suggesting to use
> the latter way of saying it.  But if this confuses people I can stick
> with the former. I don't like RECOMMENDED (which is teethless in a
> language spec), which would mean that FN is now fully case-sensitive
> and processors have to cope with multiple identifiers with
> the same case-insensitive mapping.
> 
> languages if an FN tool can just downcase/upcase all
> identifiers (depending on what the target language wants).
> RECOMMENDED makes this impossible.
> 
> Gruesse, Carsten