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

From: Magnus Westerlund <[email-masked]>
Date: Tue, 10 Apr 2007 11:06:50 +0200

Hi,

I am still waiting for a response on my second question.

/Magnus

Magnus Westerlund skrev:
> 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
> 

-- 

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

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 10 Apr 2007 12:15:33 +0300

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

Gruesse, Carsten

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 11 Apr 2007 14:41:52 +0200

> 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