Document: draft-ietf-rohc-sigcomp-sip-06.txt
Reviewer: Robert Sparks
Review Date: 5/30/07
IETF LC End Date: 5/29/07
IESG Telechat date: 6/7/07

Summary: This draft is ready for publication as a Proposed Standard RFC.
         There are some small nits the submitters and IESG may wish to
         consider addressing before publication.

Comments:

1) Section 8 mislead me (an experienced person in these technologies) 
   into misinterpreting what it was saying. My misinterpretation was 
   that it was preventing SIP retransmissions. Its
   intent was to note that any retransmission had to be recompressed, 
   that it was not valid to cache a previous compression and retransmit 
   that. The following text was suggested as a replacement:

    "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."


2) 9.4 discusses drawbacks of stateless compression and states that
     if a compartment is not available, that the application MAY choose
     not to compress a given message (putting some non-normative 
     pressure on applications to choose not to do so).  Section 5, 
     however notes that you cannot mix SIP messages and SigComp 
     messages on any given TCP stream and calls out a null decompression 
     algorithm to use to effectively send a "compressed" message that 
     isn't compressed. I think
     section 9.4 should explicitly call back to this this case to help 
     avoid implementor confusion.

3) I have personal heartburn with the decision in the document to scope
     the use of SigComp in SIP to only those cases where registration 
     state is being maintained. There is no way for endpoints that,
     for instance, only publish or subscribe to use SigComp the way 
     this document is written.  That said, there is real complexity 
     in providing a mechanism that works outside a context like 
     registration, and there is, per the submitters, working
     group consensus around this restriction. I suggest adding a paragraph
     explicitly calling out this restriction and briefly discussing 
     why the group decided to accept it.