Subject: Re: [rohc] AD comments on draft-ietf-rohc-sigcomp-sip-05

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 03 May 2007 13:55:31 +0300

Hi,

yes, the reason behind using 'must' was what Miguel Angel explained. 
Good to see that we are on the same page on this one.

Cheers,

Gonzalo

Magnus Westerlund wrote:
> Miguel Garcia skrev:
>>
>>
>> Magnus Westerlund wrote:
>>  > Miguel Garcia skrev:
>>  >>
>>  >>
>>  >> Magnus Westerlund wrote:
>>  >>  > Hi,
>>  >>  >
>>  >>  > I have now reviewed the SigComp draft and a have a few comments.
>>  >>  >
>>  >>  > 1. Section 3.
>>  >>  >
>>  >>  >    Additionally, it must support the SIP/SDP static dictionary, as
>>  >>  >    specified in [RFC3485], and the mechanism for discovering 
>> SigComp
>>  >>  >    support at the SIP layer, as specified in [RFC3486].
>>  >>  >
>>  >>  > Shouldn't the "must" in the above sentence be "MUST"?
>>  >>
>>  >> That "MUST" is already written in RFC 3485 and RFC 3486, 
>> respectively,
>>  >> so, in my opinion, the "must" is correct, especially since the text
>>  >> refers to both canonical specifications RFC 3485 and RFC 3486.
>>  >>
>>  >
>>  > Now you get me confused. Isn't this document the one intended to be 
>> the
>>  > root document for anyone implementing sigcomp for SIP? In that case it
>>  > seems necessary for this document to have a normative statement saying
>>  > that you shall implement RFC 3485 and RFC 3486. It doesn't matter if
>>  > these document are within themselves saying what feature to implement.
>>  >
>>
>> Yes and no. I don't think it makes sense to have two equal normative
>> statements in different documents, a technique commonly known as
>> overspecifying. Remember that no matter whether you have
>> draft-ietf-rohc-sigcomp-sip-05 or not, the MUST implement RFC 3485 and
>> 3486 remain in their respective documents.
>>
>> Thus, I am fine with the current wording. It could be rewording in
>> different words, for example: "Notice that RFC 3485 and RC 3486 already
>> mandate the implementations.... " But this is just a matter of taste.
>>
> 
> Okay, based on that wording in RFC 3485 and 3486 can't be changed I am 
> fine with the current wording.
> 
> What about question 2?
> 
> Cheers
> 
> Magnus Westerlund
> 
> IETF Transport Area Director & TSVWG Chair
> ----------------------------------------------------------------------
> Multimedia Technologies, Ericsson Research EAB/TVM/M
> ----------------------------------------------------------------------
> Ericsson AB                | Phone +46 8 4048287
> Torshamsgatan 23           | Fax   +46 8 7575550
> S-164 80 Stockholm, Sweden | mailto: [email-masked]
> ----------------------------------------------------------------------
> 
> _______________________________________________
> Rohc mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/rohc
> 

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

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 03 May 2007 13:56:42 +0300

Hi,

I am working with Adam on crafting some text to address that issue. I 
will be submitting a new revision of the draft shortly.

Cheers,

Gonzalo

Magnus Westerlund wrote:
> Carsten Bormann skrev:
>>
>>
>>  > 2. Section 5. Last paragraph:
>>  >
>>  > Should it for any reason not be desirable to set up
>>  >    more than one TCP connection to a SIP implementation, but the
>>  >    flexibility to send both compressed and uncompressed SIP  > 
>> messages be
>>  >    required, the compressor can set up a SigComp-structured connection
>>  >    and send any uncompressed SIP messages using the well-known shim
>>  >    header.
>>  >
>>  > What is "SigComp-structured connection"? A reference to where this 
>>  > is specified might be a good idea.
>>
>> This is referring to a TCP connection that uses SigComp (as opposed to 
>> raw SIP).
>> The "structured" here pertains to the fact that SigComp imposes a 
>> (record marking) structure, but this is not really the point; the 
>> point is that this is a TCP connection carrying SigComp compressed 
>> messages, but saying "compressed" is a bit confusing as we are talking 
>> about uncompressed messages carried in a SigComp compression shim.
>>
>> Maybe just s/-structured// to solve this little semantic problem.
>>
> 
> Yes, that is likely to reduce confusion that the reader has missed 
> something.
> 
> Please submit an updated version.
> 
> Cheers
> 
> Magnus Westerlund
>

---

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 04 May 2007 21:52:20 +0300

Hi,

we suggest to replace the paragraph under discussion with the following one:

    Section 11 of [RFC4896] details a simple set of bytecodes, intended
    to be "well-known", that implement a null decompression algorithm.
    These bytecodes effectively allow SigComp peers to send selected
    SigComp messages with uncompressed data. If a SIP implementation has
    reason to send both compressed and uncompressed SIP messages on a
    single TCP connection, the compressor can be instructed to use these
    bytecodes to send uncompressed SIP messages that are also valid
    SigComp messages.

RFC 4896 is the implementors guide.

If nobody objects to this change, which does not introduce any new 
terminology people may not be familiar with, I will revise the draft 
accordingly.

Cheers,

Gonzalo

Gonzalo Camarillo wrote:
>>> This is referring to a TCP connection that uses SigComp (as opposed 
>>> to raw SIP).
>>> messages, but saying "compressed" is a bit confusing as we are 
>>> talking about uncompressed messages carried in a SigComp compression 
>>> shim.
>>>