Subject: RE: [rohc] TCP packet formats (help me!)

From: "Finking, Robert" <[email-masked]>
Date: Thu, 7 Oct 2004 14:43:17 +0100

]> ]>   list_tcp_options(list_length_in_bytes) ===
]> ]>   {
]> ]>     end_of_list_sentinel ::= uncompressed_value(8, 0);
]> ]>     end_of_list_pad      ::= uncompressed_value(8, 1);
]> ]>        :                        :
]> ]>     timestamp            ::= tcp_timestamp_list_item();
]> ]>        :                        :
]> ]>        :                        :
]> ]>     etc.
]> ]>   };
]> ]
]> ]Can't parse this.
]>
]> Go on, then, give us a clue! What line is causing you a problem ? Is 
]> it a
]> silly, or is there a more fundamental flaw here?
]
]I don't see uncompressed_formats and compressed_formats.  These are 
]required in a structure.

That's true, but this isn't a structure, it's a list structure, which has different syntax.

The syntax for lists is simpler than for ordinary structures - there is no mapping between compressed and uncompressed to specify in the list syntax itself - you do that in the encoding methods for each of the possible list items. All that the list syntax specifies is:
   1. what items can occur in the list,
   2. how to encode them
   3. how the list is terminated (including any padding if needed)

I'm wondering if people have actually read the sections on list encoding yet? If so, it obviously needs clarifying - I'd thought I'd spelt all this out =)

Cheers

Raffles

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

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 7 Oct 2004 18:56:23 +0200

> That's true, but this isn't a structure, it's a list structure, which 

I'm sorry, I haven't read 4.10 yet, as this was never discussed, and I 
though we didn't need it.
We will do this tomorrow.

Gruesse, Carsten

---

From: Kristofer Sandlund <[email-masked]>
Date: Fri, 08 Oct 2004 08:42:58 +0200

Ok, now I have a bit better understanding of how to use the list encoding in the 
FN, but it seems to be a bit out of synch with what we've said in tcp-07.

    In the definition of the packet formats for ROHC-TCP, the most
    frequent type of TCP options are described. Each of these options has
    an uncompressed format, a list_item format and an irregular format.

So our definitions of each TCP option is assumed to be a structure that contains 
both irregular chain item and list item, while your definition puts the 
list_items into its own structure and it seems to require both a "first" and a 
"subsequent" format. Or do you mean the subsequent to be the irregular chain 
item? A list item will either be present (_list_item) or else it is not a part 
of a list structure at all, it is then part of the irregular chain (see tcp-07 
sections 4.6 and 6.6.5).

Therefore I'm not too sure about the need of a "has_context" attribute, can't we 
just leave this to the implementation to decide if it should be in list or if it 
should be in the irregular chain?

Another thing is that in -07, we use the EOL item to end the list, but it is 
defined to also contain the padding, so I assume I don't have to define a 
sentinel/pad and solely rely on the length parameter here?

/Kristofer