Subject: [rohc] Comments on RFC 4997

From: "Lee, Jiwoong" <[email-masked]>
Date: Thu, 18 Jun 2009 20:41:17 -0700

Dear ROHC WG,

I hope this comment was not discussed before. At least my quick search did not find the related thread.

These are some questions and comments about RFC 4997.

1.       Definition of Single quotes

According to pp 26 of the same document,  a discriminator is defined
     discriminator     =:=   '01101';
as equivalent to
     discriminator     =:=   compressed_value(5, 13);

In pp 36 the last paragraph, COMPRESSED format3 was defined with
field_4 =:= '1010';            // set ULENGTH to zero

Here unless one do not impose different interpretation of the single
quotes for the /field/ and the /discriminator/, wouldn't it be better
to change this into the following?
field_4 =:= '1010';            // set ULENGTH to 4

2.       Possible error in the Worked Example

I suspected in Appendix B.7 pp. 56 "COMPRESSED flags_set" format,

abc_flag_bits =:= uncompressed_value(3, 7) [0];

shoud be corrected to

abc_flag_bits =:= irregular(3) [3];

Accordingly, subsequent examples till Appendix B.8 should be corrected.

3.       Encoding function naming issue.

To my impression, the ROHC documents are using the notion and the term "compression" to mean both of compression and encoding, as if they are the same. I believe it is not.

To single out a case, the same document is defining encoding functions

"uncompressed_value( ., . )" and "compressed_value( ., .)"

These functions are indeed for inference functions. That is, it says "the field value can be computed by using other explicit field values".  Above naming does not carry this descriptive understanding at all. I understand the author's original idea of that naming - which is possibly derived from the fact that the associated field is/is not defined in UNCOMPRESSED/COMPRESSED format, or so, which is less crucial in catching the notion of "inference" encoding.

I will appreciate your inputs.

Many thanks,

Jwoong

---

From: Klaus Warnke <[email-masked]>
Date: Fri, 19 Jun 2009 11:20:27 +0200

Hi Lee,

from my point of view the definitions are correct.

A compressed value is a value that exist in a compressed format only.

The discriminator is used to distinguish the packets to choose
the correct format for decompression. Therefore this field does
not appear in a uncompressed format.

 > field_4 =:= '1010'; // set ULENGTH to zero

If a compressed packet start with '1010' the COMPRESSED format3
could be used. But the field_4 does not appear in a UNCOMPRESSED
format, so the ULENGTH is zero.

 > abc_flag_bits =:= uncompressed_value(3, 7) [0];

eg_header
{
UNCOMPRESSED {
abc_flag_bits [ 3 ];
}

COMPRESSED flags_set {
abc_flag_bits =:= uncompressed_value(3, 7) [ 0 ];
}
}

To compress a eg_header into the flags_set format, the
abs_flag_bits field in the uncompressed eg_header with the length
3 must have the value 7. If not, the flags_set format can not be
used, an other format must (irregular, for example). But the
value 7 itself does not appear in the flags_set format itself,
therefore the CLENTH is zero. It is compressed away.

The '[3]' in the UNCOMPRESSED format says, that this field is in
this format three bits in length. You can see this also in every
COMPRESSED format definiton:

abc_flag_bits =:= irregular(3) [ 3 ];
abc_flag_bits =:= uncompressed_value(3, 7) [ 0 ];
abc_flag_bits =:= static [ 0 ];

In irregular the field is send as it is with 3bits. For
uncompressed_value see above. In static, the value in the
eg_header must be the same as saved in the context. To
decompressed such format, a value in the context must exist.

The fn defines a two way mapping between uncompressed and
compressed format. You can use the eg_header UNCOMPRESSED ->
COMPRESSED flags_set mapping, if all definitions could be
fulfilled. Maybe more than one works for compression.
And vice versa.

This is how I understand the fn.

br
Klaus Warnke

Lee, Jiwoong wrote:
> quotes for the /field/ and the /discriminator/, wouldn’t it be better
> I suspected in Appendix B.7 pp. 56 “COMPRESSED flags_set” format,
>
> To my impression, the ROHC documents are using the notion and the term 
> “compression” to mean both of compression and encoding, as if they are 
> the same. I believe it is not.
>
> “uncompressed_value( ., . )” and “compressed_value( ., .)”
>
> These functions are indeed for inference functions. That is, it says 
> “the field value can be computed by using other explicit field 
> values”. Above naming does not carry this descriptive understanding at 
> all. I understand the author’s original idea of that naming – which is 
> possibly derived from the fact that the associated field is/is not 
> defined in UNCOMPRESSED/COMPRESSED format, or so, which is less 
> crucial in catching the notion of “inference” encoding.
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Rohc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rohc
>   

-- 
Klaus Warnke                [email-masked]
http://www.acticom.de
Tel +49-30-4303.2510        Fax +49-30-4303.2519
* --------------------------------------------------------- *
acticom GmbH
Am Borsigturm 42, 13507 Berlin, Germany
Managing Directors:  Olaf Kehrer, Gerrit Schulte
Commercial Register: Berlin-Charlottenburg HRB 73245
VAT-ID DE205131766
* --------------------------------------------------------- *
This email and the information it contains may be
privileged and/or confidential. It is for the intended
addressee(s) only. The unauthorised use, disclosure or
copying of this email, or any information contained,
is prohibited. If you are not an intended recipient,
please notify the sender immediately and delete this email.

---

From: Raffles <[email-masked]>
Date: Fri, 19 Jun 2009 20:36:47 +0100

Hi Klaus, Lee, All,

Thanks Klaus for replying to this. All your answers are correct as far 
as I can see. Thank you for taking the time to respond.

Lee, does this explain things for you?  It seems to me that you have 
perhaps got confused between  ULENGTH and CLENGTH. Feel free to ask 
further questions if you still have doubts.

Regards

Raffles (RFC 4997 Editor)

Klaus Warnke wrote:
>> To my impression, the ROHC documents are using the notion and the 
>> term “compression” to mean both of compression and encoding, as if 
>> they are the same. I believe it is not.
>>
>> values”. Above naming does not carry this descriptive understanding 
>> at all. I understand the author’s original idea of that naming – 
>> which is possibly derived from the fact that the associated field 
>> is/is not defined in UNCOMPRESSED/COMPRESSED format, or so, which is 
>> less crucial in catching the notion of “inference” encoding.
>>

-- 
Raffles (Robert Finking)
m: 0789 463 9887
e: [email-masked]
w: gluft.com

         O                  O
 OOOOOO  O  O    O OOOOOO OOOOO
 O    O  O  O    O OOOOO    O
 OOOOOO  O  OOOOOO O        O
 OOOOOO
      we  care  about  software

-----------------------------------------------------------------
Gluft Ltd. Registered No.: 6795336
The information contained in this e-mail and any attachments is
proprietary to Gluft Ltd and must not be passed to any third
party without permission. This communication is for information
only and shall not create or change any contractual relationship.
Please consider the environment before printing this email.
-----------------------------------------------------------------

---

From: "Lee, Jiwoong" <[email-masked]>
Date: Fri, 19 Jun 2009 15:21:13 -0700

Dear all,

Indeed, that was the case. Thank you for the clarification, Klaus.

Regards,
Jiwoong

-----Original Message-----
From: Raffles [mailto:[email-masked]] 
Sent: Friday, June 19, 2009 12:37 PM
To: Klaus Warnke
Cc: Lee, Jiwoong; [email-masked]
Subject: Re: [rohc] Comments on RFC 4997

Hi Klaus, Lee, All,

Regards

Klaus Warnke wrote:
>> term "compression" to mean both of compression and encoding, as if 
>> "the field value can be computed by using other explicit field 
>> values". Above naming does not carry this descriptive understanding 
>> at all. I understand the author's original idea of that naming - 
>> less crucial in catching the notion of "inference" encoding.
>>

-- 
Raffles (Robert Finking)
m: 0789 463 9887
e: [email-masked]
w: gluft.com

         O                  O