Re: [sipcore] Dialog state - Scope in draft-ietf-sipcore-reinvite

Hi Gonzalo,

Fisrt, I am glad to hear about this suggestion. And I once proposed the 
similar idea, as putting things which has been cleared forward, and make 
the basic rules(such as *in use* way for O/A usage, and notify way for 
remote target) as reference for other *dialog state* usages, in separate 
drafts.

Second, I once do one proposal for the other *dialog state* usages in one 
previous mail:
http://www.ietf.org/mail-archive/web/sipcore/current/msg02850.html
I think we might need several months's discussion for such topics.

Third, I suggest one expert(Gonzalo, Paul, or Robert?) to draft out one 
draft, to collect requirments for the remaining topics(the other *dialog 
state* usages's) which still need normative definition/clarification. This 
memo would have the following meanings:
1. To figure out current status of all SIP Core standard;
2. As memo of conclusions for points.
3. If someday, we need 3261bis, this might be a not bad start. 

Thanks,

Gao

===================================
 Zip    : 210012
 Tel    : 87211
 Tel2   :(+86)-025-52877211
 e_mail : gao.yang2@zte.com.cn
===================================

Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com> 
发件人:  sipcore-bounces@ietf.org
2010-07-05 14:34

收件人
SIPCORE <sipcore@ietf.org>
抄送

主题
[sipcore] Dialog state - Scope in draft-ietf-sipcore-reinvite

Hi,

the re-INVITE draft talks about modifications in the session state,
dialog state, and the dialog's remote target. While it is relatively
well understood what we mean by session state and the dialog's remote
target, we do not really have a good definition for dialog state.

We have discussed it in the past and what people had in mind were things
such as called party identity. However, the draft is too vague at this
point; it should be more precise regarding which piece of "dialog state"
the rules in the draft apply to.

My suggestion would be to have the draft talk only about session state
and the dialog's remote target, and forget about any other dialog state.
New extensions whose parameters can be modified by re-INVITEs can
specify their own rules, possibly referring to this draft and using the
rules defined in it by reference. In this way, the applicability of this
draft would be much clearer.

Comments?

Thanks,

Gonzalo

_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore

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