Subject: Re: [rohc] AD comments on draft-ietf-rohc-sigcomp-sip-05
From: Gonzalo Camarillo <[email-masked]>
To: Gonzalo Camarillo <[email-masked]>
Cc: Magnus Westerlund <[email-masked]>, Carsten Bormann <[email-masked]>, [email-masked]
Date: Fri, 04 May 2007 21:52:20 +0300
List-Id: Robust Header Compression <rohc.ietf.org>

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

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