Subject: [rohc] input bytes beyond message

From: "Lajos Zaccomer (ETH)" <[email-masked]>
Date: Tue, 4 Mar 2003 13:30:15 +0100

Hi,

At SIPit, an interesting interpretation problem was found regarding the INPUT-BYTES instruction. Namely: what to do with the bytes read if there aren't as many in the message as was requested?

The RFC says: "If the instruction requests data that lies beyond the end of the SigComp message, no data is returned.  Instead the UDVM moves program execution to the address specified by the address operand."

In my interpretation this sentence means that ONLY data that lies beyond the end of the message should be discarded. Others interpreted this to discard even those bytes that were part of the message.

Why is this important? Because it may be a very nice feature to eliminate implementing a loop or passing the length of the data block, resulting in shorter bytecodes:
	INPUT-BYTES maximum_length, destination, continue_address
This instructions reads a maximum of maximum_length bytes from the message without knowing how many bytes there are.

I don't think this may impose security risk compared to the other solution, when all the bytes are discarded, if the available cpb is increased with the number of the actually read bytes, instead of the value of the length parameter (the same way as it is done in the INPUT-HUFFMAN instruction).

As I need some statement regarding this question in one or two weeks, I call all interested parties, standardizers and implementors, to start a discussion on this question.

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

---

From: "Surtees, Abigail" <[email-masked]>
Date: Wed, 5 Mar 2003 15:06:08 -0000

Hi Zacco,	

Thanks for raising this on the list.  I'll add some thoughts into the melting pot.

This text appears in the INPUT-BITS instruction as well.  I assume that those
of us with implementations are internally consistent - that is if we return no bytes
we also return no bits, if we return the bytes that are there we also return the bits 
that are there?

This discussion has raised another question:
In the case of not returning the bits or bytes, what happens to them?  e.g. there
are 6 bytes of message left and the next instruction is INPUT-BYTES with length
12.  There aren't enough bytes so we jump to the appropriate instruction.  I think
that in a lot of the bytecodes people are using, there would then be no further 
INPUT instructions so whether the msg pointer still points to the beginning of the
6 bytes or the end of the message is irrelevant.  However, I believe it is undefined
which it should be.  If there were to be another INPUT instruction e.g. INPUT-BYTES
length 6, should it successfully read those bytes or have they effectively been 
thrown away?

Best regards,

Abbie

>At SIPit, an interesting interpretation problem was found 
>regarding the INPUT-BYTES instruction. Namely: what to do with 
>the bytes read if there aren't as many in the message as was requested?
>
>The RFC says: "If the instruction requests data that lies 
>beyond the end of the SigComp message, no data is returned.  
>Instead the UDVM moves program execution to the address 
>specified by the address operand."
>
>In my interpretation this sentence means that ONLY data that 
>lies beyond the end of the message should be discarded. Others 
>interpreted this to discard even those bytes that were part of 
>the message.
>
>Why is this important? Because it may be a very nice feature 
>to eliminate implementing a loop or passing the length of the 
>data block, resulting in shorter bytecodes:
>This instructions reads a maximum of maximum_length bytes from 
>the message without knowing how many bytes there are.
>
>I don't think this may impose security risk compared to the 
>other solution, when all the bytes are discarded, if the 
>available cpb is increased with the number of the actually 
>read bytes, instead of the value of the length parameter (the 
>same way as it is done in the INPUT-HUFFMAN instruction).
>
>As I need some statement regarding this question in one or two 
>weeks, I call all interested parties, standardizers and 
>implementors, to start a discussion on this question.
>
>BR/Zacco

---

From: "Lajos Zaccomer (ETH)" <[email-masked]>
Date: Thu, 6 Mar 2003 07:51:49 +0100

Hi Abbie,

I agree with you, the input instructions should have a consistent behaviour, which means if it applies to INPUT-BYTES, it should also apply to INPUT-BITS. The only exception is INPUT-HUFFMAN, as its result is not valid in such a case; however, the problem you raised, in case of discarded data, should be handled in INPUT-HUFFMAN, too.

BR/Zacco

-----Original Message-----
From: Surtees, Abigail [mailto:[email-masked]]
Sent: Wednesday, March 05, 2003 4:06 PM
To: Lajos Zaccomer (ETH); [email-masked]'
Subject: RE: [rohc] input bytes beyond message

Hi Zacco,	

Best regards,

Abbie