Subject: RE: [rohc] FN I-D WGLC proposed way forward

From: "Finking, Robert" <[email-masked]>
Date: Thu, 17 Nov 2005 11:05:31 -0000

Hi Everybody,
 
I've had a thought that would allow us to accommodate another of Joe's
requests: to separate out some keywords from uc_format_blah and
co_format_blah. Joes original suggestion was to have dedicated sections
something like this:
 
uncompressed:
     blah = ...
 
compressed:
     blah = ...
 
Instead of marking out sections like this, we could make a much simpler
change and have "compressed" and "uncompressed" keywords for each
format:
 
   uncompressed blah = ...
 
   compressed   blah = ...
 
This would be easily achievable by doing a search and replace, and would
still allow us to use Carsten/Eilert's checking tool provided there was
a simple pre-processor to convert the input back to the original form,
which the tool understands.
 
What do you think?
 
I'd be happy to do the pre-processor.
 
Raffles
 
PS if you're looking for a precedent, the obvious analog here is the
difference between the way Java/C# and C++ specify the privacy of class
members.

	-----Original Message-----
	From: [email-masked] [mailto:[email-masked]] On
Behalf Of Finking, Robert
	Sent: Friday, October 21, 2005 12:57 PM
	To: [email-masked]
	Cc: Joe Touch
	Subject: [rohc] FN I-D WGLC proposed way forward

	Hi Guys,

	Based on the discussions we had with Joe on the list, here's
what the authors are proposing for updates to the FN draft. The main
theme is to reassess the draft from a point of view of readability of
somebody like Joe and make as many improvements to the accessibility of
the draft as possible. In particular:

	1. Spell out the importance of understanding what fields, values
and encoding methods are, and the relationship between them. Make their
role clear and explicit at each point where they're used, instead of
assuming that the reader has fully understood their relationship
already.

	2. Add a note that the zero IP-ID is "observed" behavior, and
that for header compression the choice of the behavior to assume is
entirely up to the profile designer - i.e. it can handle non standard
behaviour... but make it clear that Zero IP-IDs are actually illegal
from the IETF's point of view.

	3. Put into relation the FN and the principles used for
achieving robustness against losses and reordering, mention reordering
as a possibility in the draft (currently no mention of reordering at
all). But make it clear that the FN only defines packet formats, i.e.
bits on the wire, and anything else related to robustness and tolerance
to reordering is outside the scope of FN.

	4. We need to include something about the comments which
indicate the field widths in bits. We clearly don't want another huge
debate about this, but Joe is right that these are a very important part
of the notation, in that they tell you what the field widths are -
without them it's non-trivial to gather this important information. This
means either making the current style of comments a part of the FN, or
else reverting to them not being comments - either way we do need to
describe them in the draft. If we take the "not comments" approach, my
suggestion is that a search and replace (or failing that a quick python
script) can auto-convert them to the new syntax. A key issue here is
that they must be annotations, not mandatory since some fields have
undefined length and we don't have the resources to handle that right
now! If we can produce a FN-to-boxNotation compiler though this problem
may go away, but we can't count on that right now!

	5. Consider changing the "::=" operator, due to it's use in BNF
and the confusion that can cause. Again, whatever replacement we come up
with (e.g "encoded") can be fixed in the current drafts by use of global
search and replace.

	6. It would be great if Carsten/Eilert could update the tool to
deal with any syntax changes and/or to meet Joe's request that it "would
be nice if the current notation could be 'compiled' into the layout
diagrams" (i.e. ASCII box notation).

	7. Need to be explicit about the 1:1 mapping between compressed
and uncompressed messages and describe that defining the handling of
blanks to produce a many:1 mapping is beyond the scope of the FN.

	8. In the body of the draft in the let statement section, need
to state that it is possible to make any field conditional.

	9. Need to address whether the ROHC group is happy to have a
name change for things like "static" from their historical names to more
accurate, easy to read ones, if so need to gather suggestions for the
counter-intuitive ones - suggestions please (e.g. "unchanged" instead of
"static").

	10. Clarify "7-bit ASCII", indicate whether 'alphabetic' is case
sensitive or not.

	11. Add explicit text about language not being like C and the
implications of that

	12. Make it explicit in the draft that uncompressed field
lengths are almost exclusively constrained by the encoding method used
to encode them. The only other way is to specify the length using a let
statement.

	13. Consider changing "let" to "bind". The problem with "let" is
that the reader thinks they know what it means, when in reality they
don't. They certainly don't expect that it could mean "if" sometimes.

	14. Clarify in A.5 that the example protocol contains a version
number

	15. Make it illegal to specify two ambiguous packet formats.

	16. revisit all examples to see if they can be made clearer. In
particular do we really need an example to show the exception to the
rule, rather than to show the norm?

	17. Clarify 4.9.4.2

	18. Change "log2" to "bitsize"

	19. Try to remove the similarity between the names
"uncomp_value" and "uncompressed_value"

	20. Give the author/reader the option of specifying the
polynomial as "x^7+x^4+x^3" (but don't use this in the TCP I-D) - Joe
can you clarify this, we authors are struggling to see why the above is
any different from setting bits 7, 4 and 3?

	Thanks again to Joe for taking the time to review the draft and
for the many interesting points he raised and also to the authors for
helping to arrive at the above list.

	Cheers

	Raffles

	Robert Finking (01794 833189)
	Roke Manor Research (http://www.roke.co.uk
<http://www.roke.co.uk/> )
	Romsey, Hampshire SO51 0ZN

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

---

From: "Finking, Robert" <[email-masked]>
Date: Thu, 24 Nov 2005 10:06:03 -0000

Hi Again,

OK here's a revised proposal. Please somebody respond to this so that I
can proceed with this (or some revision of it)! Note that all of the
below are syntax changes, there is no change proposed to the way the FN
actually works here.

One problem with the scheme I originally suggested is what to do about
control_fields and default_methods. If they become keywords, then you
have

    <keyword> = ...

Which looks kind of strange (assignment to keyword). "default_methods"
doesn't have a field order list, so we could just drop the equals sign
to get

    default_methods
    {
        blah;
    }

"control_fields" does have a field order list, but the ordering
information is irrelevant (in fact the draft states so), so we could get
rid of it, along with the "=", and use the same syntax as for
default_methods.

This approach would also nail down something which we've never
specified, which is how many control_fields blocks are you allowed -
this makes sure it's restricted to 1.

A couple of other things which Joe mentioned
1. he didn't like the case sensitivity - I'm happy  to drop the case
sensitivity if everybody else is.
2. how about a convention of capitalising reserved words so that they
stand out (in line with Joe's original suggestion

>               i.e., why use co_format as a prefix, rather than
>               say:
>
>                       header === {
>                               <base format>
>                               COMPRESSED
>                               cf1 = ...
>                               cf2 = ...
>                       }
).

Since UNCOMP_VALUE is a reserved word, this also solves:

>19. Try to remove the similarity between the names "uncomp_value" and
>"uncompressed_value"

One final issue with this approach - I don't know about you, but having
keywords with underscores doesn't sit well with me, so I've shortened
them to single words where possible:

uncomp_value      -> UVALUE
uncomp_length     -> ULENGTH
uncomp_hdr_start  -> USTART
comp_value        -> CVALUE
comp_length       -> CLENGTH
comp_hdr_start    -> CSTART

Taking all the above into account, we'd have FN that looks like this
(comments please):

   eg_header  ===
   {
     UNCOMPRESSED uc = version_no,    %[ 2 ]
                       type,          %[ 2 ]
                       flow_id,       %[ 4 ]
                       sequence_no,   %[ 4 ]
                       abc_flag_bits, %[ 3 ]
                       reserved_flag; %[ 1 ]

     CONTROL
     {
       % need modulo maths to calculate scaling correctly,
       % due to 4 bit wrap around
       BIND(scaled_seq_no:UVALUE
              == ((MOD(15 - sequence_no:UVALUE, 3) * 16
                   + sequence_no:UVALUE) / 3));
     };

     DEFAULT
     {
       version_no          ::=   uncompressed_value(2,1);
       type                ::=   irregular(2);
       flow_id             ::=   static;
       reserved_flag       ::=   uncompressed_value(1,0);
       scaled_seq_no       ::=   lsb(1,-1);
     };

     COMPRESSED irregular  =   discriminator,     %[ 2 ]
                               type,              %[ 2 ]
                               flow_id,           %[ 4 ]
                               scaled_seq_no,     %[ 4 ]
                               abc_flag_bits      %[ 3 ]
     {
       discriminator       ::=   '00';
       flow_id             ::=   irregular(4);  % overrides default
       scaled_seq_no       ::=   irregular(4);  % overrides default
       abc_flag_bits       ::=   irregular(3);
     };

     COMPRESSED flags_set  =   discriminator,     %[ 2 ]
                               type,              %[ 2 ]
                               scaled_seq_no      %[ 1 ]
     {
       discriminator       ::=   '01';
       abc_flag_bits       ::=   uncompressed_value(3,7);
     };

     COMPRESSED flags_static  =   discriminator,     %[ 1 ]
                                  type,              %[ 2 ]
                                  scaled_seq_no      %[ 1 ]
     {
       discriminator       ::=   '1';
       abc_flag_bits       ::=   static;
     };
   };

Regards

Raffles

-----Original Message-----
From: Finking, Robert
Sent: Thursday, November 17, 2005 11:06 AM
To: Finking, Robert; [email-masked]
Cc: Joe Touch; West, Mark
Subject: RE: [rohc] FN I-D WGLC proposed way forward

Hi Everybody,

uncompressed:
     blah = ...

compressed:
     blah = ...

   uncompressed blah = ...

   compressed   blah = ...

What do you think?

Raffles

PS if you're looking for a precedent, the obvious analogy here is the
difference between the way Java/C# and C++ specify the privacy of class
members.
-----Original Message-----
From: [email-masked] [mailto:[email-masked]
<mailto:[email-masked]> ] On Behalf Of Finking, Robert
Sent: Friday, October 21, 2005 12:57 PM
To: [email-masked]
Cc: Joe Touch
Subject: [rohc] FN I-D WGLC proposed way forward

Hi Guys,
Based on the discussions we had with Joe on the list, here's what the
authors are proposing for updates to the FN draft. The main theme is to
reassess the draft from a point of view of readability of somebody like
Joe and make as many improvements to the accessibility of the draft as
possible. In particular:
1. Spell out the importance of understanding what fields, values and
encoding methods are, and the relationship between them. Make their role
clear and explicit at each point where they're used, instead of assuming
that the reader has fully understood their relationship already.
2. Add a note that the zero IP-ID is "observed" behavior, and that for
header compression the choice of the behavior to assume is entirely up
to the profile designer - i.e. it can handle non standard behaviour...
but make it clear that Zero IP-IDs are actually illegal from the IETF's
point of view.
3. Put into relation the FN and the principles used for achieving
robustness against losses and reordering, mention reordering as a
possibility in the draft (currently no mention of reordering at all).
But make it clear that the FN only defines packet formats, i.e. bits on
the wire, and anything else related to robustness and tolerance to
reordering is outside the scope of FN.
4. We need to include something about the comments which indicate the
field widths in bits. We clearly don't want another huge debate about
this, but Joe is right that these are a very important part of the
notation, in that they tell you what the field widths are - without them
it's non-trivial to gather this important information. This means either
making the current style of comments a part of the FN, or else reverting
to them not being comments - either way we do need to describe them in
the draft. If we take the "not comments" approach, my suggestion is that
a search and replace (or failing that a quick python script) can
auto-convert them to the new syntax. A key issue here is that they must
be annotations, not mandatory since some fields have undefined length
and we don't have the resources to handle that right now! If we can
produce a FN-to-box Notation compiler though this problem may go away,
but we can't count on that right now!
5. Consider changing the "::=" operator, due to it's use in BNF and the
confusion that can cause. Again, whatever replacement we come up with
(e.g "encoded") can be fixed in the current drafts by use of global
search and replace.
6. It would be great if Carsten/Eilert could update the tool to deal
with any syntax changes and/or to meet Joe's request that it "would be
nice if the current notation could be 'compiled' into the layout
diagrams" (i.e. ASCII box notation).
7. Need to be explicit about the 1:1 mapping between compressed and
uncompressed messages and describe that defining the handling of blanks
to produce a many:1 mapping is beyond the scope of the FN.
8. In the body of the draft in the let statement section, need to state
that it is possible to make any field conditional.
9. Need to address whether the ROHC group is happy to have a name change
for things like "static" from their historical names to more accurate,
easy to read ones, if so need to gather suggestions for the
counter-intuitive ones - suggestions please (e.g. "unchanged" instead of
"static").
10. Clarify "7-bit ASCII", indicate whether 'alphabetic' is case
sensitive or not.
11. Add explicit text about language not being like C and the
implications of that
12. Make it explicit in the draft that uncompressed field lengths are
almost exclusively constrained by the encoding method used to encode
them. The only other way is to specify the length using a let statement.
13. Consider changing "let" to "bind". The problem with "let" is that
the reader thinks they know what it means, when in reality they don't.
They certainly don't expect that it could mean "if" sometimes.
14. Clarify in A.5 that the example protocol contains a version number
15. Make it illegal to specify two ambiguous packet formats.
16. revisit all examples to see if they can be made clearer. In
particular do we really need an example to show the exception to the
rule, rather than to show the norm?
17. Clarify 4.9.4.2
18. Change "log2" to "bitsize"
19. Try to remove the similarity between the names "uncomp_value" and
"uncompressed_value"
20. Give the author/reader the option of specifying the polynomial as
"x^7+x^4+x^3" (but don't use this in the TCP I-D) - Joe can you clarify
this, we authors are struggling to see why the above is any different
from setting bits 7, 4 and 3?
Thanks again to Joe for taking the time to review the draft and for the
many interesting points he raised and also to the authors for helping to
arrive at the above list.
Cheers
Raffles
Robert Finking (01794 833189)
Roke Manor Research (http://www.roke.co.uk <http://www.roke.co.uk> )
Romsey, Hampshire SO51 0ZN

---

From: "Kristofer Sandlund (LU/EAB)" <[email-masked]>
Date: Thu, 24 Nov 2005 13:23:18 +0100

Hi Raffles,

I think the suggested changes are good for improving the clarity
of the FN, so I'm all for it (even if it means I'll have to
M-x query-replace the TCP draft).

Regarding case sensitivity, I guess it could be ok with disallowing
upper-case letters in "non-reserved" names, but on the other hand,
This is a feature that I just realized that I want to use in ROHC-TCP
for names that are not reserved at FN level, but would be reserved
within the profile (e.g. the _dynamic suffix, I'd like to
change to _DYNAMIC within the TCP profile, but I don't want to 
reserve that name in the notation itself, since it is a local thing).

So, I think I have to case a weak vote for keeping case-sensitivity,
but otherwise I fully support your proposal, which is clearly
an improvement over the ambiguous naming schemes we have now.

BR,
	Kristofer

[email-masked] <mailto:[email-masked]> wrote:

> Hi Again,
> 
> OK here's a revised proposal. Please somebody respond to this
> so that I can proceed with this (or some revision of it)!
> Note that all of the below are syntax changes, there is no
> change proposed to the way the FN actually works here.
> 
> One problem with the scheme I originally suggested is what to
> do about control_fields and default_methods. If they become
> keywords, then you have
> 
>     <keyword> = ...
> 
> Which looks kind of strange (assignment to keyword).
> "default_methods" doesn't have a field order list, so we
> could just drop the equals sign to get
> 
>     default_methods
>     {
>         blah;
>     }
> 
> "control_fields" does have a field order list, but the
> ordering information is irrelevant (in fact the draft states
> so), so we could get rid of it, along with the "=", and use
> the same syntax as for default_methods.
> 
> This approach would also nail down something which we've
> never specified, which is how many control_fields blocks are
> you allowed - this makes sure it's restricted to 1.
> 
> 1. he didn't like the case sensitivity - I'm happy  to drop
> the case sensitivity if everybody else is.
> 2. how about a convention of capitalising reserved words so
> that they stand out (in line with Joe's original suggestion
> 
> "uncomp_value" and >"uncompressed_value"
> 
> One final issue with this approach - I don't know about you,
> but having keywords with underscores doesn't sit well with
> me, so I've shortened them to single words where possible:
> 
> uncomp_value      -> UVALUE
> uncomp_length     -> ULENGTH
> Taking all the above into account, we'd have FN that looks
> like this (comments please):
> 
> 
>    eg_header  ===
>    {
>                                abc_flag_bits      %[ 3 ]      {
>                                scaled_seq_no      %[ 1 ]      {
>        abc_flag_bits       ::=   uncompressed_value(3,7);      };
> 
>                                   scaled_seq_no      %[ 1 ]      {
> I've had a thought that would allow us to accommodate another
> of Joe's requests: to separate out some keywords from
> uc_format_blah and co_format_blah. Joes original suggestion
> was to have dedicated sections something like this:
> 
> uncompressed:
>      blah = ...
> 
> compressed:
>      blah = ...
> 
> Instead of marking out sections like this, we could make a
> much simpler change and have "compressed" and "uncompressed"
> keywords for each format:
> 
>    uncompressed blah = ...
> 
>    compressed   blah = ...
> 
> This would be easily achievable by doing a search and
> replace, and would still allow us to use Carsten/Eilert's
> checking tool provided there was a simple pre-processor to
> convert the input back to the original form, which the tool
> understands. 
> 
> What do you think?
> 
> PS if you're looking for a precedent, the obvious analogy
> here is the difference between the way Java/C# and C++
> specify the privacy of class members.
> what the authors are proposing for updates to the FN draft.
> The main theme is to reassess the draft from a point of view
> of readability of somebody like Joe and make as many
> improvements to the accessibility of the draft as possible.
> In particular:
> 1. Spell out the importance of understanding what fields,
> values and encoding methods are, and the relationship between
> them. Make their role clear and explicit at each point where
> they're used, instead of assuming that the reader has fully
> understood their relationship already.
> that for header compression the choice of the behavior to
> assume is entirely up to the profile designer - i.e. it can
> handle non standard behaviour... but make it clear that Zero
> IP-IDs are actually illegal from the IETF's point of view.
> achieving robustness against losses and reordering, mention
> reordering as a possibility in the draft (currently no
> mention of reordering at all). But make it clear that the FN
> only defines packet formats, i.e. bits on the wire, and
> anything else related to robustness and tolerance to
> indicate the field widths in bits. We clearly don't want
> another huge debate about this, but Joe is right that these
> are a very important part of the notation, in that they tell
> you what the field widths are - without them it's non-trivial
> to gather this important information. This means either
> making the current style of comments a part of the FN, or
> else reverting to them not being comments - either way we do
> need to describe them in the draft. If we take the "not
> comments" approach, my suggestion is that a search and
> replace (or failing that a quick python script) can
> auto-convert them to the new syntax. A key issue here is that
> they must be annotations, not mandatory since some fields
> have undefined length and we don't have the resources to
> handle that right now! If we can produce a FN-to-box Notation
> compiler though this problem may go away, but we can't count
> on that right now!
> 5. Consider changing the "::=" operator, due to it's use in
> BNF and the confusion that can cause. Again, whatever
> replacement we come up with (e.g "encoded") can be fixed in
> the current drafts by use of global search and replace.
> 6. It would be great if Carsten/Eilert could update the tool
> to deal with any syntax changes and/or to meet Joe's request
> that it "would be nice if the current notation could be
> 'compiled' into the layout diagrams" (i.e. ASCII box notation).
> 7. Need to be explicit about the 1:1 mapping between
> compressed and uncompressed messages and describe that
> defining the handling of blanks to produce a many:1 mapping
> is beyond the scope of the FN.
> 8. In the body of the draft in the let statement section,
> need to state that it is possible to make any field conditional.
> name change for things like "static" from their historical
> names to more accurate, easy to read ones, if so need to
> gather suggestions for the counter-intuitive ones -
> suggestions please (e.g. "unchanged" instead of "static").
> 10. Clarify "7-bit ASCII", indicate whether 'alphabetic' is
> case sensitive or not.
> lengths are almost exclusively constrained by the encoding
> method used to encode them. The only other way is to specify
> the length using a let statement.
> 13. Consider changing "let" to "bind". The problem with "let"
> is that the reader thinks they know what it means, when in
> reality they don't. They certainly don't expect that it could
> mean "if" sometimes.
> 16. revisit all examples to see if they can be made clearer.
> In particular do we really need an example to show the
> exception to the rule, rather than to show the norm?
> 17. Clarify 4.9.4.2
> polynomial as "x^7+x^4+x^3" (but don't use this in the TCP
> I-D) - Joe can you clarify this, we authors are struggling to
> see why the above is any different from setting bits 7, 4 and 3?
> Thanks again to Joe for taking the time to review the draft
> and for the many interesting points he raised and also to the
> authors for helping to arrive at the above list.
> Cheers
> Raffles

---

From: "Finking, Robert" <[email-masked]>
Date: Thu, 24 Nov 2005 13:18:08 -0000

Hi Kris,

Many thanks for the rapid response - much appreciated =) On the case
issue, I don't quite understand. The suggestion was to allow any
capitalisation anywhere in the FN. This would allow you to do what you
suggested below.

At present, the _DYNAMIC suffix that you want to use would be illegal.
Currently capitals are for constants, lower case for everything else
(actually I don't think the current draft spells it out quite like that,
but that's what's intended).
What I'm proposing is that we lift that restriction and make the FN
insensitive to capitalisation. However I'm also suggesting that we adopt
a *convention* (non-normative) which makes keywords all capitals:

>   O  "BIND", "THIS"
>   O  "MOD", "LOG2"
>   O  "DEFAULT", "CONTROL"
>   O  "USTART", "ULENGTH", "UVALUE"
>   O  "CSTART", "CLENGTH", "CVALUE"

This means you *could* write FN with what ever capitalisation you wanted
to, e.g. like this, but it wouldn't be conventional:

   eG_hEADeR  ===
   {
     UncOmpResSed uC = VeRSiON_NO,    %[ 2 ]
                       tYpE,          %[ 2 ]
        :
     cOMpREsSEd iRreGular  =   dISCriminaTor,     %[ 2 ]
                               TypE,              %[ 2 ]

etc. Note that "type" has different capitalisations in the compressed
and uncompressed formats, but both still refer to the same field.

Hopefully this gives you the freedom you want whilst still providing an
easily readable capitalisation convention.

Does that make sense? Do we have a vote in favour?

Regards

Raffles

> From: Kristofer Sandlund (LU/EAB) 
> [mailto:[email-masked]] 
> Sent: Thursday, November 24, 2005 12:23 PM
> To: Finking, Robert; [email-masked]; Ghyslain Pelletier (LU/EAB)
> Cc: West, Mark; Ford, Alan; Joe Touch
> I think the suggested changes are good for improving the 
> clarity of the FN, so I'm all for it (even if it means I'll 
> have to M-x query-replace the TCP draft).
> 
> Regarding case sensitivity, I guess it could be ok with 
> disallowing upper-case letters in "non-reserved" names, but 
> on the other hand, This is a feature that I just realized 
> that I want to use in ROHC-TCP for names that are not 
> reserved at FN level, but would be reserved within the 
> profile (e.g. the _dynamic suffix, I'd like to change to 
> _DYNAMIC within the TCP profile, but I don't want to 
> So, I think I have to case a weak vote for keeping 
> case-sensitivity, but otherwise I fully support your 
> proposal, which is clearly an improvement over the ambiguous 
> naming schemes we have now.
> 
> BR,
> 	Kristofer
> 
> > OK here's a revised proposal. Please somebody respond to 
> this so that 
> > I can proceed with this (or some revision of it)! Note that 
> all of the 
> > below are syntax changes, there is no change proposed to 
> the way the 
> > FN actually works here.
> > 
> "default_methods" 
> > information is irrelevant (in fact the draft states so), so 
> we could 
> > get rid of it, along with the "=", and use the same syntax as for 
> > default_methods.
> > 
> the case 
> > sensitivity if everybody else is. 2. how about a convention of 
> > capitalising reserved words so that they stand out (in line 
> with Joe's 
> > original suggestion
> > 
> > One final issue with this approach - I don't know about you, but 
> > having keywords with underscores doesn't sit well with me, so I've 
> > shortened them to single words where possible:
> > 
> > uncomp_value      -> UVALUE
> > uncomp_length     -> ULENGTH
> > co_format_blah. Joes original suggestion was to have dedicated 
> > sections something like this:
> > 
> > uncompressed:
> >      blah = ...
> > 
> > compressed:
> >      blah = ...
> > 
> > Instead of marking out sections like this, we could make a much 
> > simpler change and have "compressed" and "uncompressed" 
> keywords for 
> > each format:
> > 
> >    uncompressed blah = ...
> > 
> >    compressed   blah = ...
> > 
> > This would be easily achievable by doing a search and replace, and 
> > would still allow us to use Carsten/Eilert's checking tool provided 
> > there was a simple pre-processor to convert the input back to the 
> > original form, which the tool understands.
> > 
> > What do you think?
> > 
> here is the 
> > difference between the way Java/C# and C++ specify the privacy of 
> > class members. -----Original Message-----
> > authors are proposing for updates to the FN draft. The main 
> theme is 
> > to reassess the draft from a point of view of readability 
> of somebody 
> > like Joe and make as many improvements to the accessibility of the 
> > draft as possible. In particular:

---

From: "Kristofer Sandlund (LU/EAB)" <[email-masked]>
Date: Thu, 24 Nov 2005 14:29:18 +0100

Ok, I obviuosly have not been looking at the FN for some time, so
I got a bit confused. So, let me try to see if I understand it now:

Currently:
--------
- Everything is case-sensitive, but only constants can use upper-case

Your suggestion:
--------
- Everything is case-insensitive
- We adopt optional convention of using upper-case for keywords.

Correct?

What I'd like to see:
--------
- Case-sensitive
- Legal to use uppercase for anything
- All reserved keywords defined in FN-draft are (MUST BE) upper-case
- Recommend that local defined names start with lower-case,
  but that I can do foo_DYNAMIC as a convention locally in ROHC-TCP

Does this make any sense?

/Kristofer

Finking, Robert <mailto:[email-masked]> wrote:

> capitalisation anywhere in the FN. This would allow you to do what
> you suggested below. 
>

---

From: "Finking, Robert" <[email-masked]>
Date: Mon, 28 Nov 2005 09:06:32 -0000

Hi,

Yes that makes sense, and since we really can't afford to debate these
things right now, sure let's go with that. Over the weekend, it occurred
to me that we have a problemette with the new syntax. Control fields now
look like this:

   CONTROL
   {
      field_floo ::= encoding(params);
      etc.
   };

However, not all control field sections specify encoding methods for all
their fields, rather they leave the definition of the encoding to the
compressed packet formats. To get round this, I propose simply that we
allow their field encodings to remain unspecified, like this:

   CONTROL
   {
      field_floo ::= encoding(params);
      field_blah;
      etc.
   };

Obviously this isn't a simple search and replace job for you TCP guys,
so I'm looking at writing a tool to transform the FN from one form to
the other. I'll let you know when it's available =)

I think it's good for us to be doing these sorts of things if you can
stomach it, because on reflection most of Joe's issues were with the FN
itself rather than the I-D. I think it's worth doing these sorts of
changes where we can.

Let me know your thoughts.

Cheers

Raffles