Re: [rohc] Comments on RFC 4997

[Raffles <[e-mail]>]

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:
> 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:
>>
>> 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
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Rohc mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/rohc
>>   
>
>

-- 
Raffles (Robert Finking)
m: 0789 463 9887
e: [e-mail]
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.
-----------------------------------------------------------------