[rohc] sigcomp-sip: David Ward's DISCUSS

ROHCers,

David Ward, RTG AD, has put in a DISCUSS on draft-ietf-rohc-sigcomp- 
sip-07.txt, which reads:

> 3320 section 8.7 (Decompression failures)
>
> "If a decompression failure occurs when decompressing a message then
>   the UDVM informs the dispatcher and takes no further action.  It is
>   the responsibility of the dispatcher to decide how to cope with the
>   decompression failure.  In general a dispatcher SHOULD discard the
>   compressed message (or the compressed stream if the transport is
>   stream-based) and any decompressed data that has been outputted but
>   not yet passed to the application.
> "
>
> and in this draft there is no mention of how SIP should handle  
> decompression failures

 From my point of view (having been involved in this from day 1),  
this is nicely covered by section 8:

> 8.  SIP Retransmissions
>
>    When SIP messages are retransmitted, they need to be re-compressed,
>    taking into account any SigComp states that may have been  
> created or
>    invalidated since the previous transmission.  Implementations MUST
>    NOT cache the result of compressing the message and retransmit  
> such a
>    cached result.
>
>    The reason for this behavior is that it is impossible to know  
> whether
>    the failure causing the retransmission occurred on the message  
> being
>    retransmitted or on the response to that message.  If the response
>    was lost, any state changes effected by the first instance of the
>    retransmitted message would already have taken place.  If these  
> state
>    changes removed a state that the previously-transmitted message
>    relied upon, then retransmission of the same compressed message  
> would
>    lead to a decompression failure.

However, this may be a bit opaque to people new to this set of  
documents.
Also, the discussion of NACK in the draft only relates to SigComp  
state; it could mention that NACK (now being mandatory) is the  
general way to handle decompression failure.

All of this is editorial, I think, but I also think it would be nice  
not to entirely rely on the reader making the connections.
Any opinions?  I could go ahead and draft some text.

Gruesse, Carsten

_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc