Subject: FW: [rohc] FN draft review

From: "Finking, Robert" <[email-masked]>
Date: Thu, 9 Nov 2006 10:28:01 -0000

Hi Ghyslain, Mark,

Here are my responses to Mark's comments (inline). I should perhaps say
that Mark and I have acted entirely independently on this - though we do
work together on projects here and there, we haven't actually discussed
the FN together for a long time!

Cheers

Raffles

> -----Original Message-----
> From: West, Mark [mailto:[email-masked]] 
> Sent: Tuesday, October 31, 2006 1:35 PM
> To: [email-masked]
> Subject: [rohc] FN draft review
> 
> 
> 
> 
> Hi all,
> 
> Herewith a review of the RoHC FN draft (-11).
> 
> A general comment: this draft looks to be in pretty good 
> shape; I, for one, find it more readable than on its previous 
> outings.  My thanks, therefore, to the authors and previous 
> reviewers for their efforts in making that the case!
> 
> I've split this review into 'real' comments / questions 
> first, and left a bunch of NITs to the end.
> 
> Cheers,
> 
> Mark.
> 
> 
> 
> Comments:
> 
> Section 2
> 
> * "Context", certainly at the compressor, a context would be 
> expected to contain a list of 1 or more values?

Good point

> 
> * "Encoding method", is there any particular reason to use 
> both 'function' and 'relation', rather than just 'relation' 
> (or 'relationship')?

Agree use of "function" is a bit lose in this context.

> 
> Section 3.2.1
> 
> * "one unspecified data object and one specified object" -- 
> is it possible to bind two unspecified objects?

I guess so but you wouldn't ever want to do it! You could for example
have two control fields which are bound to each other, but not to
anything else. Not sure if it helps to point this out in the draft or
not though!

> 
> * "At the decompressor, the operation is reversed..." -- 
> presumably decoding fails if the binding fails?

Yes. Worth stating.

> 
> * "For example, the "static" encoding method creates a 
> binding..." is true but incomplete, because it has also to 
> bind the lengths.  It might be nice to spell this out?
> 

OK

> * "Both the compressed and uncompressed forms of each field 
> are mapped to 'bits on the wire'... -- what does it mean to 
> map an _uncompressed_ field 'on the wire'?  Or does this 
> simply refer to bit/byte ordering issues?

It's the bits on the incoming wire at the compressor and outgoing wire
at the decompressor. At least that's how I understood it - I don't see
any need for
any change here, unless there is an obvious clarification to be made.

> 
> Section 3.2.2
> 
> * "control fields, that are additional information added to 
> the compressed format during compression" -- seems a little 
> confusing (to me, at least!) Perhaps "control fields, that 
> represent context information separate from that contained in 
> the uncompressed header", or something..?

OK

> 
> * "this is possible because ctrl_field_3 has no 
> 'uncompressed' value..." 
> This seems to contradict previous statements about the nature 
> of the binding in FN?  (i.e. during decompression you do not 
> have any undefined value, but 2 defined values that have to 
> match?)  I guess I'm still a bit unclear as to why this isn't 
> done through a control field, but I think it makes sense...

The way I see it, the previous description is intended to paint
a broad brush picture - now we're filling in some details.
I can see it might be useful to make it explicit that this is
an exception to the general case in that we're not mapping
between uncompressed and compressed, we're just explicitly
setting the value of part of the compressed header. However,
if we make it too wordy I think it becomes less clear rather
than more clear and I kind of thought that the existing text
already got the point across, so my feeling is not to change
this.

> 
> Section 3.3
> 
> * "It is a fail-safe encoding method that can be used..." -- 
> I'm not sure that I believe this.  Or at least, not without 
> the caveat, 'subject to the previous conditions of use'. At 
> least I can certainly conceive a field (null-terminated 
> value?) that cannot be compressed by 'irregular'.

The text explicitly states "whose length attribute is either
fixed or it can be calculated using an expression". No change
needed!

> 
> Section 4.2
> 
> * "It is illegal to have two or more identifiers that differ 
> from each other only in capitalisation" -- so is it case 
> sensitive, or not, or..?

Yes, case sensitive. We're just trying to rule out the classic
problems that occur with case sensitive languages where you
either 1. accidentally declare/use a new identifier, which can
take a while to spot by eye, or 2. purposefully create a new
identifier that differs only in capitalisation, which then
makes it hard to read for others.

> 
> Section 4.4.2
> 
> * Given that 'v' and 'l' are introduced here just for this 
> expression, and that 'l' is more that slightly ambiguous with 
> '1' (at least in my courier font!), why not use 'VALUE' and 
> 'LENGTH', or something?

OK

> 
> * What does it mean to bind comp_value(-1) comp_length(8) to 
> uncomp_value(unspec) uncomp_length(16)?  (Assuming 
> appropriate length bindings)  Do I get 0x00ff or 0xffff out?
 
We don't have an encoding method that does that. It would be
up to you to specify the mapping if you wanted to define it.
Note this has nothing to do with section 4.4.2 which defines
how to map from bits-on-the-wire to attributes - your question
is about how to map between compressed and uncompressed
attributes.

>
> 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.

> 
> Section 4.7
> 
> * I can't believe that the list of exclusions is exhaustive?  
> However, this probably doesn't matter too much.

I believe it is complete, but if you find anything missing,
do feel free to shout up!

> 
> Section 4.9
> 
> * Would it make sense to give an example for case (3) of the 
> ENFORCE binding?
>   For example, I assume that I could use:
>     ENFORCE(foo.ULENGTH == bar.ULENGTH)
>   to force two fields to be the same (currently unknown) value?
> 
> I also assume that, e.g., ENFORCE(foo.UVALUE != 20) allows 
> the decompressor to pick any value for foo.UVALUE that does 
> not contradict any other binding?

That's correct. Yes I think that would be useful. One thing I
never got around to was overhauling this section - I'm not
entirely sure it's as clear as it could be. Thanks for supplying
two useful examples!

> 
> Section 4.10
> 
> * Presumably the enforcement of lengths can be used to 
> specify the length of one field in terms of the value of 
> another (c.f. TCP SACK block); might be nice to make this 
> explicit (I don't /think/ it currently is...)

Yes, it would be good to mention this.

> 
> Section 4.11
> 
> * I don't understand why methods aren't specified 'formally' 
> using a set of ENFORCE statements.  This is typically trivial 
> and adds a degree of rigo(u)r to the definition?
> 
>   e.g. 'uncompressed_value' ==>
>         ENFORCE(f.ULENGTH = len)
>         ENFORCE(f.UVALUE  = val)
>         ENFORCE(f.CLENGTH = 0)

We started out doing this, but:
1. It requires defining extra attributes to allow access to the context,
which aren't needed for any other purpose (we decided it was better to
simplify the FN).
2. LSB is a nightmare a. to write and b. for the reader to understand
(and so probably would CRC be, but we gave up before we got to it).

The problem is that you end up defining the trivial cases in such a way
and not the really difficult ones. It would be a bit like having ASCII
art diagrams to explain a common linked list but not having them for an
more complex and unusual data structure like an AVT tree that occurred
in the same piece of code
(http://www.cs.iastate.edu/~honavar/Papers/icml-zhang03.pdf) ;-) In my
opinion anwyay!

> 
> Section 4.11.6
> 
> * Does the calculation of the CRC include the CRC?  And how 
> is the checking of the CRC defined?

It is counted as being zero. We did discuss whether to mention
this but sidestepped it by referencing the ROHC-FW.

> 
> Section 4.12.1.2
> 
> * I assume that it is 'illegal' to have an encoding specified 
> for both "UNCOMPRESSED" and "COMPRESSED" encoding methods.  
> However, I don't think that this is explicitly stated?

No, it is not illegal. If they are both specified, they succeed
only when the bindings they both specify don't conflict. If they
always conflict then the UNCOMPRESSED format and COMPRESSED format
concerned can never be used together. If there is only one
UNCOMPRESSED format as is often the case then the COMPRESSED format
becomes useless. However I don't think it's worth spelling all this
out in the document.

> 
> Section 4.12.1.4
> 
> * Presumably using a binding which relies upon a context 
> value will simply fail or leave the field with an undefined 
> value?  (In other words, it should not be done, but the 
> definition of binding within the notation seems to cover this case.)
> 
> 

The final paragraph of this section already prohibits use of bindings
which rely on context in the INITIAL section =)

> 
> 
> NITs
> 
> Section 1
> 
> * "this sometimes showed to be unclear" -> "this was 
> sometimes unclear"
> 
> * "previously existed" -> "exists"
> 
> * "is a function that performs" -> "defines" (maybe?  
> 'function' seems like a provocative word!)
> 
> 
> Section 2
> 
> * in "Uncompressed format", is the text "to be compressed" necessary?
> 
> Section 3.1
> 
> * "define the inverse, how to relate" -> "define the inverse: 
> how to relate"
> 
> * "outline compression strategy principles" ->
>     "outline compression strategy" or
>     "outline compression princinples" (but not both!)
> 
> Section 3.2.1
> 
> * "indicates how long this field is before it is compressed."
>     -> "indicates the uncompressed length of the field." 
> (otherwise you are implying a temporal ordering that is not 
> present in the mapping?)
> 
> * "This is similar to the unification process in logic."
>     Is this worth a reference?

Probably! But what? Can we cite Wikipedia??? =)
http://en.wikipedia.org/wiki/Unification - seriously the Wikipedia page
has some useful references at the bottom. Eg. "F. Baader and W. Snyder,
Unification Theory. In J.A. Robinson and A. Voronkov, editors, Handbook
of Automated Reasoning, volume I, pages 447-533. Elsevier Science
Publishers, 2001"

> 
> * "where "length" is the value attribute" ->
>     "where "length" is the length attribute" ???

OOps!

> 
> Section 3.3
> 
> * "help the reader's understanding" -> "help the readers' 
> understanding" ???

I am happy with the idea that reading is a personal activity and that
"reader" in this case is effectively being used as a singular pronoun.
However if you wish to move the apostrophe Ghyslain I really can't find
it in myself to be that bothered about this. I'm not sure whether I take
this as a good sign that we're bothering to consider such trifles (in
that the noise levels have dropped right down) or a worrying one!

> 
> * "This is notated explicitly by specifying in square 
> brackets a length of 0
>    for the length of the checksum field" ->
>     "This is notated explicitly by specifying, in square 
> brackets, a length
>      of 0 for checksum field"

Hoorah - more comments about commas. Every other reviewer inside Roke
has added, deleted and rearanged each other reviewer's new use of
commas. I was beginning to worry that people had got all comma'd out!
Personally I don't think it needs any here, but feel free to liberally
sprinkle them here and there so that somebody else can suggest taking
them out ;-)

> 
> Section 4.4
> 
> * "Fields are the units which headers are divided into"
>     -> "Fields are the units into which headers are divided"

No comment!

> 
> Section 4.11.3
> 
> * "<expression> -> "<length_expression>"
> 
> Section 4.11.6
> 
> * "I.e." -> "i.e."
> 
> Section 4.12.1
> 
> * "a second field to represent the salient part" ->
>     "a second field to represent the rapidly changing part" ->
> 

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

---

From: "West, Mark" <[email-masked]>
Date: Thu, 9 Nov 2006 11:38:04 -0000

Hi Raffles,

Some (independent!) comments on some of your comments... (I've snipped out the non-contentious ones for clarity).

Thanks,

Mark.

[Mark] ok.  This is related to the comment on section 4.9 which speculates about binding 2 objects that are unspecified at the time of the binding to assert equality between them.  Whether it makes sense in this context, I really don't know.  If you think I'm talking rubbish, then I'm happy for the text to stay as it is...

> simply refer to bit/byte ordering issues?

It's the bits on the incoming wire at the compressor and outgoing wire at the decompressor. At least that's how I understood it - I don't see any need for
any change here, unless there is an obvious clarification to be made.

[Mark] But hang on... the "uncompressed form" is mapped to a "compressed form" (via the encodings) and that "compressed form" is mapped to bits on the wire?  (Or the reverse, for decompression.)  The "uncompressed form" (as I would understand that term) is never directly mapped to bits on the wire.  Is it?

[Mark] Ok, I've re-read the text and I think I misunderstood when reading it previously.  However, I'll have a bit more of a think and see if I feel like being pedantic... ;-)

[Mark] Ok, not a big deal.  I just can't see the value in the 'fail-safe' sentence, since all the information is given in the previous sentence.

[Mark] So is it worth being explicit (if it isn't already) about case sensitivity?  (Rather than having to derive it from the above rule?)

[Mark] Fair enough.

[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 ;-)

We started out doing this, but:
1. It requires defining extra attributes to allow access to the context, which aren't needed for any other purpose (we decided it was better to simplify the FN).
2. LSB is a nightmare a. to write and b. for the reader to understand (and so probably would CRC be, but we gave up before we got to it).

The problem is that you end up defining the trivial cases in such a way and not the really difficult ones. It would be a bit like having ASCII art diagrams to explain a common linked list but not having them for an more complex and unusual data structure like an AVT tree that occurred in the same piece of code (http://www.cs.iastate.edu/~honavar/Papers/icml-zhang03.pdf) ;-) In my opinion anwyay!

[Mark] Let me think about this -- I'll get back to you!

[Mark] Fair enough.  I guess it feels like 'crc' is a bit outside of the rest of the encodings, since it seems to work in a quite different way.  That's not necessarily a problem, but pointing out that the CRC is over the entire uncompressed header (or something) may help make it clear that it's behaving a bit differently from the other methods..?

[Mark]  Indeed it does.  I was speculating as to whether that explicit restriction is necessary.  So my question was whether the extant rules for successful binding / decompression mean that everything will behave itself sensibly?

---

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

Robert, Mark,

See comments inline.
I've clipped away that for which I agree on and already updated the
draft.

///Ghyslain

Finking, Robert wrote:

>> Section 3.3
>> 
>> * "It is a fail-safe encoding method that can be used..." -- I'm not
>> sure that I believe this.  Or at least, not without the caveat,
>> 'subject to the previous conditions of use'. At least I can certainly
>> conceive a field (null-terminated

I agree with Mark's point, but not with his example. I think that a
possible example would be to declare a control field in a COMPRESSED
section and code it with irregular, without ever having bound UVALUE:

COMPRESSED a_format {
	ctrl_field_never_declared_before = irregular(16); [16]
} 

> fixed or it can be calculated using an expression". No change needed!

Yet I have rewritten as follow:

... "can be used to encode any field for which both uncompressed
     attributes (ULENGTH and UVALUE) are defined, and whose length
     attribute is either fixed or it can be calculated using an
     expression. It is a fail-safe encoding method that can be used
     for such fields in the case where no other encoding method applies"
 
I could have changed it to say "ULENGTH != 0" but I think that the
general applicability if for a field that has both ULENGTH and UVALUE
defined. Right now, a ULENGTH of 0 would mean an undefined UVALUE and I
think that in that case irregular can't be applied (not fail-safe).

> subfields in the uncompressed header.

I think that Mark meant something similar to EXT-3 in 3095 where
additional TS, SN and/or IP-ID can be put in the extension and gets
concatenated to the bits (if any) in the base header.

So you can't simply split the uncompressed field - there you'd want to
split the result of an encoding method.

I don't think that this is possible with grouping (if that was the
question). I don't think this is either possible otherwise. 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 I
think.
 
>> 
>> Section 4.9
>> 
>> * Would it make sense to give an example for case (3) of the ENFORCE
>>   binding? For example, I assume that I could use:

I don't think we need to add anything there.

My understanding here is that the question is what happens if an ENFORCE
binds an attribute to a range of values using !=, < or >. I think that
it does not matter - either when reversing it there will be another
binding that will give the exact value, either there won't be and the
binding gets satisfied with any value that matches the condition
(although this particular case is bad practice as this can't guarantee
bitwise transparency, which is normally a requirement - but this is not
FN's problem).

> Yes, it would be good to mention this.

This is already covered by the ENFORCE statement definition, for which
[] provides an abbreviated form.
 
>>   e.g. 'uncompressed_value' ==>

I've made the change for the easy ones. I think that anyway the english
text under meant the same. For those that are more complex, we can keep
the text as it currently is. I don't think that's a problem.

> this but sidestepped it by referencing the ROHC-FW.

My understanding is that this is not exactly true .
 
My opinion is that this is outside the scope of FN.

CRC coverage with calculation of CRC is profile-specific. CRC-3 and
CRC-7 are not part of the uncompressed header, so no problem there. Wrt
CRC-8, the framework mentions what applies. Checking of CRC and
checksums is assumed well-known in other IETF RFCs I've checked.

>>     Is this worth a reference?

No reference here. This is not necessary for the reader's understanding.
And no we can't cite Wikipedia, web pages have no guarantee they'll keep
the same definition or will stay up.

> However if you wish to move the apostrophe Ghyslain I really

THIS IS NOT MY REVIEW! Why blame me for this???  ; )

> can't find

Not my review again ; )
 
I've fixed most of the NITS and into the CVS. Just have a check.

---

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

Some more thoughts inline ...

///Ghyslain

> do feel free to shout up!

Carsten had the same comment, and listed a number of examples.

I have to admit that working by exclusion wrt to another language is not
the best practice we've come up with. Either we think that this is not
important, or we take another approach. I am not sure this is
interesting to increase the list of exclusions.

Please provide a suggestion (I can't think of how to resolve this one)

---

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

West, Mark wrote:

>> * "Both the compressed and uncompressed forms of each field are
>> mapped to 'bits on the wire'... -- what does it mean to map an
>> _uncompressed_ field 'on the wire'?  Or does this simply refer to
>> bit/byte ordering issues?
> 
> It's the bits on the incoming wire at the compressor and
> outgoing wire at the decompressor. At least that's how I
> understood it - I don't see any need for any change here,
> unless there is an obvious clarification to be made.
> 
> [Mark] But hang on... the "uncompressed form" is mapped to a
> "compressed form" (via the encodings) and that "compressed
> form" is mapped to bits on the wire?  (Or the reverse, for
> decompression.)  The "uncompressed form" (as I would
> understand that term) is never directly mapped to bits on the
> wire.  Is it?

I've removed the "mapping on bits on the wire" and use instead "bits
exchanged between compressor and decompressor". I am not sure really
what this "mapping" was trying to say from the beginning, but it seems
unnecessary to expand more on that.
 
> [Mark] Ok, not a big deal.  I just can't see the value in the
> 'fail-safe' sentence, since all the information is given in
> the previous sentence.

>> 
>> Section 4.2
>> 
>> * "It is illegal to have two or more identifiers that differ from
>> each other only in capitalisation" -- so is it case sensitive, or
>> not, or..?
> 
> Yes, case sensitive. We're just trying to rule out the
> classic problems that occur with case sensitive languages
> where you either 1. accidentally declare/use a new
> identifier, which can take a while to spot by eye, or 2.
> purposefully create a new identifier that differs only in
> capitalisation, which then makes it hard to read for others.
> 
> [Mark] So is it worth being explicit (if it isn't already)
> about case sensitivity?  (Rather than having to derive it
> from the above rule?)

What about the following:

   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"

> 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.
 
>> using a set of ENFORCE statements.  This is typically trivial and
>> adds a degree of rigo(u)r to the definition?
>> 
> 1. It requires defining extra attributes to allow access to
> the context, which aren't needed for any other purpose (we
> decided it was better to simplify the FN).
> 2. LSB is a nightmare a. to write and b. for the reader to
> understand (and so probably would CRC be, but we gave up
> before we got to it).
> 
> The problem is that you end up defining the trivial cases in
> such a way and not the really difficult ones. It would be a
> bit like having ASCII art diagrams to explain a common linked
> list but not having them for an more complex and unusual data
> structure like an AVT tree that occurred in the same piece of
> code
> (http://www.cs.iastate.edu/~honavar/Papers/icml-zhang03.pdf) ;-) In
> my opinion anwyay! 
> 

>> 
>> Section 4.11.6
>> 
>> * Does the calculation of the CRC include the CRC?  And how is the
>> checking of the CRC defined?
> 
> It is counted as being zero. We did discuss whether to
> mention this but sidestepped it by referencing the ROHC-FW.
> 
> [Mark] Fair enough.  I guess it feels like 'crc' is a bit
> outside of the rest of the encodings, since it seems to work
> in a quite different way.  That's not necessarily a problem,
> but pointing out that the CRC is over the entire uncompressed
> header (or something) may help make it clear that it's
> behaving a bit differently from the other methods..?

That's would be inappropriate I think, as this is profile-specific?
 
>> 
>> Section 4.12.1.4
>> 
>> * Presumably using a binding which relies upon a context value will
>> simply fail or leave the field with an undefined value?  (In other
>> words, it should not be done, but the definition of binding within
>> the notation seems to cover this case.)
>> 
>> 
> 
> The final paragraph of this section already prohibits use of
> bindings which rely on context in the INITIAL section =)
> 
> [Mark]  Indeed it does.  I was speculating as to whether that
> explicit restriction is necessary.  So my question was
> whether the extant rules for successful binding /
> decompression mean that everything will behave itself sensibly?

Sanity of the packet format specification (not sanity of the language
itself) is a responsability of the user of the notation. I don't think
that there is a way to specify being sensible ; )

---

From: "West, Mark" <[email-masked]>
Date: Thu, 9 Nov 2006 13:52:50 -0000

In-line, as ever...

Thanks,

Mark.

-----Original Message-----
From: Ghyslain Pelletier (LU/EAB) [mailto:[email-masked]]
Sent: Thu 11/9/2006 1:39 PM
To: West, Mark; Finking, Robert
Cc: [email-masked]
Subject: RE: [rohc] FN draft review

[Mark] splendid!

[Mark] perfectly happy with that

   o  "false", "true"

[Mark] That's fine.  I don't have a problem with requiring identifiers to be distinct other than by case -- I was really just after the "Identifiers are case-sensitive" bit being added.  But I'm quite happy with the above text.

[Mark] Thanks for the clarification.  I'm sure it would be a mess and I agree that we can live without it.

[Mark] Ok.

[Mark] Fair point - ok, leave it as it is.

[Mark] Agreed ;-)  I don't think there's any need to change any text, anyway...

---

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

On Nov 09 2006, at 03:38, West, Mark wrote:

> [Mark] ok.  This is related to the comment on section 4.9 which  
> speculates about binding 2 objects that are unspecified at the time  
> of the binding

There is no "at the time" in FN...

Perfectly legal:

foo(bar) {
   UNCOMPRESSED { f[16]; }
   COMPRESSED { f[16];
     ENFORCE(f.UVALUE == f.CVALUE);
     ENFORCE(f.UVALUE == bar);
   }
}

(Yes, this can be said with "irregular", too.)

Gruesse, Carsten

---

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

> which aren't needed for any other purpose (we decided it was better to

For lsb and static, yes.  The other ones can be done formally, see my  
comments.

> (and so probably would CRC be, but we gave up before we got to it).

I'm not sure FN is powerful enough to do CRC (but then you can parse  
troff in sed :-).

> and not the really difficult ones.

That is not a problem.
Removing 60 % of potential misunderstanding is better than removing 0  
% of potential misunderstanding.

I thought the FN motto was "consistency is the hobgoblin of the  
little mind"? :-)

Gruesse, Carsten

---

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

>    capitalisation, and in particular within the same scope.

That is much worse, as FN then is no longer case-insensitive (yes,  
that's not a typo).

Leave multiple case spellings as an error.

Gruesse, Carsten

---

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

> Please provide a suggestion (I can't think of how to resolve this one)

Just clarify that the exclusions given are examples, and that the  
definitive list of what's in FN follows.
(This is just an editorial fix, I think.)

Gruesse, Carsten