RE: [rohc] input bytes beyond message

["Surtees, Abigail" <abigail.surtees@roke.co.uk>]

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:
>	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
>Rohc@ietf.org
>https://www1.ietf.org/mailman/listinfo/rohc
>
_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc