Subject: RE: [rohc] SigComp States

From: [email-masked]
Date: Mon, 3 Nov 2003 10:42:53 -0500

Hello John,

Thanks for comments on sigcomp-sip. Please see my reply inline.

BR,
Zhigang

> (1) [snip] When do compartments share the same state? When do 
> different compartments become related to the same state?

There are two possible cases: a) two compartments accidentally
creates the same state without knowing it, and b) they intentionally
create the same state. The chance of a) may be small in practice,
but a sigcomp implementation must be able to handle it correctly.
Case b) is more like a state "sharing". An example could be
multiple compartments (from the same sigcomp implementation) share
a state of bytecode or dictionary.

> (2) [snip] Why does a UDVM need more than a single allocated state item?

The compressor may want to create more than one state in a sigcomp
message, e.g., one state containing bytecode and one containing 
dictionary. Of course, this is up to implementation. It may just
create one state. The purpose is to make SigComp reasonably flexible
without compromise security.

> (3) [snip] 3. If the state creation request contains a 
> state_identifier that already exists..." Is there any clear 
> example to this kind of situation?

An example could be for sigcomp over UDP. A compressor may try to
create the same state in two sigcomp messages before it knows whether
or not the first sigcomp message is received at the other endpoint.

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