Subject: RE: [rohc] sigcomp issue cabo-11

From: [email-masked]
Date: Tue, 16 Apr 2002 17:17:05 -0500

> > It would be possible to put the message size in low memory,
> > as we do with state_length.
> 
> > Action
> 
> > (decide whether to use low memory)

[Hans wrote:]
 
> Would the suggested action cause any problems? 
> If not why not just go ahead and use the lower memory if that 
> would avoid a loop.

I would suggest to go this way too. The only implication is that 
the decompressor dispatcher needs to have a complete SigComp 
message before invoking UDVM. But that is not a problem to me.

Also, the definition of INPUT-BYTECODE is unclear about the
case of length == 0. I proposed to use length zero to indicate
"I want all the rest of the message". But that is moot if we
put message size in low memory. Then, we could clarify 
zero length case by replacing fourth paragraph of section 
9.4.2 as follows:

"If the instruction requests data that lies beyond the end of the
SigComp message or the requested data length equals zero, no data 
is returned. Instead the UDVM moves program execution to the 
address specified by the address operand."

BR,
Zhigang

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

---

From: [email-masked] (Dr. Carsten Bormann)
Date: 17 Apr 2002 01:31:32 +0200

> message before invoking UDVM. But that is not a problem to me.

Yes (sorry, I considered but failed to document this implication).

It's not a problem for me, either.
(It does remove some implementation flexibility for the TCP case,
though.)

Actually, I believe all remnants of text about UDVMs staying active
while waiting for external events should be removed from the document.
(Ceterum censeo...)

> case of length == 0.

No, I believe it's perfectly clear.  As requested, you get zero bytes
copied.  The operation succeeds (i.e., does not jump to @address), as
no data beyond the input message was requested.

> I proposed to use length zero to indicate
> put message size in low memory.

Exactly.

The low memory approach also would allow the decompressor code to
"plan" for the size of the input message before sucking it in.

> Then, we could clarify

That would be an unnecessary change (why put in a special case to fail
on 0?).

(Generally, giving special meanings to special values of arguments for
an operation generates trouble.  Making the change might mean that a
decompressor must check a length of additional data it has computed
for zero to avoid accidentally terminating when no additional data is
needed.)

Gruesse, Carsten

PS.: Oh, the name INPUT-BYTECODE has become quite misleading now.
How about INPUT-BYTES?
(Or INPUT-OCTETS, if it must be :-)