Subject: RE: [rohc] code_len==0 in a sigcomp message's header

From: "Surtees, Abigail" <[email-masked]>
Date: Mon, 20 Mar 2006 14:37:28 -0000

Hi Cristian,
 
I'm a little confused by this question.

" SigComp NACK packets are syntactically valid SigComp messages which
   have been specifically designed to be safely ignored by
   implementations that do not support the NACK mechanism.

   In particular, NACK messages are formatted as the second variant of a
   SigComp message (typically used for code upload) with a "code_len"
   field of zero. "

If you're a version 1 (non-NACK) SigComp endpoint, then on receipt of a
NACK you will find len=0 and code_len=0 leading to decompression failure
and the message will be ignored.

If you're a version 2 (NACK) SigComp endpoint, then on receipt of a NACK
you will find len=0 and code_len=0, version=1 and pars the NACK message.

i.e. a NACK enabled SigComp endpoint WILL use the code_len field to
distinguish NACKs.

Best regards,

Abbie

> On Mon, Mar 20, 2006 at 09:56:01AM -0000, Surtees, Abigail wrote:
> > Hi Cristian,
> > 
> > Such a message would just cause decompression failure.  If 
> a non-NACK
> > message has len=0 (i.e. bytecode) and code_len=0 (i.e. no bytes of
> > bytecode) then it will load zero bytes of bytecode into the 
> UDVM, start
> > running and immediately get decompression failure because 
> the UDVM is
> > pre-loaded with zeros.
> 
> cristian: hi! 
> 
> ...and how can you tell a NACK from a non-NACK?... if not by using
> code_len?
> 
> bye now!
> cristian
> -- 
>  _          | There are many people who use UNIX or Linux  
> (_'_        | who IMHO do not understand UNIX.
>   (_'rist   |              --David Korn  
> GPG public key at wwwkeys.de.pgp.net
> 

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

---

From: Cristian CONSTANTIN <[email-masked]>
Date: Mon, 20 Mar 2006 16:58:56 +0100

> i.e. a NACK enabled SigComp endpoint WILL use the code_len field to

cristian: hi! 
o.k. thanks. 
so, the packets len==0 && code_len==0 packets are legal but not really useful.
anyway, what I do not understand here why not drop from the begining such packets 
under the assumptions of an rfc3320 only impl. (i.e.  NACK is not supported for 
one reason or another)

bye now!
cristian