RE: SigComp Requirements (was Re: [rohc] RE: Default decompressio n algorithms)

["Price, Richard" <[e-mail]>]

> > I don't understand - what did I propose that contradicts the
> > current SigComp/UDVM draft?
> 
> UDVM uses state identifiers that uniquely identify state.
> In UDVM, there is no need for a central organization registering state
> identifiers.

For security reasons the UDVM always creates new state identifiers to be a
hash of the relevant item of state. However, when state is accessed the state
identifier is simply used as a key to retrieve the corresponding state. The
UDVM instruction for retrieving state doesn't check that the state identifier
is actually a hash of the state being retrieved - and why should it? Evaluating
the MD5 hash twice would throw away processing resources for no gain.

An implication of only evaluating the MD5 hash when the UDVM creates new
state is that if the state happens to be created externally, there is no need
for the state identifier to be a hash of the state at all. The collision
problem needs to be solved of course; having "a central organization
registering state identifiers" is one way to do this.

> > Nothing needs to be added to SigComp in order to support my proposal.
> 
> Not true, your new kind of state identifier has properties that differ from
> UDVM state identifiers. They are not adding capability.  Why bother?

As far as I can tell, the current SigComp draft does in fact allow my proposal
with no need for any modifications. Whether it *should* or not is another
matter entirely.

> I'd rather work on finishing the document.

Agreed. But since the current SigComp draft allows my proposal to be
implemented, we need to decide whether this is OK or not. Are there any
technical reasons for enforcing that application-defined state should always
be referenced by a hash?

Regards,

Richard