Subject: RE: [Sipping] I-D ACTION:draft-ietf-sipping-dialogusage-02.txt

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Wed, 28 Jun 2006 21:50:46 +0200

Hi, 

>>FIFTH, chapter 1 says that a dialog can contain only one Invute dialog
usage. But, as we agreed an Invite usage can not 
>>be created within an existing dialog (no matter what type of usages
already exist within that dialog), i.e. an Invite 
>>dialog usage can ONLY be created when the dialog itself is created,
and one dialog can ONLY contain one Invite dialog 
>>usage. So, I think we need text to clarify that. It may sound obvious,
but to avoid questions on the list in the 
>>future...
>Did we agree to that?

I'll need to check the old e-mails.

But, assuming we did NOT agree on that, are you saying that within an
existing subscribe dialog (containing one ore more subscribe usages, it
is ok to send an "initial" INVITE, containing a From AND To header tag
(isn't that considered to be a re-INVITE?), and create an invite usage?

Regards,

Christer

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 28 Jun 2006 18:28:01 -0400

> (isn't that considered to be a re-INVITE?), and create an invite usage?

My general position on this (which differs from most everybody else here 
I think) is that once you allow the sharing of dialogs at all, there are 
some general principles about how they coexist within the dialog. Once 
those are clarified its better to allow uses that fit within the general 
principles than it is to make up a bunch of exception conditions to 
disallow things that would naturally "just work" if the general 
principles are supported.

Once you have the general dialog sharing mechanisms implemented, an 
invite sent in a dialog established with subcribe, using from and to 
tags, should "just work". Rejecting it becomes an extra special case to 
be implemented.

If people attempt to figure out the specific cases of dialog sharing 
that they need to implement, and do them each as special cases, it is 
highly probably they will get it wrong.

We would have been better off if dialog sharing had never been there. 
But once there, its better cleaned up than left as a hack.

	Paul