Subject: [rohc] Updated FN Draft

From: "Finking, Robert" <[email-masked]>
Date: Fri, 18 Mar 2005 16:32:27 -0000

Hi All,
 
FYI I've just posted an updated version of the draft, taking into account
the bulk of the non-contended review comments from L-E, plus a few other
nits and bits which I spotted. Enjoy!
 
Regards
 
Raffles
_______________________________________________
Rohc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc

---

From: "Finking, Robert" <[email-masked]>
Date: Tue, 22 Mar 2005 15:47:13 -0000

Apologies, what I meant to say was:

All,

Here are the FN Draft issues left to resolve as I see it in rough order of
importance. Feel free to add any I've missed:

1. Let Statements syntax 

2. Let Statements description 

3. Appendix A (Formal Syntax Definition) should it stay or should it go (as
an aside, do we need formal syntax fragments in the normative part of the
draft, either instead of or as well as Appendix A)? 

4. (less important) Any feelings on the replacement for the (currently bad)
example in 3.2.2 i.e. should it be more of an example and less of a
prototype - or should we explicitly try to supply a prototype? My feeling is
that we should go for an example. Votes for "you're the editor it's your
problem" will be accepted.

Regards

Raffles

-----Original Message-----
From: Finking, Robert 
Sent: Friday, March 18, 2005 4:32 PM
To: [email-masked]
Subject: [rohc] Updated FN Draft

Hi All,

Regards

Raffles

---

From: "Ghyslain Pelletier \(LU/EAB\)" <[email-masked]>
Date: Tue, 22 Mar 2005 17:14:04 +0100

Hi Robert,

Thanks for the update!

Besides moving the "let" definition to the structure section,
what seems to be missing in terms of syntax and description?

Also, what seems to be bad about the example in 3.2.2 (besides
that it feels longer than necessary)?

Regarding the Appendixes, how outdated is their contents?
Personnally, I don't think that the appendix is needed
to understand the FN, but the question is why was it put
there from the beginning? I'd like to hear a clear purpose.

Also, both A and B seem to want to serve different purposes,
so we should address them separately when pondering their
future in the draft.

/Ghyslain

> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Finking, Robert
> Sent: den 22 mars 2005 16:47
> To: [email-masked]
> Subject: RE: [rohc] Updated FN Draft
> 
>

---

From: "Finking, Robert" <[email-masked]>
Date: Tue, 22 Mar 2005 16:51:35 -0000

Hi Ghyslain, All,

Thanks for the response. Answers below.

Good to hear from you.

Regards

Raffles

> From: Ghyslain Pelletier (LU/EAB) 
> 
> 
> Hi Robert,
> 
> Thanks for the update!
> 
The debate that arose was whether we should split the syntax in two, so that
we'd have two separate statements, "let" and "assert" (or some similar).

One would be used to do things like initialise the value of a control field
and would bind the expression given as its argument, the other would be used
as a conditional to decide which of several alternative encodings to use.
The argument Carsten has presented is that mathematically both of these
amount to the same thing, so why do we need two different reserved words
which do the same thing? L-E's argument is that conceptually (/intuitively?)
they're two different things and that it's confusing calling them the same
thing. I hope I've represented both sides OK there! L-E/Carsten please feel
free to chip in at this point to back up your respective sides.

> that it feels longer than necessary)?

It's confusing and hard to explain. It's almost a prototype, but not quite.
It would be better if we either treated it as a prototype - mainly this just
means modifying the surrounding text - or else make it into an example. One
of the main difficulties in explaining it is in the overloading of
identifiers within the example.

> there from the beginning? I'd like to hear a clear purpose.

The reason is that since the FN is formal, it needs defining formally.
Without a formal syntax definition it's not possible to determine exactly
what is legal notation and what isn't. More importantly it's needed to
define a unique parsing of a given piece of notation. I'm not talking about
tools here, but the actual meaning of the FN. If I write down 1 + 4 * 5,
because your brain knows how to parse maths expressions, you know this means
"multiply 4 by 5 and add 1 to the result" (21) rather than "add 1 to 4 and
multiply the result by 5". The same is true of the notation - without a set
of rules to parse it by it is not possible to nail down the meaning of a
profile. I guess I'm arguing that it's normative - so maybe we should have
syntax fragments associated with each subsection of section 4?

> so we should address them separately when pondering their

I thought we'd already reached consensus on Appendix B? Here's the thread of
discussion we had on it:

]> > - Appendix B: Is this appendix up-to-date? And should we 
]> > still keep it? The TCP profile is also an example, although 
]> > it is much more complicated. I do not have a clear opinion,
]> > what do others think?
]> 
]> Yes, it's up to date. At least it should be. 
]
]After re-reading the draft again, including appendix B, I agree
]it seems to be fully up-to-date, and it is indeed very useful. 

If you have anything else to add though, please feel free =)

---

From: "Lars-Erik Jonsson \(LU/EAB\)" <[email-masked]>
Date: Wed, 23 Mar 2005 11:17:38 +0100

Robert,
 
Thanks for the update, I've looked through it again and only noticed the following few things
that you should look at again, in addition to the more critical issues you listed in you mail
from yesterday, which we will have to resolve together.
 
* Last sentence of 4.7, remove either "section" or "Section".
 
* I'm still not happy with the first sentence of the definition of the word "Field", as I do not
  think "ROHC-FN" does anything by itself. Can we rephrase the first sentence as:
  "With ROHC-FN, the protocol header to be compressed is divided into..."
 
* The last paragraph of section 3.2.2 is still "missing".
 
/L-E

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Finking, Robert
Sent: den 18 mars 2005 17:32
To: [email-masked]
Subject: [rohc] Updated FN Draft

Hi All,
 
FYI I've just posted an updated version of the draft, taking into account the bulk of the non-contended review comments from L-E, plus a few other nits and bits which I spotted. Enjoy!
 
Regards
 
Raffles

---

From: "Finking, Robert" <[email-masked]>
Date: Wed, 23 Mar 2005 10:57:05 -0000

Hi L-E, ROHCers,

These all look non contentious (please shout up people if you disagree), so
I've just gone ahead and done them. I spotted another occurrence of "section
Section" as a result, so thanks for pointing that out!

On the last paragraph of 3.2.2 I've just deleted it and slightly modified
text earlier on in the section to make sure it covers it, and spotted
another error in the document text in the process! (mixed up "field order
list" and "field encodings list"). Sometimes you wonder how many times
you've looked at something without realising it was wrong!

Thanks again everybody for your continued support.

Raffles

> From: Lars-Erik Jonsson (LU/EAB) 
> [mailto:[email-masked]] 
> Sent: Wednesday, March 23, 2005 10:18 AM
> To: Finking, Robert; [email-masked]
> * I'm still not happy with the first sentence of the 
> definition of the word "Field", as I do not
> FYI I've just posted an updated version of the draft, taking 
> into account the bulk of the non-contended review comments 
> from L-E, plus a few other nits and bits which I spotted. Enjoy!
> 
> Regards
> 
> Raffles
>

---

From: "Ghyslain Pelletier \(LU/EAB\)" <[email-masked]>
Date: Wed, 23 Mar 2005 12:29:16 +0100

Thanks Robert,

I think that Appendix B should be kept.

I also agree with you that Appendix A should also be kept,
and I think that for convenience it can stay as an appendix
and does not need to be fragmented and moved to every
subsection in section 4.

Regarding the let statement, I completely agree with
Carsten's position and I disagree with Lars-Erik's view.

The reason is that if I take L-E's argument and define
an "if" and an "assert", I still need to create a reversible
binding so that a statement remain meaningful at both
compressor and decompressor, so the "if" and "assert" would
anyway end up meaning the same thing as today's "let" - we'd
just end up with two keywords doing the same thing althought
their name and use could reflect the conceptual differences
that L-E mentions.

So, I'd definitely vote to keep the meaning of let as it is
defined today. I think it is useful and correct.

/Ghyslain

> Sent: den 22 mars 2005 17:52
> To: [email-masked]