Subject: [rohc] ROHC FN - moving forward

From: "Ghyslain Pelletier \(LU/EAB\)" <[email-masked]>
Date: Mon, 13 Nov 2006 14:20:43 +0100

Carsten, Robert,

Trying to catch up on recent mails ... Let me know if I've missed
something, or if I am not reflecting the correct consensus.

I'm trying here to make a complete list of what's left to do and a
proposed way forward, alternatively a question or two ...

Then I'll make another update/check to the draft, and then see with
Lars-Erik how we should proceed. 

///Ghyslain

Issue #1: ABNF in RoHC-FN
===================================================================
First, I'd like to state that my personal opinion on this issue is
exactly the same as Robert's as expressed in
http://www1.ietf.org/mail-archive/web/rohc/current/msg04692.html

My main concern is the amount of work/review that this requires and
the impact of this requiring a third wglc for this draft.

What I've seen so far on the list:

ARGUMENTS FOR:
o the formal syntax using the ABNF description is useful.
o a normative appendix is probably the only proper alternative
o it verifies for existing FN specs (TCP/RoHCv2)

ARGUMENTS AGAINST:
o it is not _necessary_ for the specs to be complete
o it needs to be reviewed and verified
o it will likely delay publication
o it sure does not help avoiding another wglc

I think that the consensus I'm seeing is to have the formal syntax in a
normative appendix. HOWEVER, if this appendix cannot be completed and
verified quickly, or if it brings new issues related to the ABNF
description itself (and thus not FN) than I think it should be dropped
from the specs.

I will make a review of the formal syntax as quickly as I can.
(I hope that Robert and Mark can do the same?)

Issue #2: Names for UNCOMPRESSED and COMPRESSED formats without ID
===================================================================
The argument against the "empty" ID relates to tools that would use
FN, otherwise this is not an issue spec-wise.
My understanding is that the consensus is to keep the "empty" ID,
thus no change to the draft. In addition, we have no requirement
to entertain tools that would use FN.

Issue #3: Completeness of the list of exclusions wrt C90
===================================================================
The resolution is to simply clarify that the exclusions given are
examples, and that the definitive list of what's in FN follows.
As a simple editorial fix.

Issue #4: Binary operators
===================================================================
Binary operators are not needed and not reversible (except XOR).
No change needed here.

Other issues
====================================================================

> I assume we did decide to fix the "8_bit" etc. identifiers in TCP-12,
not in FN.

Correct.

> I'm not sure I have an answer to my comment on 4.12.3.2.

Your question is:

> A format only fails if it fails to define one of the
> compressed attributes of one of the fields in the compressed format.
>
> Why is that a failure?

Well, I am actually quite certain that I will miss the point of your
question here ... the format fails if it fails to define either CLENGTH
or CVALUE for a field; this means that the encoding method for the field
fails to compress the field as it can't make the binding(s). How could
the format succeed in that case?

I don't see how this text is not correct, so right now it should be left
untouched. Please explain more where you want to get at otherwise.

My ToDos:
--------------------------------------------------------------------
o Verify formal syntax in appendix, normative
o Change the reference to RFC4234 to normative
o Fix the intro of 4.7. Clarify that the exclusions given are
  examples, and that the definitive list of what's in FN follows.
 Make it clear that this is C90 expressions we're talking about
o s/"perfectly allowable"/<something else>/
o fix the contributors section.

... and then I hope we can all agree that this is it.

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

---

From: "Finking, Robert" <[email-masked]>
Date: Mon, 13 Nov 2006 13:30:37 -0000

Hi Ghyslain,

This all looks good to me - thanks for tying all these bits together.

I have some stuff that I need to do at the start of this week, but
should be finished by Wednesdayish - then I intend to reread the draft.
Hope this is soon enough!

Cheers

Raffles

> -----Original Message-----
> From: Ghyslain Pelletier (LU/EAB) 
> [mailto:[email-masked]] 
> Sent: Monday, November 13, 2006 1:21 PM
> To: Finking, Robert; Carsten Bormann
> Cc: [email-masked]
> Subject: ROHC FN - moving forward
> 
> 
> Carsten, Robert,
> 
> Trying to catch up on recent mails ... Let me know if I've 
> missed something, or if I am not reflecting the correct consensus.
> 
> I'm trying here to make a complete list of what's left to do 
> and a proposed way forward, alternatively a question or two ...
> 
> Then I'll make another update/check to the draft, and then 
> see with Lars-Erik how we should proceed. 
> 
> ///Ghyslain
> 
> First, I'd like to state that my personal opinion on this 
> issue is exactly the same as Robert's as expressed in 
> My main concern is the amount of work/review that this 
> requires and the impact of this requiring a third wglc for this draft.
> 
> o a normative appendix is probably the only proper 
> alternative o it verifies for existing FN specs (TCP/RoHCv2)
> 
> ARGUMENTS AGAINST:
> I think that the consensus I'm seeing is to have the formal 
> syntax in a normative appendix. HOWEVER, if this appendix 
> cannot be completed and verified quickly, or if it brings new 
> issues related to the ABNF description itself (and thus not 
> FN) than I think it should be dropped from the specs.
> 
> I will make a review of the formal syntax as quickly as I 
> can. (I hope that Robert and Mark can do the same?)
> 
> The argument against the "empty" ID relates to tools that 
> would use FN, otherwise this is not an issue spec-wise. My 
> understanding is that the consensus is to keep the "empty" 
> ID, thus no change to the draft. In addition, we have no 
> requirement to entertain tools that would use FN.
> 
> The resolution is to simply clarify that the exclusions given 
> are examples, and that the definitive list of what's in FN 
> follows. As a simple editorial fix.
> 
> Binary operators are not needed and not reversible (except 
> XOR). No change needed here.
> 
> Other issues 
> > A format only fails if it fails to define one of the compressed 
> > attributes of one of the fields in the compressed format.
> >
> > Why is that a failure?
> 
> Well, I am actually quite certain that I will miss the point 
> of your question here ... the format fails if it fails to 
> define either CLENGTH or CVALUE for a field; this means that 
> the encoding method for the field fails to compress the field 
> as it can't make the binding(s). How could the format succeed 
> in that case?
> 
> I don't see how this text is not correct, so right now it 
> should be left untouched. Please explain more where you want 
> to get at otherwise.
> 
> My ToDos:
>   examples, and that the definitive list of what's in FN 
> follows.  Make it clear that this is C90 expressions we're 
> talking about o s/"perfectly allowable"/<something else>/ o 
> fix the contributors section.
>