Subject: Re: [sipcore] The semantics of Require.

From: [email-masked]
Date: Tue, 27 Apr 2010 12:53:01 +0800

Hi,

There's one exception of my analysis. That is the option-tag's definition 
itself has behavior specification.

Then I re-read 100rel's definition. It seems is in this class. 

Name: 100rel

      Description: This option tag is for reliability of provisional
         responses.  When present in a Supported header, it indicates
         that the UA can send or receive reliable provisional responses.
         When present in a Require header in a request, it indicates
         that the UAS MUST send all provisional responses reliably.
         When present in a Require header in a reliable provisional
         response, it indicates that the response is to be sent
         reliably.

It is a mess from defintion aspect. But it might be right.

Thanks,

Gao 

===================================
 Zip    : 210012
 Tel    : 87211
 Tel2   :(+86)-025-52877211
 e_mail : [email-masked]
===================================
----- 转发人 GaoYang140197/user/zte_ltd 时间 2010-04-27 12:16 -----

GaoYang140197/user/zte_ltd
2010-04-27 12:02

收件人
Paul Kyzivat <[email-masked]>
抄送
Christer Holmberg <[email-masked]>, "[email-masked]" 
<[email-masked]>
主题
Re: [sipcore] The semantics of Require.

Hi Paul,

Yes. Under semantic analysis, Require(from UAC) only means the demand of 
UAS's capability.

To expressing the semantics of demanding UAS's specific behavior (in 
specific conditions) needs something new. Relating, if UAS want the UAC's 
specific behavior (in specific conditions) should use the same *new 
header*, Require is not proper. So, Require 100rel from both UAC and UAS 
is misapplication.

And it seams that we should clarify that we haven't had tool with the 
semantics of demanding the peer's specific behavior (in specific 
conditions). But I prefer there's no correction for RFC3262 just for this 
reason.

Thanks,

Gao 

> If this discussion is to continue, can we at least have a relevant 
> subject rather than hijacking the discussion options ping?
> 
> I agree in principle with Dean's point. But from a practical perspective 

> I think we just acknowledge that the definition of certain options added 

> on additional semantics. I think we should just grandfather that but 
> refrain from making the same mistake in the future.
> 
>    Thanks,
>    Paul
> 

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.