Subject: RE: [rohc] FN draft review

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

OK, here's a second take on one of your questions...

> 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?
> 
> * 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?

I guess you're asking what happens if

   ENFORCE(field.COMP_VALUE = field.UNCOMP_VALUE);

They just get bound together, so field.UNCOMP_VALUE gets a value of -1.
That becomes 0xFFFF on the uncompressed output, which is very
straightforward as far as I can see?

One of the main points of splitting up fields into attributes is to make
this kind of thing well defined and easy to comprehend. You aren't
assigning from an 8-bit buffer to a 16-bit buffer, you're unifying two
integer values. If one is x and the other is undefined, the undefined
one becomes x, with no concept of length or even bits ever being
involved.

Does that help? Do we need to clarify that in the document?

Raffles

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

---

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

>    ENFORCE(field.COMP_VALUE = field.UNCOMP_VALUE);

A syntax error?  :-)

This binding does it by itself cause anything to be -1, so I'm  
confused by the question.

The point remains that the modulo arithmetic causes pain.  (See my  
[[]]-ed out comment.)

> straightforward as far as I can see?

Yes, *if* there is something binding these values to -1 in the first  
place.
If the only thing binding here is the compressed header, the  
uncompressed field will be bound to 255.

> this kind of thing well defined and easy to comprehend.

I'm not convinced that the implicit conversion to integer helps.   
Ceterum censeo.

> You aren't

Yes, that's the problem.

The xVALUE attributes actually bind a field to a modulo group (we  
could say so...).
This is ambiguous if there are two bindings with different field  
lengths.
I read the draft as saying that the intention is that the unspecified  
bits turn zero, but this is never said in so many words.

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

On compression, the first eight bits of f are lost.  Nice, if this is  
what I want.
On decompression, the 8-bit-field is zero-extended, but only if there  
is no other binding in place. Duh.

Fun: Add
   ENFORCE((f.UVALUE < 128) || (f.UVALUE >= -128));
(This is a diversion.  Back to my main point:)

Sign extension *can* be done in FN:

foo {
   UNCOMPRESSED { fe [9]; fv[7]; }
   COMPRESSED {fe[1]; fv =:= irregular(7);
     ENFORCE(fe.UVALUE == fe.CVALUE * -1);
   }
}

(In contrast to the zero extended example, this does not actually  
truncate in the compression direction.)

Gruesse, Carsten