Re: [SIPPING] question on draft-johnston-sipping-cc-conferencing-00.txt

Jonathan Rosenberg <jdrosen@dynamicsoft.com> Tue, 05 November 2002 21:04 UTC

Received: via dmail-2000(11) for +imap/ietf/SIPPING; Tue, 5 Nov 2002 15:04:52 -0600 (CST)
Return-Path: <sipping-admin@ietf.org>
Received: from www1.ietf.org (ietf.org [132.151.1.19]) by bdsl.greycouncil.com (8.12.5/8.12.5) with ESMTP id gA5L4pWr006590 for <dean.willis@softarmor.com>; Tue, 5 Nov 2002 15:04:52 -0600
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA5Kf5v07864; Tue, 5 Nov 2002 15:41:05 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA5Keqv07849 for <sipping@optimus.ietf.org>; Tue, 5 Nov 2002 15:40:52 -0500
Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12519 for <sipping@ietf.org>; Tue, 5 Nov 2002 15:38:18 -0500 (EST)
Received: from dynamicsoft.com ([63.113.46.70]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gA5KelYH024892; Tue, 5 Nov 2002 15:40:47 -0500 (EST)
Message-ID: <3DC82CCD.5010109@dynamicsoft.com>
Date: Tue, 05 Nov 2002 15:40:45 -0500
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Organization: dynamicsoft
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Michael Hammer <mhammer@cisco.com>
CC: sipping@ietf.org
Subject: Re: [SIPPING] question on draft-johnston-sipping-cc-conferencing-00.txt
References: <4.3.2.7.2.20021105122704.01b07458@cia.cisco.com>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>, <mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>, <mailto:sipping-request@ietf.org?subject=subscribe>
Status: RO
X-Status:
X-Keywords:
X-UID: 3011


Michael Hammer wrote:
> In this draft the creating of a new conference and the joining of an 
> existing conference appear identical.  Given that conference servers may 
> host many conferences, and given that collision of selected identifiers 
> could occur, is there any way for a user to indicate that they wish to 
> connect to an existing conference versus creating a new one?

The draft proposes two separate URIs for creating a new conference, and 
joining an existing one. Therefore, a UA would indicate which case they 
desire by using the appropriate URI. THis presumes that there is some 
other means for propagatign those URIs. I believe the genreal model is 
that the "Conference factory URI" - used for creating conferences - 
would be learned through configuration. THe conference URI itself would 
be handed out as a result of sending an INVITE to the conference factory 
URI. You could also get one through email, IM, web links, etc., in which 
case the context is provided to the user - "click here to JOIN the 
conference".


> 
> A value such as "isnew" or "existing" could also permit, in the first 
> case, an error indicating that a conference by that name already exists, 
> or in the second case, an error indicating that a conference by that 
> name does not exist.

In the case of creation, the client does not provide the conference URI, 
it is given the conference URI by the server. So, there can never be 
collisions. In terms of trying to join a conference that doesnt exist - 
well, we have an error for that. Its 404 (Not Found).


> 
> The presumption is that you do not want to interrupt an existing 
> conference already in progress (case 1) or you do not want to create a 
> conference (and pay corresponding charges) as an invitee if the invitor 
> is not present (case 2).
> 
> Is such a protection covered elsewhere in another draft?

I dont think its needed. As above, the intent is encoded in the URI 
which is used...

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP