From exim@www1.ietf.org Mon Dec 1 07:28:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07575 for ; Mon, 1 Dec 2003 07:28:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQn9n-0001dQ-HD for xcon-archive@odin.ietf.org; Mon, 01 Dec 2003 07:28:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB1CS34i006270 for xcon-archive@odin.ietf.org; Mon, 1 Dec 2003 07:28:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQn9n-0001cb-96 for xcon-web-archive@optimus.ietf.org; Mon, 01 Dec 2003 07:28:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07572 for ; Mon, 1 Dec 2003 07:27:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQn9m-0000a9-00 for xcon-web-archive@ietf.org; Mon, 01 Dec 2003 07:28:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AQn9m-0000a6-00 for xcon-web-archive@ietf.org; Mon, 01 Dec 2003 07:28:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQn9l-0001ZS-4O; Mon, 01 Dec 2003 07:28:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQn8u-0001Tk-3K for xcon@optimus.ietf.org; Mon, 01 Dec 2003 07:27:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07541 for ; Mon, 1 Dec 2003 07:26:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQn8t-0000ZC-00 for xcon@ietf.org; Mon, 01 Dec 2003 07:27:07 -0500 Received: from mtagate7.de.ibm.com ([195.212.29.156]) by ietf-mx with esmtp (Exim 4.12) id 1AQn8s-0000YS-00 for xcon@ietf.org; Mon, 01 Dec 2003 07:27:06 -0500 Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196] (may be forged)) by mtagate7.de.ibm.com (8.12.10/8.12.10) with ESMTP id hB1CQMwj130050 for ; Mon, 1 Dec 2003 12:26:22 GMT Received: from d10ml001.telaviv.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12relay02.megacenter.de.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id hB1CQLtX286292 for ; Mon, 1 Dec 2003 13:26:22 +0100 In-Reply-To: To: xcon@ietf.org Subject: RE: [XCON] CPCP - making something simple that works MIME-Version: 1.0 X-Mailer: Lotus Notes Build V65_07292003 July 29, 2003 Message-ID: From: Avshalom Houri Date: Mon, 1 Dec 2003 14:26:22 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 6.0.2CF2|July 23, 2003) at 01/12/2003 14:26:21, Serialize complete at 01/12/2003 14:26:21 Content-Type: multipart/alternative; boundary="=_alternative 00445204C2256DEF_=" Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , This is a multipart message in MIME format. --=_alternative 00445204C2256DEF_= Content-Type: text/plain; charset="US-ASCII" I think that expelling users is more often used in open communities as IRC and rarely (if ever) used in enterprise conferences. I agree that we should define a minimal set of features for the first version of CPCP but the main question will be how we make sure that it is extendable. If we find a good way to extend, the initial set of features will be less important. Avshalom Markus.Isomaki@nokia.com Sent by: xcon-admin@ietf.org 30/11/2003 11:49 PM To , cc Subject RE: [XCON] CPCP - making something simple that works Hi, There is one use scenario for CPCP where the capability to expell seems necessary. I would like to build with SIP, MSRP and CPCP a "text chatroom" service similar to something like what is available in IRC, Jabber or Wireless Village. My understanding is that in those kind of services expelling users is something which is actually used. On the other hand, if you can do the same thing (for one participant at a time) with SIP REFER, expelling may not be needed in the initial set of CPCP features. Mass-expel is probably not used that much. Markus > -----Original Message----- > From: ext Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: 30 November, 2003 21:28 > To: Khartabil Hisham (NMP-MSW/Helsinki) > Cc: Isomaki Markus (NRC/Helsinki); xcon@ietf.org > Subject: Re: [XCON] CPCP - making something simple that works > > > > > I believe timing is important and is one major advantage of > CPCP over > > ad-hoc conferences. > > Note, however, that this can easily be done by an external > application > that uses a normal calendaring mechanism (such as the iCal extensions > for events) and then generates CPCP requests. Having a very simple > single start/end-time (no repeats) is sufficient for that and > does not > add significant complexity. > > > > > What about security of the conference? is that a priority? How > > desides on the level of security and what protocol to use? who sets > > the password for the conference? I am ok with having a default > > authentication mechanism like digest for joining a conference. > > I would find it peculiar if joining a conference required > anything other > than a standard SIP client, for example. > > > > > There is also the issue of expelling users. What is the opinion on > > that? Is it important? > > I have never seen that be used in real conferences, even where the > feature was available. If this is a rather rare event, it is > easier to > create a new conference without the offending user and have everyone > minus one move to the new conference. The much more common > case is the > executive session (or the jury session, e.g., for a thesis defense), > which seems most readily modeled as two sessions with distinct > participants, set up from the beginning. > > The problem with expelling is that this adds the risk of accidental > invocation and probably does not deal with the full range of Robert's > Rules stipulations and procedures. > > I think a natural threshold for initial inclusion is common usage in > today's conferencing systems. > > Henning > _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon --=_alternative 00445204C2256DEF_= Content-Type: text/html; charset="US-ASCII"
I think that expelling users is more often used in open communities as IRC and rarely
(if ever) used in enterprise conferences.
I agree that we should define a minimal set of features for the first version of CPCP but the main question will be
how we make sure that it is extendable. If we find a good way to extend, the initial set of features will be less important.

Avshalom



Markus.Isomaki@nokia.com
Sent by: xcon-admin@ietf.org

30/11/2003 11:49 PM

To
<hgs@cs.columbia.edu>, <hisham.khartabil@nokia.com>
cc
<xcon@ietf.org>
Subject
RE: [XCON] CPCP - making something simple that works





Hi,

There is one use scenario for CPCP where the capability to expell seems necessary. I would like to build with SIP, MSRP and CPCP a "text chatroom" service similar to something like what is available in IRC, Jabber or Wireless Village. My understanding is that in those kind of services expelling users is something which is actually used.

On the other hand, if you can do the same thing (for one participant at a time) with SIP REFER, expelling may not be needed in the initial set of CPCP features. Mass-expel is probably not used that much.

Markus  

> -----Original Message-----
> From: ext Henning Schulzrinne [mailto:hgs@cs.columbia.edu]
> Sent: 30 November, 2003 21:28
> To: Khartabil Hisham (NMP-MSW/Helsinki)
> Cc: Isomaki Markus (NRC/Helsinki); xcon@ietf.org
> Subject: Re: [XCON] CPCP - making something simple that works
>
>
>
> > I believe timing is important and is one major advantage of
> CPCP over
> > ad-hoc conferences.
>
> Note, however, that this can easily be done by an external
> application
> that uses a normal calendaring mechanism (such as the iCal extensions
> for events) and then generates CPCP requests. Having a very simple
> single start/end-time (no repeats) is sufficient for that and
> does not
> add significant complexity.
>
> >
> > What about security of the conference? is that a priority? How
> > desides on the level of security and what protocol to use? who sets
> > the password for the conference? I am ok with having a default
> > authentication mechanism like digest for joining a conference.
>
> I would find it peculiar if joining a conference required
> anything other
> than a standard SIP client, for example.
>
> >
> > There is also the issue of expelling users. What is the opinion on
> > that? Is it important?
>
> I have never seen that be used in real conferences, even where the
> feature was available. If this is a rather rare event, it is
> easier to
> create a new conference without the offending user and have everyone
> minus one move to the new conference. The much more common
> case is the
> executive session (or the jury session, e.g., for a thesis defense),
> which seems most readily modeled as two sessions with distinct
> participants, set up from the beginning.
>
> The problem with expelling is that this adds the risk of accidental
> invocation and probably does not deal with the full range of Robert's
> Rules stipulations and procedures.
>
> I think a natural threshold for initial inclusion is common usage in
> today's conferencing systems.
>
> Henning
>

_______________________________________________
XCON mailing list
XCON@ietf.org
https://www1.ietf.org/mailman/listinfo/xcon
--=_alternative 00445204C2256DEF_=-- _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Mon Dec 1 10:45:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15499 for ; Mon, 1 Dec 2003 10:45:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQqET-0006kE-Qd for xcon-archive@odin.ietf.org; Mon, 01 Dec 2003 10:45:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB1Fj5MI025922 for xcon-archive@odin.ietf.org; Mon, 1 Dec 2003 10:45:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQqET-0006k1-Kf for xcon-web-archive@optimus.ietf.org; Mon, 01 Dec 2003 10:45:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15482 for ; Mon, 1 Dec 2003 10:44:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQqER-0003WI-00 for xcon-web-archive@ietf.org; Mon, 01 Dec 2003 10:45:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AQqEQ-0003WF-00 for xcon-web-archive@ietf.org; Mon, 01 Dec 2003 10:45:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQqEP-0006jM-Qe; Mon, 01 Dec 2003 10:45:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQqDh-0006g7-JM for xcon@optimus.ietf.org; Mon, 01 Dec 2003 10:44:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15419 for ; Mon, 1 Dec 2003 10:44:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQqDd-0003Vm-00 for xcon@ietf.org; Mon, 01 Dec 2003 10:44:13 -0500 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 1AQqDd-0003V5-00 for xcon@ietf.org; Mon, 01 Dec 2003 10:44:13 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA28113; Mon, 1 Dec 2003 10:43:39 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA20894; Mon, 1 Dec 2003 10:43:40 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Mon, 1 Dec 2003 10:43:40 -0500 Message-ID: <313680C9A886D511A06000204840E1CF070B6136@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'georg.mayer@nokia.com'" Cc: xcon@ietf.org Subject: RE: [XCON] CPCP requirements to support IMS Date: Mon, 1 Dec 2003 10:43:39 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , > a) there may be different conferece factory URIs for > different types of conferences (e.g. for some only a > restricted number of participants might be allowed, etc.) There might be more than one conference factory uri, but I think that is because there might be more than one conference service available to you. The example you give is not correct, as you would use CPCP to control the number of allowed participants. > > b) if no conference resources have been reserved up till now > (i.e. if there is no participant in the conference) from the > users point of view the result of sending an INVITE with a > conference factory URI or a conference URI is identical. Of > course in the case of the factory URI, the conference URI is > first created, but afterwards the conference resources are > reserved and the user becomes the first participant in it. No, this is not my understanding. You don't get a conference by calling the conference factory uri, you only get a Contact with the conference uri. Nothing happens until you call the conference uri. You could gave some resources reserved prior to actually starting the conference, but that comes as a result of using CPCP on the conference URI that you get from the conference factory. When you call the conference URI, the conference "starts" (although conferencing with one user is not a conference, right? And you may only get music on hold until the "organizer" arrives). So, they are not at all the same. > > What I meant in my mails before was, that the user should get > via CPCP aware of a URI that finally allows him to join the > conference and automatically reserve the resources for it. No, I don't thing CPCP will give you the conference URI. You need the conference URI in order to use CPCP. You get the conference URI from the conference factory, from a REFER, from an INVITE (in the case of a dial out conference) or possibly some out-of-band mechanism. In the latter cases, it will usually be the case that one participant (the conference organizer) obtains the conference uri from the conference factory uri. Thereafter, she will arrange to give other participants the conference uri she gets from the conference factory via REFER, or manipulating CPCP to cause an INVITE, or by email :). You might also generate a conference URI from a web page (as opposed to the conference factory uri), or your calendar program, but those are out of scope of our work. _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Mon Dec 1 11:00:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16019 for ; Mon, 1 Dec 2003 11:00:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQqT0-0007L2-10 for xcon-archive@odin.ietf.org; Mon, 01 Dec 2003 11:00:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB1G05pi028209 for xcon-archive@odin.ietf.org; Mon, 1 Dec 2003 11:00:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQqSx-0007Kj-Lx for xcon-web-archive@optimus.ietf.org; Mon, 01 Dec 2003 11:00:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15982 for ; Mon, 1 Dec 2003 10:59:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQqSv-0003lk-00 for xcon-web-archive@ietf.org; Mon, 01 Dec 2003 11:00:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AQqSu-0003lf-00 for xcon-web-archive@ietf.org; Mon, 01 Dec 2003 11:00:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQqSv-0007K4-Ca; Mon, 01 Dec 2003 11:00:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQqS8-0007Ig-Ub for xcon@optimus.ietf.org; Mon, 01 Dec 2003 10:59:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15962 for ; Mon, 1 Dec 2003 10:58:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQqS3-0003l5-00 for xcon@ietf.org; Mon, 01 Dec 2003 10:59:07 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1AQqS2-0003kt-00 for xcon@ietf.org; Mon, 01 Dec 2003 10:59:06 -0500 Received: from cisco.com (64.102.124.12) by sj-iport-5.cisco.com with ESMTP; 01 Dec 2003 07:58:09 -0800 Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hB1FwUxi017862; Mon, 1 Dec 2003 10:58:32 -0500 (EST) Received: from mhammer-w2k03.cisco.com (dhcp-hrn-64-100-229-166.cisco.com [64.100.229.166]) by fruitpie.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AVH84939; Mon, 1 Dec 2003 07:58:30 -0800 (PST) Message-Id: <4.3.2.7.2.20031201105417.00b17068@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 01 Dec 2003 10:58:29 -0500 To: Henning Schulzrinne From: Michael Hammer Subject: Re: [XCON] CPCP - making something simple that works Cc: hisham.khartabil@nokia.com, Markus.Isomaki@nokia.com, xcon@ietf.org In-Reply-To: <3FCA44AC.1000305@cs.columbia.edu> References: <2038BCC78B1AD641891A0D1AE133DBB70118B10F@esebe019.ntc.nokia.com> <2038BCC78B1AD641891A0D1AE133DBB70118B10F@esebe019.ntc.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , Henning, I can name two cases where explicitly expelling someone is useful: 1) An enterprise conference is discussing company sensitive material of economic value and someone manages to join and refused to identify themselves, 2) Someone on the conference puts it on hold improperly and plays music on hold to the conference. Both of these happen frequently enough that an ability to eject the offending user is desirable and more preferable to wasting time getting everyone to move on to another conference. It shouldn't be necessary to get hold of a moderator to do the expelling. Mike At 02:27 PM 11/30/2003 -0500, Henning Schulzrinne wrote: >>I believe timing is important and is one major advantage of CPCP over >>ad-hoc conferences. > >Note, however, that this can easily be done by an external application >that uses a normal calendaring mechanism (such as the iCal extensions for >events) and then generates CPCP requests. Having a very simple single >start/end-time (no repeats) is sufficient for that and does not add >significant complexity. > >>What about security of the conference? is that a priority? How >>desides on the level of security and what protocol to use? who sets >>the password for the conference? I am ok with having a default >>authentication mechanism like digest for joining a conference. > >I would find it peculiar if joining a conference required anything other >than a standard SIP client, for example. > >>There is also the issue of expelling users. What is the opinion on >>that? Is it important? > >I have never seen that be used in real conferences, even where the feature >was available. If this is a rather rare event, it is easier to create a >new conference without the offending user and have everyone minus one move >to the new conference. The much more common case is the executive session >(or the jury session, e.g., for a thesis defense), which seems most >readily modeled as two sessions with distinct participants, set up from >the beginning. > >The problem with expelling is that this adds the risk of accidental >invocation and probably does not deal with the full range of Robert's >Rules stipulations and procedures. > >I think a natural threshold for initial inclusion is common usage in >today's conferencing systems. > >Henning > >_______________________________________________ >XCON mailing list >XCON@ietf.org >https://www1.ietf.org/mailman/listinfo/xcon _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Mon Dec 1 12:22:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18585 for ; Mon, 1 Dec 2003 12:22:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQrkP-0003LE-7l for xcon-archive@odin.ietf.org; Mon, 01 Dec 2003 12:22:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB1HM9tI012838 for xcon-archive@odin.ietf.org; Mon, 1 Dec 2003 12:22:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQrkP-0003Kz-0a for xcon-web-archive@optimus.ietf.org; Mon, 01 Dec 2003 12:22:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18572 for ; Mon, 1 Dec 2003 12:21:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQrkN-0005Y9-00 for xcon-web-archive@ietf.org; Mon, 01 Dec 2003 12:22:07 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AQrkN-0005Y5-00 for xcon-web-archive@ietf.org; Mon, 01 Dec 2003 12:22:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQrkG-0003KI-Kn; Mon, 01 Dec 2003 12:22:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQrjm-0003JN-QG for xcon@optimus.ietf.org; Mon, 01 Dec 2003 12:21:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18511 for ; Mon, 1 Dec 2003 12:21:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQrjl-0005XC-00 for xcon@ietf.org; Mon, 01 Dec 2003 12:21:29 -0500 Received: from goliath.siemens.de ([192.35.17.28]) by ietf-mx with esmtp (Exim 4.12) id 1AQrjk-0005WU-00 for xcon@ietf.org; Mon, 01 Dec 2003 12:21:28 -0500 Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by goliath.siemens.de (8.11.7/8.11.7) with ESMTP id hB1HKPY27522; Mon, 1 Dec 2003 18:20:25 +0100 (MET) Received: from moody.mchh.siemens.de (moody.mchh.siemens.de [139.21.205.85]) by mail2.siemens.de (8.11.7/8.11.7) with ESMTP id hB1HKOP04816; Mon, 1 Dec 2003 18:20:25 +0100 (MET) Received: from mchh248e.mchh.siemens.de (mchh248e.mchh.siemens.de [139.21.200.58]) by moody.mchh.siemens.de (8.9.3/8.9.1) with ESMTP id SAA25608; Mon, 1 Dec 2003 18:20:24 +0100 (MET) Received: by mchh248e.mchh.siemens.de with Internet Mail Service (5.5.2653.19) id ; Mon, 1 Dec 2003 18:20:22 +0100 Message-ID: <76592C4D3DA1AC4FB8424084D10D31A8D5CE62@mchh2c4e.mchh.siemens.de> From: Heil Franca Marcelo To: "'Rosen, Brian'" , "'georg.mayer@nokia.com'" Cc: xcon@ietf.org Subject: AW: [XCON] CPCP requirements to support IMS Date: Mon, 1 Dec 2003 18:20:20 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , Brian, Georg, Please see my comments inline. Marcelo > > > a) there may be different conferece factory URIs for > > different types of conferences (e.g. for some only a > > restricted number of participants might be allowed, etc.) > There might be more than one conference factory uri, but I think > that is because there might be more than one conference service > available to you. The example you give is not correct, > as you would use CPCP to control the number of allowed participants. > > > > > b) if no conference resources have been reserved up till now > > (i.e. if there is no participant in the conference) from the > > users point of view the result of sending an INVITE with a > > conference factory URI or a conference URI is identical. Of > > course in the case of the factory URI, the conference URI is > > first created, but afterwards the conference resources are > > reserved and the user becomes the first participant in it. > No, this is not my understanding. > > You don't get a conference by calling the conference factory uri, > you only get a Contact with the conference uri. Nothing happens > until you call the conference uri. You could gave some > resources reserved prior to actually starting the conference, > but that comes as a result of using CPCP on the conference URI > that you get from the conference factory. When you call the > conference URI, the conference "starts" (although conferencing > with one user is not a conference, right? And you may only get > music on hold until the "organizer" arrives). > > So, they are not at all the same. I see no reason why a conference cannot be created by a conference server when a request (INVITE) addressed to the conference-factory-URI is received (on an ad-hoc basis). The conference-URI generated for the conference is returned in the 200 OK response, and, at this time, the conference already started and the requesting UA is already taking part on it. > > > > What I meant in my mails before was, that the user should get > > via CPCP aware of a URI that finally allows him to join the > > conference and automatically reserve the resources for it. > No, I don't thing CPCP will give you the conference URI. You need > the conference URI in order to use CPCP. You get the conference > URI from the conference factory, from a REFER, from an INVITE (in > the case of a dial out conference) or possibly some out-of-band > mechanism. > If you use CPCP to create a conference, you will get the conference URI back upon successful creation. > In the latter cases, it will usually be the case that one participant > (the conference organizer) obtains the conference uri from the > conference factory uri. Thereafter, she will arrange to give > other participants the conference uri she gets from the conference > factory via REFER, or manipulating CPCP to cause an INVITE, or > by email :). You might also generate a conference URI from a > web page (as opposed to the conference factory uri), or your calendar > program, but those are out of scope of our work. > > > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon > _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Mon Dec 1 13:14:18 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20576 for ; Mon, 1 Dec 2003 13:14:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQsYc-00075R-Rq for xcon-archive@odin.ietf.org; Mon, 01 Dec 2003 13:14:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB1IE2Ir027233 for xcon-archive@odin.ietf.org; Mon, 1 Dec 2003 13:14:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQsYc-000758-Eg for xcon-web-archive@optimus.ietf.org; Mon, 01 Dec 2003 13:14:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20553 for ; Mon, 1 Dec 2003 13:13:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQsYa-00069h-00 for xcon-web-archive@ietf.org; Mon, 01 Dec 2003 13:14:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AQsYa-00069e-00 for xcon-web-archive@ietf.org; Mon, 01 Dec 2003 13:14:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQsYa-00074f-Mj; Mon, 01 Dec 2003 13:14:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQsXc-0006ts-V9 for xcon@optimus.ietf.org; Mon, 01 Dec 2003 13:13:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20481 for ; Mon, 1 Dec 2003 13:12:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQsXb-00067g-00 for xcon@ietf.org; Mon, 01 Dec 2003 13:12:59 -0500 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 1AQsXa-00067N-00 for xcon@ietf.org; Mon, 01 Dec 2003 13:12:58 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA04405; Mon, 1 Dec 2003 13:12:23 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA16740; Mon, 1 Dec 2003 13:12:25 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Mon, 1 Dec 2003 13:12:24 -0500 Message-ID: <313680C9A886D511A06000204840E1CF070B6137@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Heil Franca Marcelo'" , "'georg.mayer@nokia.com'" Cc: xcon@ietf.org Subject: RE: [XCON] CPCP requirements to support IMS Date: Mon, 1 Dec 2003 13:12:22 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , Of course, there is no right or wrong here, but I would prefer that the conference factory URI never actually create a conference. Among other things, a single conference factory URI may "front" a number of entities that provide the focus function, and the conference factory would create a conference uri on the appropriate entity in order to do things like load balance. I also appear to be mistaked in that CPCP can be used to create a conference. We might want to revisit this, as in general, it's not a good idea to have two ways to do the same thing. I'm going to start a new thread on this one. Brian > -----Original Message----- > From: Heil Franca Marcelo [mailto:marcelo.heil_franca@siemens.com] > Sent: Monday, December 01, 2003 12:20 PM > To: 'Rosen, Brian'; 'georg.mayer@nokia.com' > Cc: xcon@ietf.org > Subject: AW: [XCON] CPCP requirements to support IMS > > > Brian, Georg, > > Please see my comments inline. > > Marcelo > > > > > a) there may be different conferece factory URIs for > > > different types of conferences (e.g. for some only a > > > restricted number of participants might be allowed, etc.) > > There might be more than one conference factory uri, but I think > > that is because there might be more than one conference service > > available to you. The example you give is not correct, > > as you would use CPCP to control the number of allowed participants. > > > > > > > > b) if no conference resources have been reserved up till now > > > (i.e. if there is no participant in the conference) from the > > > users point of view the result of sending an INVITE with a > > > conference factory URI or a conference URI is identical. Of > > > course in the case of the factory URI, the conference URI is > > > first created, but afterwards the conference resources are > > > reserved and the user becomes the first participant in it. > > No, this is not my understanding. > > > > You don't get a conference by calling the conference factory uri, > > you only get a Contact with the conference uri. Nothing happens > > until you call the conference uri. You could gave some > > resources reserved prior to actually starting the conference, > > but that comes as a result of using CPCP on the conference URI > > that you get from the conference factory. When you call the > > conference URI, the conference "starts" (although conferencing > > with one user is not a conference, right? And you may only get > > music on hold until the "organizer" arrives). > > > > So, they are not at all the same. > > I see no reason why a conference cannot be created by a > conference server when a request (INVITE) addressed to the > conference-factory-URI is received (on an ad-hoc basis). The > conference-URI generated for the conference is returned in > the 200 OK response, and, at this time, the conference > already started and the requesting UA is already taking part on it. > > > > > > > > What I meant in my mails before was, that the user should get > > > via CPCP aware of a URI that finally allows him to join the > > > conference and automatically reserve the resources for it. > > No, I don't thing CPCP will give you the conference URI. You need > > the conference URI in order to use CPCP. You get the conference > > URI from the conference factory, from a REFER, from an INVITE (in > > the case of a dial out conference) or possibly some out-of-band > > mechanism. > > > > If you use CPCP to create a conference, you will get the > conference URI back upon successful creation. > > > In the latter cases, it will usually be the case that one > participant > > (the conference organizer) obtains the conference uri from the > > conference factory uri. Thereafter, she will arrange to give > > other participants the conference uri she gets from the conference > > factory via REFER, or manipulating CPCP to cause an INVITE, or > > by email :). You might also generate a conference URI from a > > web page (as opposed to the conference factory uri), or > your calendar > > program, but those are out of scope of our work. > > > > > > _______________________________________________ > > XCON mailing list > > XCON@ietf.org > > https://www1.ietf.org/mailman/listinfo/xcon > > > > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon > _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Mon Dec 1 13:27:18 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21464 for ; Mon, 1 Dec 2003 13:27:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQslD-0008LF-KJ for xcon-archive@odin.ietf.org; Mon, 01 Dec 2003 13:27:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB1IR3sB032059 for xcon-archive@odin.ietf.org; Mon, 1 Dec 2003 13:27:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQslD-0008L0-EU for xcon-web-archive@optimus.ietf.org; Mon, 01 Dec 2003 13:27:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21455 for ; Mon, 1 Dec 2003 13:26:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQslB-0006NC-00 for xcon-web-archive@ietf.org; Mon, 01 Dec 2003 13:27:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AQslA-0006N8-00 for xcon-web-archive@ietf.org; Mon, 01 Dec 2003 13:27:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQslB-0008KW-0l; Mon, 01 Dec 2003 13:27:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQsl9-0008KF-Jj for xcon@optimus.ietf.org; Mon, 01 Dec 2003 13:26:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21444 for ; Mon, 1 Dec 2003 13:26:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQsl7-0006My-00 for xcon@ietf.org; Mon, 01 Dec 2003 13:26:57 -0500 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 1AQsl6-0006Mf-00 for xcon@ietf.org; Mon, 01 Dec 2003 13:26:56 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA04945 for ; Mon, 1 Dec 2003 13:26:22 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA19184 for ; Mon, 1 Dec 2003 13:26:23 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Mon, 1 Dec 2003 13:26:22 -0500 Message-ID: <313680C9A886D511A06000204840E1CF070B6138@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'xcon@ietf.org'" Date: Mon, 1 Dec 2003 13:26:20 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [XCON] Chicken and Egg - Can CPCP create a conference Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , I'd like to re-open the requirement to create a conference with CPCP. Somehow, I missed that one. Generally, I think it's a bad idea to have two ways to do something, and we have another way to create a conference (conference factory uri). I'd like to eliminate one of them if possible. Beyond that, it seems to me that there is a chicken and egg problem with CPCP. That is, how do you "start" sending CPCP "commands", and to whom do you address them? This is an issue that intertwines with the signalling protocol (sip). In my mind, the conference uri gave you an address (the host of the focus) and an identifier (the userpart of the uri). Now, in at least the first version of all of this, do we need to have some kind of discovery mechanism for the conference policy server? I think not, or at least I think you get it from the focus. I'd propose that it is precisely the host of the focus, but I'd be okay with a query to the focus that returned the address of the conference policy server. So, if I were choosing, I would not permit CPCP to create conferences. I would rely on the conference factory URI (as well as out of band means). I would make the conference policy server the same host as the conference uri, or at least make the focus return the address of conference policy server. If you need a conference uri to get the conference policy server address, then you can't use CPCP without a conference URI, and thus using CPCP to create/discover a conference URI wouldn't work. Brian _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Mon Dec 1 13:55:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22591 for ; Mon, 1 Dec 2003 13:55:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQtCL-0001d8-Hm for xcon-archive@odin.ietf.org; Mon, 01 Dec 2003 13:55:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB1It5o8006260 for xcon-archive@odin.ietf.org; Mon, 1 Dec 2003 13:55:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQtCL-0001cs-4v for xcon-web-archive@optimus.ietf.org; Mon, 01 Dec 2003 13:55:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22583 for ; Mon, 1 Dec 2003 13:54:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQtCI-0006oN-00 for xcon-web-archive@ietf.org; Mon, 01 Dec 2003 13:55:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AQtCI-0006oK-00 for xcon-web-archive@ietf.org; Mon, 01 Dec 2003 13:55:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQtCI-0001cQ-8V; Mon, 01 Dec 2003 13:55:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQtCA-0001c6-Ge for xcon@optimus.ietf.org; Mon, 01 Dec 2003 13:54:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22568 for ; Mon, 1 Dec 2003 13:54:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQtC6-0006o6-00 for xcon@ietf.org; Mon, 01 Dec 2003 13:54:50 -0500 Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx with esmtp (Exim 4.12) id 1AQtC5-0006nw-00 for xcon@ietf.org; Mon, 01 Dec 2003 13:54:50 -0500 Received: from cs.columbia.edu (path.cs.columbia.edu [128.59.19.143]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id hB1Iqme9024245 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 1 Dec 2003 13:52:48 -0500 (EST) Message-ID: <3FCB8E00.8020706@cs.columbia.edu> Date: Mon, 01 Dec 2003 13:52:48 -0500 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Hammer CC: hisham.khartabil@nokia.com, Markus.Isomaki@nokia.com, xcon@ietf.org Subject: Re: [XCON] CPCP - making something simple that works References: <2038BCC78B1AD641891A0D1AE133DBB70118B10F@esebe019.ntc.nokia.com> <2038BCC78B1AD641891A0D1AE133DBB70118B10F@esebe019.ntc.nokia.com> <4.3.2.7.2.20031201105417.00b17068@cia.cisco.com> In-Reply-To: <4.3.2.7.2.20031201105417.00b17068@cia.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Michael Hammer wrote: > Henning, > > I can name two cases where explicitly expelling someone is useful: > > 1) An enterprise conference is discussing company sensitive material of > economic value and someone manages to join and refused to identify > themselves, If they manage to join the first time without authentication, why wouldn't they rejoin the second time, under a different alias? > > 2) Someone on the conference puts it on hold improperly and plays music > on hold to the conference. Muting that party is probably the preferred approach, since you may want that party to rejoin once they have been told not to do that again. > > Both of these happen frequently enough that an ability to eject the > offending user is desirable and more preferable to wasting time getting > everyone to move on to another conference. It shouldn't be necessary to > get hold of a moderator to do the expelling. > _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Mon Dec 1 14:32:15 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23916 for ; Mon, 1 Dec 2003 14:32:15 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQtm5-0003gi-W2 for xcon-archive@odin.ietf.org; Mon, 01 Dec 2003 14:32:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB1JW1nl014170 for xcon-archive@odin.ietf.org; Mon, 1 Dec 2003 14:32:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQtm5-0003gT-PN for xcon-web-archive@optimus.ietf.org; Mon, 01 Dec 2003 14:32:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23885 for ; Mon, 1 Dec 2003 14:31:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQtm3-0007BF-00 for xcon-web-archive@ietf.org; Mon, 01 Dec 2003 14:31:59 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AQtm2-0007BC-00 for xcon-web-archive@ietf.org; Mon, 01 Dec 2003 14:31:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQtm3-0003g0-Sb; Mon, 01 Dec 2003 14:31:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQtlh-0003fi-Dy for xcon@optimus.ietf.org; Mon, 01 Dec 2003 14:31:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23857 for ; Mon, 1 Dec 2003 14:31:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQtle-0007Ar-00 for xcon@ietf.org; Mon, 01 Dec 2003 14:31:34 -0500 Received: from mail4.microsoft.com ([131.107.3.122]) by ietf-mx with esmtp (Exim 4.12) id 1AQtle-0007AY-00 for xcon@ietf.org; Mon, 01 Dec 2003 14:31:34 -0500 Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.149]) by mail4.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 1 Dec 2003 11:31:40 -0800 Received: from 157.54.8.109 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 01 Dec 2003 11:31:03 -0800 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by inet-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 1 Dec 2003 11:31:09 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Subject: RE: [XCON] CPCP - making something simple that works Date: Mon, 1 Dec 2003 11:31:02 -0800 Message-ID: Thread-Topic: [XCON] CPCP - making something simple that works Thread-Index: AcO4BpeuJzKZGj4xSHa3aCVoBvVzZgAOccRA From: "Orit Levin" To: "Avshalom Houri" , X-OriginalArrivalTime: 01 Dec 2003 19:31:09.0190 (UTC) FILETIME=[ABD73A60:01C3B841] Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3B841.9DE8B86F" ------_=_NextPart_001_01C3B841.9DE8B86F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I second the "extensibility requirement" 100%. Simple (both ad-hoc and pre-configured) conferencing can be done with SIP today. (See http://www.ietf.org/internet-drafts/draft-ietf-sipping-cc-conferencing-0 2.txt). The reason for launching XCON is to come up with a standard and convenient way (for users) to do more than that in extensible manner. =20 Orit. ________________________________ From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org] On Behalf Of Avshalom Houri Sent: Monday, December 01, 2003 4:26 AM To: xcon@ietf.org Subject: RE: [XCON] CPCP - making something simple that works =20 ---skip=20 I agree that we should define a minimal set of features for the first version of CPCP but the main question will be=20 how we make sure that it is extendable. If we find a good way to extend, the initial set of features will be less important.=20 Avshalom=20 Markus.Isomaki@nokia.com=20 Sent by: xcon-admin@ietf.org=20 30/11/2003 11:49 PM=20 To , =20 cc =20 Subject RE: [XCON] CPCP - making something simple that works =20 =20 =20 ------_=_NextPart_001_01C3B841.9DE8B86F Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I second the “extensibility requirement” 100%.

Simple (both ad-hoc and = pre-configured) conferencing can be done with SIP today. (See http://www.ietf.org/internet-drafts/draft-ietf-sipping-cc-c= onferencing-02.txt).

The reason for launching XCON is to = come up with a standard and convenient way (for users) to do more than that = in extensible manner.

 

Orit.

From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org] On Behalf Of Avshalom Houri
Sent: Monday, December = 01, 2003 4:26 AM
To: xcon@ietf.org
Subject: RE: [XCON] CPCP = - making something simple that works

 

---skip


I agree that we should define a minimal set of = features for the first version of CPCP but the main question will = be
how we make sure that it is extendable. If we find a good way to extend, the initial set of features will be less important.

Avshalom


Markus.Isomaki@nokia.com
Sent by: xcon-admin@ietf.org

30/11/2003 11:49 PM

To

<hgs@cs.columbia.edu>, = <hisham.khartabil@nokia.com>

cc

<xcon@ietf.org> =

Subject

RE: [XCON] CPCP - making something = simple that works

 

 

 





------_=_NextPart_001_01C3B841.9DE8B86F-- --------------InterScan_NT_MIME_Boundary-- _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Mon Dec 1 15:04:15 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25005 for ; Mon, 1 Dec 2003 15:04:15 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQuH4-0005Gi-Mm for xcon-archive@odin.ietf.org; Mon, 01 Dec 2003 15:04:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB1K42lD020246 for xcon-archive@odin.ietf.org; Mon, 1 Dec 2003 15:04:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQuH4-0005GT-HD for xcon-web-archive@optimus.ietf.org; Mon, 01 Dec 2003 15:04:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24951 for ; Mon, 1 Dec 2003 15:03:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQuH1-0007SG-00 for xcon-web-archive@ietf.org; Mon, 01 Dec 2003 15:03:59 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AQuH1-0007SD-00 for xcon-web-archive@ietf.org; Mon, 01 Dec 2003 15:03:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQuH3-0005G7-22; Mon, 01 Dec 2003 15:04:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQuG7-0005F5-W6 for xcon@optimus.ietf.org; Mon, 01 Dec 2003 15:03:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24807 for ; Mon, 1 Dec 2003 15:02:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQuG4-0007Rt-00 for xcon@ietf.org; Mon, 01 Dec 2003 15:03:01 -0500 Received: from mail4.microsoft.com ([131.107.3.122]) by ietf-mx with esmtp (Exim 4.12) id 1AQuG4-0007Rc-00 for xcon@ietf.org; Mon, 01 Dec 2003 15:03:00 -0500 Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.149]) by mail4.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 1 Dec 2003 12:03:09 -0800 Received: from 157.54.5.25 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 01 Dec 2003 12:02:30 -0800 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by inet-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 1 Dec 2003 12:02:15 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] Chicken and Egg - Can CPCP create a conference Date: Mon, 1 Dec 2003 12:02:29 -0800 Message-ID: Thread-Topic: [XCON] Chicken and Egg - Can CPCP create a conference Thread-Index: AcO4OLYOWg4kF8XLTJCDNErrhRO//QACR+Ng From: "Orit Levin" To: "Rosen, Brian" , X-OriginalArrivalTime: 01 Dec 2003 20:02:15.0708 (UTC) FILETIME=[045F45C0:01C3B846] Content-Transfer-Encoding: quoted-printable Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Brian! I am actually surprised by this thread. In reality, a single conference instance can be potentially defined / requested by million ways. Moreover, the same conference instance can host participants joining by very different means and media. Moreover, the same conference can have more than a single unique identifier... SIP conferencing and XCON conferencing must be able to coexist in the system and share same conference instances but apart from that - each is a "complete system" on its own. (SIP point-to-point CC is a different issue - it is one of the tools available for XCON.) As a result, the discussion of the addressing scheme should first apply to the SIPPING conferencing work. (In XCON we still need to agree on the higher level architectural decomposition of the pieces that we managed to introduce.) In particular, draft-ietf-sipping-cc-conferencing-02.txt has different assumptions or, I should say, is less restrictive that you propose below. BTW, it does define that "calling a Factory" results in establishing a conference with its focus (either through the same dialog or by redirection to a focus - both are valid cases). If we disagree on this, let's start this discussion in SIPPING ASAP. Orit. -----Original Message----- From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org] On Behalf Of Rosen, Brian Sent: Monday, December 01, 2003 10:26 AM To: 'xcon@ietf.org' Subject: [XCON] Chicken and Egg - Can CPCP create a conference I'd like to re-open the requirement to create a conference with CPCP. Somehow, I missed that one. Generally, I think it's a bad idea to have two ways to do something, and we have another way to create a conference (conference factory uri). I'd like to eliminate one of them if possible. Beyond that, it seems to me that there is a chicken and egg problem with CPCP. That is, how do you "start" sending CPCP "commands", and to whom do you address them? This is an issue that intertwines with the signalling protocol (sip). In my mind, the conference uri gave you an address (the host of the focus) and an identifier (the userpart of the uri). Now, in at least the first version of all of this, do we need to have some kind of discovery mechanism for the conference policy server? I think not, or at least I think you get it from the focus. I'd propose that it is precisely the host of the focus, but I'd be okay with a query to the focus that returned the address of the conference policy server.=20 So, if I were choosing, I would not permit CPCP to create conferences. I would rely on the conference factory URI (as well as out of band means). I would make the conference policy server the same host as the conference uri, or at least make the focus return the address of conference policy server. If you need a conference uri to get the conference policy server address, then you can't use CPCP without a conference URI, and thus using CPCP to create/discover a conference URI wouldn't work. Brian _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Mon Dec 1 16:12:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29869 for ; Mon, 1 Dec 2003 16:12:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQvKt-0002do-0C for xcon-archive@odin.ietf.org; Mon, 01 Dec 2003 16:12:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB1LC2wp010146 for xcon-archive@odin.ietf.org; Mon, 1 Dec 2003 16:12:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQvKs-0002dZ-Qq for xcon-web-archive@optimus.ietf.org; Mon, 01 Dec 2003 16:12:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29847 for ; Mon, 1 Dec 2003 16:11:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQvKr-0001Cm-00 for xcon-web-archive@ietf.org; Mon, 01 Dec 2003 16:12:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AQvKq-0001Cj-00 for xcon-web-archive@ietf.org; Mon, 01 Dec 2003 16:12:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQvKr-0002dI-Cr; Mon, 01 Dec 2003 16:12:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQvKc-0002ck-0w for xcon@optimus.ietf.org; Mon, 01 Dec 2003 16:11:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29832 for ; Mon, 1 Dec 2003 16:11:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQvKa-0001BO-00 for xcon@ietf.org; Mon, 01 Dec 2003 16:11:44 -0500 Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx with esmtp (Exim 4.12) id 1AQvKZ-00019k-00 for xcon@ietf.org; Mon, 01 Dec 2003 16:11:43 -0500 Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 1 Dec 2003 13:10:45 -0800 Received: from 157.54.5.25 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 01 Dec 2003 13:11:13 -0800 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by inet-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 1 Dec 2003 13:10:57 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] Chicken and Egg - Can CPCP create a conference Date: Mon, 1 Dec 2003 13:11:10 -0800 Message-ID: Thread-Topic: [XCON] Chicken and Egg - Can CPCP create a conference Thread-Index: AcO4SuRlHpzqIm/lSvWOsRBNa8hzGAAA3ohw From: "Orit Levin" To: "Rosen, Brian" , X-OriginalArrivalTime: 01 Dec 2003 21:10:57.0043 (UTC) FILETIME=[9CE11630:01C3B84F] Content-Transfer-Encoding: quoted-printable Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable I agree with the general principles below :-) In my view they don't contradict the points that I stressed in my previous mail. That is NOT for the sake of other (than SIP) protocols - it is for the sake of simple conferencing using SIP and clean extensible conferencing design using XCON. Cheers, Orit. BTW Using URI as a conference ID - is OK. Prescribing its structure - I don't think so.=20 -----Original Message----- From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]=20 Sent: Monday, December 01, 2003 12:37 PM To: Orit Levin; xcon@ietf.org Subject: RE: [XCON] Chicken and Egg - Can CPCP create a conference Orit Keeping XCON separate from SIP is useful so long as it doesn't=20 get in the way of common sense. To me, that would mean, for example,=20 having a different name space for a conference ID, requiring one=20 for CPCP and another for SIP. If a conference ID in CPCP is not a=20 uri, for which a SIP uri is an excellent, but not limiting example,=20 I have a very large problem. I don't care if some day, someone invents a way to use CPCP without=20 SIP, and I don't have any interest in making that difficult in any way. However, it's not a driving function, and I don't think there is=20 any reason to have more than one standardized way to create a conference. =20 An INVITE to a conference URI does it. A specific implementation may=20 have some other, non standardized way. I want ONE standardized way,=20 unless someone has a compelling reason why we need to have two. =20 It's a broken record; when you have multiple ways to do the same thing,=20 you facilitate incompatible implementations. If there are a million=20 ways, you will have a lot of incompatible systems. I have no interest=20 in fostering that kind of design. Brian > -----Original Message----- > From: Orit Levin [mailto:oritl@microsoft.com] > Sent: Monday, December 01, 2003 3:02 PM > To: Rosen, Brian; xcon@ietf.org > Subject: RE: [XCON] Chicken and Egg - Can CPCP create a conference >=20 >=20 > Brian! > I am actually surprised by this thread. >=20 > In reality, a single conference instance can be potentially defined / > requested by million ways. Moreover, the same conference instance can > host participants joining by very different means and media. Moreover, > the same conference can have more than a single unique identifier... >=20 > SIP conferencing and XCON conferencing must be able to coexist in the > system and share same conference instances but apart from=20 > that - each is > a "complete system" on its own. (SIP point-to-point CC is a different > issue - it is one of the tools available for XCON.) >=20 > As a result, the discussion of the addressing scheme should=20 > first apply > to the SIPPING conferencing work. (In XCON we still need to=20 > agree on the > higher level architectural decomposition of the pieces that we managed > to introduce.) >=20 > In particular, draft-ietf-sipping-cc-conferencing-02.txt has different > assumptions or, I should say, is less restrictive that you propose > below. BTW, it does define that "calling a Factory" results in > establishing a conference with its focus (either through the=20 > same dialog > or by redirection to a focus - both are valid cases). If we=20 > disagree on > this, let's start this discussion in SIPPING ASAP. >=20 > Orit. >=20 > -----Original Message----- > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org] On Behalf Of > Rosen, Brian > Sent: Monday, December 01, 2003 10:26 AM > To: 'xcon@ietf.org' > Subject: [XCON] Chicken and Egg - Can CPCP create a conference >=20 > I'd like to re-open the requirement to create a conference with CPCP. > Somehow, I missed that one. >=20 > Generally, I think it's a bad idea to have two ways to do=20 > something, and > we > have another way to create a conference (conference factory uri). I'd > like to eliminate one of them if possible. >=20 > Beyond that, it seems to me that there is a chicken and egg=20 > problem with > CPCP. That is, how do you "start" sending CPCP "commands",=20 > and to whom > do you address them? This is an issue that intertwines with the > signalling > protocol (sip). In my mind, the conference uri gave you an=20 > address (the > host of the focus) and an identifier (the userpart of the uri). Now, > in at least the first version of all of this, do we need to have some > kind > of discovery mechanism for the conference policy server? I think not, > or at least I think you get it from the focus. I'd propose that it is > precisely the host of the focus, but I'd be okay with a query to the > focus > that returned the address of the conference policy server.=20 >=20 > So, if I were choosing, I would not permit CPCP to create conferences. > I would rely on the conference factory URI (as well as out of band > means). > I would make the conference policy server the same host as the > conference > uri, or at least make the focus return the address of=20 > conference policy > server. > If you need a conference uri to get the conference policy server > address, > then you can't use CPCP without a conference URI, and thus=20 > using CPCP to > create/discover a conference URI wouldn't work. >=20 > Brian >=20 > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon >=20 >=20 >=20 > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon >=20 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Mon Dec 1 16:16:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00153 for ; Mon, 1 Dec 2003 16:16:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQvOl-0002zg-AO for xcon-archive@odin.ietf.org; Mon, 01 Dec 2003 16:16:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB1LG340011499 for xcon-archive@odin.ietf.org; Mon, 1 Dec 2003 16:16:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQvOl-0002zJ-3H for xcon-web-archive@optimus.ietf.org; Mon, 01 Dec 2003 16:16:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00106 for ; Mon, 1 Dec 2003 16:15:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQvOj-0001SO-00 for xcon-web-archive@ietf.org; Mon, 01 Dec 2003 16:16:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AQvOi-0001SL-00 for xcon-web-archive@ietf.org; Mon, 01 Dec 2003 16:16:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQvOj-0002xY-T1; Mon, 01 Dec 2003 16:16:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQvO7-0002wx-Kc for xcon@optimus.ietf.org; Mon, 01 Dec 2003 16:15:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00059 for ; Mon, 1 Dec 2003 16:15:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQvO5-0001Pg-00 for xcon@ietf.org; Mon, 01 Dec 2003 16:15:21 -0500 Received: from dgesmtp02.wcom.com ([199.249.16.17]) by ietf-mx with esmtp (Exim 4.12) id 1AQvO5-0001Mv-00 for xcon@ietf.org; Mon, 01 Dec 2003 16:15:21 -0500 Received: from pmismtp02.wcomnet.com ([166.38.62.37]) by firewall.wcom.com (Iplanet MTA 5.2) with ESMTP id <0HP8008JRIXRXM@firewall.wcom.com> for xcon@ietf.org; Mon, 01 Dec 2003 21:13:03 +0000 (GMT) Received: from pmismtp02.wcomnet.com by pmismtp02.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0HP800M01ITXKN@pmismtp02.wcomnet.com>; Mon, 01 Dec 2003 21:13:03 +0000 (GMT) Received: from xs578v3521.mci.com ([166.50.122.43]) by pmismtp02.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0HP800LOUIVV51@pmismtp02.wcomnet.com>; Mon, 01 Dec 2003 21:11:57 +0000 (GMT) Date: Mon, 01 Dec 2003 15:11:54 -0600 From: Alan Johnston Subject: RE: [XCON] Chicken and Egg - Can CPCP create a conference X-Sender: Alan.Johnston@pop.mcit.com To: "Rosen, Brian" , "'Orit Levin'" , xcon@ietf.org Message-id: <5.2.1.1.0.20031201150446.02b19d10@pop.mcit.com> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Content-type: text/plain; charset=us-ascii; format=flowed Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , At 03:36 PM 12/1/2003 -0500, Rosen, Brian wrote: >Orit > >Keeping XCON separate from SIP is useful so long as it doesn't >get in the way of common sense. To me, that would mean, for example, >having a different name space for a conference ID, requiring one >for CPCP and another for SIP. If a conference ID in CPCP is not a >uri, for which a SIP uri is an excellent, but not limiting example, >I have a very large problem. > >I don't care if some day, someone invents a way to use CPCP without >SIP, and I don't have any interest in making that difficult in any way. >However, it's not a driving function, and I don't think there is >any reason to have more than one standardized way to create a conference. >An INVITE to a conference URI does it. A specific implementation may >have some other, non standardized way. I want ONE standardized way, >unless someone has a compelling reason why we need to have two. >It's a broken record; when you have multiple ways to do the same thing, >you facilitate incompatible implementations. If there are a million >ways, you will have a lot of incompatible systems. I have no interest >in fostering that kind of design. Brian, Please re-read the SIP Conferencing Framework document - practically every conference-related operation has both a SIP and a non-SIP mechanism to do so. Thanks, Alan sip:alan@sipstation.com >Brian > > > > > > -----Original Message----- > > From: Orit Levin [mailto:oritl@microsoft.com] > > Sent: Monday, December 01, 2003 3:02 PM > > To: Rosen, Brian; xcon@ietf.org > > Subject: RE: [XCON] Chicken and Egg - Can CPCP create a conference > > > > > > Brian! > > I am actually surprised by this thread. > > > > In reality, a single conference instance can be potentially defined / > > requested by million ways. Moreover, the same conference instance can > > host participants joining by very different means and media. Moreover, > > the same conference can have more than a single unique identifier... > > > > SIP conferencing and XCON conferencing must be able to coexist in the > > system and share same conference instances but apart from > > that - each is > > a "complete system" on its own. (SIP point-to-point CC is a different > > issue - it is one of the tools available for XCON.) > > > > As a result, the discussion of the addressing scheme should > > first apply > > to the SIPPING conferencing work. (In XCON we still need to > > agree on the > > higher level architectural decomposition of the pieces that we managed > > to introduce.) > > > > In particular, draft-ietf-sipping-cc-conferencing-02.txt has different > > assumptions or, I should say, is less restrictive that you propose > > below. BTW, it does define that "calling a Factory" results in > > establishing a conference with its focus (either through the > > same dialog > > or by redirection to a focus - both are valid cases). If we > > disagree on > > this, let's start this discussion in SIPPING ASAP. > > > > Orit. > > > > -----Original Message----- > > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org] On Behalf Of > > Rosen, Brian > > Sent: Monday, December 01, 2003 10:26 AM > > To: 'xcon@ietf.org' > > Subject: [XCON] Chicken and Egg - Can CPCP create a conference > > > > I'd like to re-open the requirement to create a conference with CPCP. > > Somehow, I missed that one. > > > > Generally, I think it's a bad idea to have two ways to do > > something, and > > we > > have another way to create a conference (conference factory uri). I'd > > like to eliminate one of them if possible. > > > > Beyond that, it seems to me that there is a chicken and egg > > problem with > > CPCP. That is, how do you "start" sending CPCP "commands", > > and to whom > > do you address them? This is an issue that intertwines with the > > signalling > > protocol (sip). In my mind, the conference uri gave you an > > address (the > > host of the focus) and an identifier (the userpart of the uri). Now, > > in at least the first version of all of this, do we need to have some > > kind > > of discovery mechanism for the conference policy server? I think not, > > or at least I think you get it from the focus. I'd propose that it is > > precisely the host of the focus, but I'd be okay with a query to the > > focus > > that returned the address of the conference policy server. > > > > So, if I were choosing, I would not permit CPCP to create conferences. > > I would rely on the conference factory URI (as well as out of band > > means). > > I would make the conference policy server the same host as the > > conference > > uri, or at least make the focus return the address of > > conference policy > > server. > > If you need a conference uri to get the conference policy server > > address, > > then you can't use CPCP without a conference URI, and thus > > using CPCP to > > create/discover a conference URI wouldn't work. > > > > Brian > > > > _______________________________________________ > > XCON mailing list > > XCON@ietf.org > > https://www1.ietf.org/mailman/listinfo/xcon > > > > > > > > _______________________________________________ > > XCON mailing list > > XCON@ietf.org > > https://www1.ietf.org/mailman/listinfo/xcon > > > >_______________________________________________ >XCON mailing list >XCON@ietf.org >https://www1.ietf.org/mailman/listinfo/xcon _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Mon Dec 1 16:22:18 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00741 for ; Mon, 1 Dec 2003 16:22:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQvUY-0003Eq-L1 for xcon-archive@odin.ietf.org; Mon, 01 Dec 2003 16:22:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB1LM2WF012442 for xcon-archive@odin.ietf.org; Mon, 1 Dec 2003 16:22:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQvUY-0003Eb-Fc for xcon-web-archive@optimus.ietf.org; Mon, 01 Dec 2003 16:22:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00714 for ; Mon, 1 Dec 2003 16:21:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQvUW-0001hX-00 for xcon-web-archive@ietf.org; Mon, 01 Dec 2003 16:22:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AQvUW-0001hU-00 for xcon-web-archive@ietf.org; Mon, 01 Dec 2003 16:22:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQvUX-0003EF-Ag; Mon, 01 Dec 2003 16:22:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQvUN-0003Dr-LO for xcon@optimus.ietf.org; Mon, 01 Dec 2003 16:21:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00707 for ; Mon, 1 Dec 2003 16:21:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQvUL-0001hE-00 for xcon@ietf.org; Mon, 01 Dec 2003 16:21:49 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1AQvUL-0001ff-00 for xcon@ietf.org; Mon, 01 Dec 2003 16:21:49 -0500 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hB1LLGDM006699; Mon, 1 Dec 2003 16:21:16 -0500 (EST) Received: from cisco.com ([161.44.79.239]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AEI45284; Mon, 1 Dec 2003 16:21:15 -0500 (EST) Message-ID: <3FCBB0CB.10108@cisco.com> Date: Mon, 01 Dec 2003 16:21:15 -0500 From: Paul Kyzivat 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: "Rosen, Brian" CC: "'Orit Levin'" , xcon@ietf.org Subject: Re: [XCON] Chicken and Egg - Can CPCP create a conference References: <313680C9A886D511A06000204840E1CF070B613F@whq-msgusr-02.pit.comms.marconi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Brian - inline. Paul Rosen, Brian wrote: > Orit > > Keeping XCON separate from SIP is useful so long as it doesn't > get in the way of common sense. To me, that would mean, for example, > having a different name space for a conference ID, requiring one > for CPCP and another for SIP. If a conference ID in CPCP is not a > uri, for which a SIP uri is an excellent, but not limiting example, > I have a very large problem. > > I don't care if some day, someone invents a way to use CPCP without > SIP, and I don't have any interest in making that difficult in any way. > However, it's not a driving function, and I don't think there is > any reason to have more than one standardized way to create a conference. > An INVITE to a conference URI does it. I have one problem with this, and perhaps it is small enough to be ignored: If I want to create a scheduled conference for some time in the future, perhaps from an application with a web interface, then using an INVITE to do so seems peculiar. I don't want to establish a dialog with the focus now. I don't even what a focus now. All I want is an address that uniquely addresses the conference policy server and the conference to be defined. I especially don't want to open any media streams, or force the server to assign media resources just in case I might need them. But it may indeed be possible to use sip in a specific way to achieve all that is needed. For instance, perhaps an invite could be sent with a medialess offer, together with some headers that indicate desire for suitable features. If this was sufficiently specific for the server to get the hint, the response could be a 3xx with a contact for the policy server (http url). This may however be a viewed as a hack. If I am forced to send a real invite, and establish and invite dialog, in order to learn the policy server address, then what happens if I then change the conference policy to start at a particular time in the future? Does my call immediately get terminated? Paul > A specific implementation may > have some other, non standardized way. I want ONE standardized way, > unless someone has a compelling reason why we need to have two. > It's a broken record; when you have multiple ways to do the same thing, > you facilitate incompatible implementations. If there are a million > ways, you will have a lot of incompatible systems. I have no interest > in fostering that kind of design. > > Brian > > > > > >>-----Original Message----- >>From: Orit Levin [mailto:oritl@microsoft.com] >>Sent: Monday, December 01, 2003 3:02 PM >>To: Rosen, Brian; xcon@ietf.org >>Subject: RE: [XCON] Chicken and Egg - Can CPCP create a conference >> >> >>Brian! >>I am actually surprised by this thread. >> >>In reality, a single conference instance can be potentially defined / >>requested by million ways. Moreover, the same conference instance can >>host participants joining by very different means and media. Moreover, >>the same conference can have more than a single unique identifier... >> >>SIP conferencing and XCON conferencing must be able to coexist in the >>system and share same conference instances but apart from >>that - each is >>a "complete system" on its own. (SIP point-to-point CC is a different >>issue - it is one of the tools available for XCON.) >> >>As a result, the discussion of the addressing scheme should >>first apply >>to the SIPPING conferencing work. (In XCON we still need to >>agree on the >>higher level architectural decomposition of the pieces that we managed >>to introduce.) >> >>In particular, draft-ietf-sipping-cc-conferencing-02.txt has different >>assumptions or, I should say, is less restrictive that you propose >>below. BTW, it does define that "calling a Factory" results in >>establishing a conference with its focus (either through the >>same dialog >>or by redirection to a focus - both are valid cases). If we >>disagree on >>this, let's start this discussion in SIPPING ASAP. >> >>Orit. >> >>-----Original Message----- >>From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org] On Behalf Of >>Rosen, Brian >>Sent: Monday, December 01, 2003 10:26 AM >>To: 'xcon@ietf.org' >>Subject: [XCON] Chicken and Egg - Can CPCP create a conference >> >>I'd like to re-open the requirement to create a conference with CPCP. >>Somehow, I missed that one. >> >>Generally, I think it's a bad idea to have two ways to do >>something, and >>we >>have another way to create a conference (conference factory uri). I'd >>like to eliminate one of them if possible. >> >>Beyond that, it seems to me that there is a chicken and egg >>problem with >>CPCP. That is, how do you "start" sending CPCP "commands", >>and to whom >>do you address them? This is an issue that intertwines with the >>signalling >>protocol (sip). In my mind, the conference uri gave you an >>address (the >>host of the focus) and an identifier (the userpart of the uri). Now, >>in at least the first version of all of this, do we need to have some >>kind >>of discovery mechanism for the conference policy server? I think not, >>or at least I think you get it from the focus. I'd propose that it is >>precisely the host of the focus, but I'd be okay with a query to the >>focus >>that returned the address of the conference policy server. >> >>So, if I were choosing, I would not permit CPCP to create conferences. >>I would rely on the conference factory URI (as well as out of band >>means). >>I would make the conference policy server the same host as the >>conference >>uri, or at least make the focus return the address of >>conference policy >>server. >>If you need a conference uri to get the conference policy server >>address, >>then you can't use CPCP without a conference URI, and thus >>using CPCP to >>create/discover a conference URI wouldn't work. >> >>Brian >> >>_______________________________________________ >>XCON mailing list >>XCON@ietf.org >>https://www1.ietf.org/mailman/listinfo/xcon >> >> >> >>_______________________________________________ >>XCON mailing list >>XCON@ietf.org >>https://www1.ietf.org/mailman/listinfo/xcon >> > > > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon > _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Mon Dec 1 17:08:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04805 for ; Mon, 1 Dec 2003 17:08:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQwD6-0006W0-GM for xcon-archive@odin.ietf.org; Mon, 01 Dec 2003 17:08:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB1M84sV025041 for xcon-archive@odin.ietf.org; Mon, 1 Dec 2003 17:08:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQwD5-0006Vg-Ul for xcon-web-archive@optimus.ietf.org; Mon, 01 Dec 2003 17:08:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04775 for ; Mon, 1 Dec 2003 17:07:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQwD3-0003EI-00 for xcon-web-archive@ietf.org; Mon, 01 Dec 2003 17:08:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AQwD3-0003ED-00 for xcon-web-archive@ietf.org; Mon, 01 Dec 2003 17:08:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQwD3-0006Up-Vo; Mon, 01 Dec 2003 17:08:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQwCI-0006KZ-Rp for xcon@optimus.ietf.org; Mon, 01 Dec 2003 17:07:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04765 for ; Mon, 1 Dec 2003 17:06:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQwCG-0003DR-00 for xcon@ietf.org; Mon, 01 Dec 2003 17:07:12 -0500 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 1AQwCF-0003CM-00 for xcon@ietf.org; Mon, 01 Dec 2003 17:07:12 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA12809; Mon, 1 Dec 2003 17:06:36 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA23771; Mon, 1 Dec 2003 17:06:37 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Mon, 1 Dec 2003 17:06:36 -0500 Message-ID: <313680C9A886D511A06000204840E1CF070B6147@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Alan Johnston'" , "'Orit Levin'" , xcon@ietf.org Subject: RE: [XCON] Chicken and Egg - Can CPCP create a conference Date: Mon, 1 Dec 2003 17:06:35 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , Guilty of not reading documents carefully enough. Most of the "duplicate" mechanisms were, on my reading, merely reflecting the observation that the focus is one end of the dialog each participant has, and in SIP, either end can initiate most operations, thus there is really no possibility of incompatible implementations. Re-reading, I think we may want to beef up the wording to make sure of it. The only case where I think CPCP actually "creates" a conference is where there is a dial out with no-one dialing in before the dial out occurs. It should not be possible, I think, to "create" a conference before someone dials in or the focus dials out. Similarly, a conference is destroyed when the last dialog is terminated with a BYE, which may very well be by the focus, but it is not terminated explicitly by CPCP. Looking at the other mechanisms: Adding participants Similar to creating conferences, you can dial out or dial in. I think we might want to observe in the text that focus implementations MUST accept INVITES and REFERS, as well as CPCP requests to send INVITES. A UA could implement either or both mechanisms. I would observe that if a UA wishes to promote a two way to a conference, then it would have to use a REFER, and no other mechanism. I'd prefer that the SIP way be the only way, but the carriers seem to want to control who does the dialing, so there is no way the community would support REFER only. Removing Participants Again, mostly a "both ends of the dialog" issue. BYE from focus really is an acceptable way to boot someone. 3rd party REFER really is a duplicate, but prohibiting it seems unlikely. In most systems it wouldn't work from, say, a moderator, because of security issues (a random user can't REFER/BYE you I hope). Probably need to expand that wording to say "third person (another participant) departures..." I don't want to imply that the focus would use REFER. It would use BYE. I note that the text in this section about the focus manipulating other dialogs is misplaced, because it would do the same thing if the participant was removed by SIP or any other means. Obtaining Membership I don't see why we need two mechanisms. If we keep both, then we should explicitly require a focus to implement both. I really don't care which one we keep. Adding and Removing Media "Both ends of the dialog" issues. Again, a focus probably can't help but implement both, but it might be good to say that explicitly somewhere. Brian > -----Original Message----- > From: Alan Johnston [mailto:alan.johnston@mci.com] > Sent: Monday, December 01, 2003 4:12 PM > To: Rosen, Brian; 'Orit Levin'; xcon@ietf.org > Subject: RE: [XCON] Chicken and Egg - Can CPCP create a conference > > > At 03:36 PM 12/1/2003 -0500, Rosen, Brian wrote: > >Orit > > > >Keeping XCON separate from SIP is useful so long as it doesn't > >get in the way of common sense. To me, that would mean, for example, > >having a different name space for a conference ID, requiring one > >for CPCP and another for SIP. If a conference ID in CPCP is not a > >uri, for which a SIP uri is an excellent, but not limiting example, > >I have a very large problem. > > > >I don't care if some day, someone invents a way to use CPCP without > >SIP, and I don't have any interest in making that difficult > in any way. > >However, it's not a driving function, and I don't think there is > >any reason to have more than one standardized way to create > a conference. > >An INVITE to a conference URI does it. A specific implementation may > >have some other, non standardized way. I want ONE standardized way, > >unless someone has a compelling reason why we need to have two. > >It's a broken record; when you have multiple ways to do the > same thing, > >you facilitate incompatible implementations. If there are a million > >ways, you will have a lot of incompatible systems. I have > no interest > >in fostering that kind of design. > > Brian, > > Please re-read the SIP Conferencing Framework document - > practically every > conference-related operation has both a SIP and a non-SIP > mechanism to do so. > > Thanks, > Alan > sip:alan@sipstation.com > > > > > >Brian > > > > > > > > > > > -----Original Message----- > > > From: Orit Levin [mailto:oritl@microsoft.com] > > > Sent: Monday, December 01, 2003 3:02 PM > > > To: Rosen, Brian; xcon@ietf.org > > > Subject: RE: [XCON] Chicken and Egg - Can CPCP create a conference > > > > > > > > > Brian! > > > I am actually surprised by this thread. > > > > > > In reality, a single conference instance can be > potentially defined / > > > requested by million ways. Moreover, the same conference > instance can > > > host participants joining by very different means and > media. Moreover, > > > the same conference can have more than a single unique > identifier... > > > > > > SIP conferencing and XCON conferencing must be able to > coexist in the > > > system and share same conference instances but apart from > > > that - each is > > > a "complete system" on its own. (SIP point-to-point CC is > a different > > > issue - it is one of the tools available for XCON.) > > > > > > As a result, the discussion of the addressing scheme should > > > first apply > > > to the SIPPING conferencing work. (In XCON we still need to > > > agree on the > > > higher level architectural decomposition of the pieces > that we managed > > > to introduce.) > > > > > > In particular, draft-ietf-sipping-cc-conferencing-02.txt > has different > > > assumptions or, I should say, is less restrictive that you propose > > > below. BTW, it does define that "calling a Factory" results in > > > establishing a conference with its focus (either through the > > > same dialog > > > or by redirection to a focus - both are valid cases). If we > > > disagree on > > > this, let's start this discussion in SIPPING ASAP. > > > > > > Orit. > > > > > > -----Original Message----- > > > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org] On > Behalf Of > > > Rosen, Brian > > > Sent: Monday, December 01, 2003 10:26 AM > > > To: 'xcon@ietf.org' > > > Subject: [XCON] Chicken and Egg - Can CPCP create a conference > > > > > > I'd like to re-open the requirement to create a > conference with CPCP. > > > Somehow, I missed that one. > > > > > > Generally, I think it's a bad idea to have two ways to do > > > something, and > > > we > > > have another way to create a conference (conference > factory uri). I'd > > > like to eliminate one of them if possible. > > > > > > Beyond that, it seems to me that there is a chicken and egg > > > problem with > > > CPCP. That is, how do you "start" sending CPCP "commands", > > > and to whom > > > do you address them? This is an issue that intertwines with the > > > signalling > > > protocol (sip). In my mind, the conference uri gave you an > > > address (the > > > host of the focus) and an identifier (the userpart of the > uri). Now, > > > in at least the first version of all of this, do we need > to have some > > > kind > > > of discovery mechanism for the conference policy server? > I think not, > > > or at least I think you get it from the focus. I'd > propose that it is > > > precisely the host of the focus, but I'd be okay with a > query to the > > > focus > > > that returned the address of the conference policy server. > > > > > > So, if I were choosing, I would not permit CPCP to create > conferences. > > > I would rely on the conference factory URI (as well as out of band > > > means). > > > I would make the conference policy server the same host as the > > > conference > > > uri, or at least make the focus return the address of > > > conference policy > > > server. > > > If you need a conference uri to get the conference policy server > > > address, > > > then you can't use CPCP without a conference URI, and thus > > > using CPCP to > > > create/discover a conference URI wouldn't work. > > > > > > Brian > > > > > > _______________________________________________ > > > XCON mailing list > > > XCON@ietf.org > > > https://www1.ietf.org/mailman/listinfo/xcon > > > > > > > > > > > > _______________________________________________ > > > XCON mailing list > > > XCON@ietf.org > > > https://www1.ietf.org/mailman/listinfo/xcon > > > > > > >_______________________________________________ > >XCON mailing list > >XCON@ietf.org > >https://www1.ietf.org/mailman/listinfo/xcon > _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Mon Dec 1 17:11:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05001 for ; Mon, 1 Dec 2003 17:11:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQwFz-0006r1-Su for xcon-archive@odin.ietf.org; Mon, 01 Dec 2003 17:11:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB1MB3Rv026340 for xcon-archive@odin.ietf.org; Mon, 1 Dec 2003 17:11:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQwFz-0006pt-M5 for xcon-web-archive@optimus.ietf.org; Mon, 01 Dec 2003 17:11:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04983 for ; Mon, 1 Dec 2003 17:10:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQwFx-0003JN-00 for xcon-web-archive@ietf.org; Mon, 01 Dec 2003 17:11:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AQwFx-0003JK-00 for xcon-web-archive@ietf.org; Mon, 01 Dec 2003 17:11:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQwFy-0006p9-QH; Mon, 01 Dec 2003 17:11:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQwFh-0006mB-Kp for xcon@optimus.ietf.org; Mon, 01 Dec 2003 17:10:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04963 for ; Mon, 1 Dec 2003 17:10:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQwFf-0003Im-00 for xcon@ietf.org; Mon, 01 Dec 2003 17:10:43 -0500 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 1AQwFe-0003I1-00 for xcon@ietf.org; Mon, 01 Dec 2003 17:10:42 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA12895; Mon, 1 Dec 2003 17:10:10 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA24197; Mon, 1 Dec 2003 17:10:11 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Mon, 1 Dec 2003 17:10:10 -0500 Message-ID: <313680C9A886D511A06000204840E1CF070B6148@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Paul Kyzivat'" Cc: "'Orit Levin'" , xcon@ietf.org Subject: RE: [XCON] Chicken and Egg - Can CPCP create a conference Date: Mon, 1 Dec 2003 17:10:10 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , I think you need to be able to manipulate policy before a conference is instantiated. So, policy is available as soon as you have a valid conference ID (ie conference uri). This is a reason I don't want a conference factory uri to instantiate a conference. I want to send an INVITE to the factory URI, get a conference ID, manipulate it's policy, and then INVITE/REFER participants. Brian > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Monday, December 01, 2003 4:21 PM > To: Rosen, Brian > Cc: 'Orit Levin'; xcon@ietf.org > Subject: Re: [XCON] Chicken and Egg - Can CPCP create a conference > > > Brian - inline. > > Paul > > Rosen, Brian wrote: > > Orit > > > > Keeping XCON separate from SIP is useful so long as it doesn't > > get in the way of common sense. To me, that would mean, > for example, > > having a different name space for a conference ID, requiring one > > for CPCP and another for SIP. If a conference ID in CPCP is not a > > uri, for which a SIP uri is an excellent, but not limiting example, > > I have a very large problem. > > > > I don't care if some day, someone invents a way to use CPCP without > > SIP, and I don't have any interest in making that difficult > in any way. > > However, it's not a driving function, and I don't think there is > > any reason to have more than one standardized way to create > a conference. > > An INVITE to a conference URI does it. > > I have one problem with this, and perhaps it is small enough > to be ignored: > > If I want to create a scheduled conference for some time in > the future, > perhaps from an application with a web interface, then using > an INVITE > to do so seems peculiar. I don't want to establish a dialog with the > focus now. I don't even what a focus now. All I want is an > address that > uniquely addresses the conference policy server and the > conference to be > defined. I especially don't want to open any media streams, > or force the > server to assign media resources just in case I might need them. > > But it may indeed be possible to use sip in a specific way to achieve > all that is needed. For instance, perhaps an invite could be > sent with a > medialess offer, together with some headers that indicate desire for > suitable features. If this was sufficiently specific for the > server to > get the hint, the response could be a 3xx with a contact for > the policy > server (http url). This may however be a viewed as a hack. > > If I am forced to send a real invite, and establish and > invite dialog, > in order to learn the policy server address, then what > happens if I then > change the conference policy to start at a particular time in the > future? Does my call immediately get terminated? > > Paul > > > A specific implementation may > > have some other, non standardized way. I want ONE > standardized way, > > unless someone has a compelling reason why we need to have two. > > It's a broken record; when you have multiple ways to do the > same thing, > > you facilitate incompatible implementations. If there are > a million > > ways, you will have a lot of incompatible systems. I have > no interest > > in fostering that kind of design. > > > > Brian > > > > > > > > > > > >>-----Original Message----- > >>From: Orit Levin [mailto:oritl@microsoft.com] > >>Sent: Monday, December 01, 2003 3:02 PM > >>To: Rosen, Brian; xcon@ietf.org > >>Subject: RE: [XCON] Chicken and Egg - Can CPCP create a conference > >> > >> > >>Brian! > >>I am actually surprised by this thread. > >> > >>In reality, a single conference instance can be potentially > defined / > >>requested by million ways. Moreover, the same conference > instance can > >>host participants joining by very different means and > media. Moreover, > >>the same conference can have more than a single unique identifier... > >> > >>SIP conferencing and XCON conferencing must be able to > coexist in the > >>system and share same conference instances but apart from > >>that - each is > >>a "complete system" on its own. (SIP point-to-point CC is a > different > >>issue - it is one of the tools available for XCON.) > >> > >>As a result, the discussion of the addressing scheme should > >>first apply > >>to the SIPPING conferencing work. (In XCON we still need to > >>agree on the > >>higher level architectural decomposition of the pieces that > we managed > >>to introduce.) > >> > >>In particular, draft-ietf-sipping-cc-conferencing-02.txt > has different > >>assumptions or, I should say, is less restrictive that you propose > >>below. BTW, it does define that "calling a Factory" results in > >>establishing a conference with its focus (either through the > >>same dialog > >>or by redirection to a focus - both are valid cases). If we > >>disagree on > >>this, let's start this discussion in SIPPING ASAP. > >> > >>Orit. > >> > >>-----Original Message----- > >>From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org] On Behalf Of > >>Rosen, Brian > >>Sent: Monday, December 01, 2003 10:26 AM > >>To: 'xcon@ietf.org' > >>Subject: [XCON] Chicken and Egg - Can CPCP create a conference > >> > >>I'd like to re-open the requirement to create a conference > with CPCP. > >>Somehow, I missed that one. > >> > >>Generally, I think it's a bad idea to have two ways to do > >>something, and > >>we > >>have another way to create a conference (conference factory > uri). I'd > >>like to eliminate one of them if possible. > >> > >>Beyond that, it seems to me that there is a chicken and egg > >>problem with > >>CPCP. That is, how do you "start" sending CPCP "commands", > >>and to whom > >>do you address them? This is an issue that intertwines with the > >>signalling > >>protocol (sip). In my mind, the conference uri gave you an > >>address (the > >>host of the focus) and an identifier (the userpart of the > uri). Now, > >>in at least the first version of all of this, do we need to > have some > >>kind > >>of discovery mechanism for the conference policy server? I > think not, > >>or at least I think you get it from the focus. I'd propose > that it is > >>precisely the host of the focus, but I'd be okay with a query to the > >>focus > >>that returned the address of the conference policy server. > >> > >>So, if I were choosing, I would not permit CPCP to create > conferences. > >>I would rely on the conference factory URI (as well as out of band > >>means). > >>I would make the conference policy server the same host as the > >>conference > >>uri, or at least make the focus return the address of > >>conference policy > >>server. > >>If you need a conference uri to get the conference policy server > >>address, > >>then you can't use CPCP without a conference URI, and thus > >>using CPCP to > >>create/discover a conference URI wouldn't work. > >> > >>Brian > >> > >>_______________________________________________ > >>XCON mailing list > >>XCON@ietf.org > >>https://www1.ietf.org/mailman/listinfo/xcon > >> > >> > >> > >>_______________________________________________ > >>XCON mailing list > >>XCON@ietf.org > >>https://www1.ietf.org/mailman/listinfo/xcon > >> > > > > > > _______________________________________________ > > XCON mailing list > > XCON@ietf.org > > https://www1.ietf.org/mailman/listinfo/xcon > > > > > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon > _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Mon Dec 1 17:27:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06691 for ; Mon, 1 Dec 2003 17:27:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQwVT-0007cW-HM for xcon-archive@odin.ietf.org; Mon, 01 Dec 2003 17:27:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB1MR38a029286 for xcon-archive@odin.ietf.org; Mon, 1 Dec 2003 17:27:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQwVT-0007cH-C7 for xcon-web-archive@optimus.ietf.org; Mon, 01 Dec 2003 17:27:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06667 for ; Mon, 1 Dec 2003 17:26:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQwVQ-0003yX-00 for xcon-web-archive@ietf.org; Mon, 01 Dec 2003 17:27:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AQwVQ-0003yT-00 for xcon-web-archive@ietf.org; Mon, 01 Dec 2003 17:27:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQwVQ-0007bx-Rg; Mon, 01 Dec 2003 17:27:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQwUX-0007ao-7W for xcon@optimus.ietf.org; Mon, 01 Dec 2003 17:26:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06544 for ; Mon, 1 Dec 2003 17:25:49 -0500 (EST) From: georg.mayer@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQwUU-0003w0-00 for xcon@ietf.org; Mon, 01 Dec 2003 17:26:02 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AQwUT-0003vv-00 for xcon@ietf.org; Mon, 01 Dec 2003 17:26:01 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hB1MQ0g29481 for ; Tue, 2 Dec 2003 00:26:00 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 2 Dec 2003 00:26:00 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 2 Dec 2003 00:25:59 +0200 Received: from esebe021.NOE.Nokia.com ([172.21.138.104]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 2 Dec 2003 00:25:59 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] Chicken and Egg - Can CPCP create a conference Date: Tue, 2 Dec 2003 00:25:59 +0200 Message-ID: <147748D63CC6B5449BC5E49FB5F8FF5101FD5C83@esebe021.ntc.nokia.com> Thread-Topic: [XCON] Chicken and Egg - Can CPCP create a conference Thread-Index: AcO4WAhZEYb3E6CMSD2vp/a1zy/SGQAATtgw To: , Cc: , X-OriginalArrivalTime: 01 Dec 2003 22:25:59.0482 (UTC) FILETIME=[188AC1A0:01C3B85A] Content-Transfer-Encoding: quoted-printable Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi, > This is a reason I don't want a conference factory uri to instantiate > a conference. I want to send an INVITE to the factory URI,=20 > get a conference > ID, manipulate it's policy, and then INVITE/REFER participants. I may have problems understanding this, so I have to ask. I understand = the current work on SIP conferencing in a way, that I can send a = conf-factory URI to a server, which then, during establishment of the = session/invite dialog, creates the conference and with it the conference = URI. It returns the conference URI latest in the 200 (OK) response to me = (in the Contact header) and then I am in the conference. So I would not = need to dial into the conference again. Do you think this is ok? If not, then I would have a problem to use an INVITE request to ... = "connect" to the conference-factory URI in order to create the = conference URI. An INVITE is supposed to establish a media session, but = in that case it would be used only for conference URI creation. Then = maybe (!) the OPTIONS or some other request would be better suited. But from my point of view it is easy, conveninant und nice that I just = call the conf-facotry and <> I'm in the conference. Best regards Georg > -----Original Message----- > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On Behalf Of ext > Rosen, Brian > Sent: 02 December, 2003 00:10 > To: 'Paul Kyzivat' > Cc: 'Orit Levin'; xcon@ietf.org > Subject: RE: [XCON] Chicken and Egg - Can CPCP create a conference >=20 >=20 > I think you need to be able to manipulate policy before a conference > is instantiated. So, policy is available as soon as you have a valid > conference ID (ie conference uri). >=20 > This is a reason I don't want a conference factory uri to instantiate > a conference. I want to send an INVITE to the factory URI,=20 > get a conference > ID, manipulate it's policy, and then INVITE/REFER participants. >=20 > Brian >=20 > > -----Original Message----- > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > Sent: Monday, December 01, 2003 4:21 PM > > To: Rosen, Brian > > Cc: 'Orit Levin'; xcon@ietf.org > > Subject: Re: [XCON] Chicken and Egg - Can CPCP create a conference > >=20 > >=20 > > Brian - inline. > >=20 > > Paul > >=20 > > Rosen, Brian wrote: > > > Orit > > >=20 > > > Keeping XCON separate from SIP is useful so long as it doesn't=20 > > > get in the way of common sense. To me, that would mean,=20 > > for example,=20 > > > having a different name space for a conference ID, requiring one=20 > > > for CPCP and another for SIP. If a conference ID in CPCP=20 > is not a=20 > > > uri, for which a SIP uri is an excellent, but not=20 > limiting example,=20 > > > I have a very large problem. > > >=20 > > > I don't care if some day, someone invents a way to use=20 > CPCP without=20 > > > SIP, and I don't have any interest in making that difficult=20 > > in any way. > > > However, it's not a driving function, and I don't think there is=20 > > > any reason to have more than one standardized way to create=20 > > a conference. =20 > > > An INVITE to a conference URI does it.=20 > >=20 > > I have one problem with this, and perhaps it is small enough=20 > > to be ignored: > >=20 > > If I want to create a scheduled conference for some time in=20 > > the future,=20 > > perhaps from an application with a web interface, then using=20 > > an INVITE=20 > > to do so seems peculiar. I don't want to establish a dialog=20 > with the=20 > > focus now. I don't even what a focus now. All I want is an=20 > > address that=20 > > uniquely addresses the conference policy server and the=20 > > conference to be=20 > > defined. I especially don't want to open any media streams,=20 > > or force the=20 > > server to assign media resources just in case I might need them. > >=20 > > But it may indeed be possible to use sip in a specific way=20 > to achieve=20 > > all that is needed. For instance, perhaps an invite could be=20 > > sent with a=20 > > medialess offer, together with some headers that indicate=20 > desire for=20 > > suitable features. If this was sufficiently specific for the=20 > > server to=20 > > get the hint, the response could be a 3xx with a contact for=20 > > the policy=20 > > server (http url). This may however be a viewed as a hack. > >=20 > > If I am forced to send a real invite, and establish and=20 > > invite dialog,=20 > > in order to learn the policy server address, then what=20 > > happens if I then=20 > > change the conference policy to start at a particular time in the=20 > > future? Does my call immediately get terminated? > >=20 > > Paul > >=20 > > > A specific implementation may > > > have some other, non standardized way. I want ONE=20 > > standardized way,=20 > > > unless someone has a compelling reason why we need to have two. =20 > > > It's a broken record; when you have multiple ways to do the=20 > > same thing,=20 > > > you facilitate incompatible implementations. If there are=20 > > a million=20 > > > ways, you will have a lot of incompatible systems. I have=20 > > no interest=20 > > > in fostering that kind of design. > > >=20 > > > Brian > > >=20 > > >=20 > > >=20 > > >=20 > > >=20 > > >>-----Original Message----- > > >>From: Orit Levin [mailto:oritl@microsoft.com] > > >>Sent: Monday, December 01, 2003 3:02 PM > > >>To: Rosen, Brian; xcon@ietf.org > > >>Subject: RE: [XCON] Chicken and Egg - Can CPCP create a conference > > >> > > >> > > >>Brian! > > >>I am actually surprised by this thread. > > >> > > >>In reality, a single conference instance can be potentially=20 > > defined / > > >>requested by million ways. Moreover, the same conference=20 > > instance can > > >>host participants joining by very different means and=20 > > media. Moreover, > > >>the same conference can have more than a single unique=20 > identifier... > > >> > > >>SIP conferencing and XCON conferencing must be able to=20 > > coexist in the > > >>system and share same conference instances but apart from=20 > > >>that - each is > > >>a "complete system" on its own. (SIP point-to-point CC is a=20 > > different > > >>issue - it is one of the tools available for XCON.) > > >> > > >>As a result, the discussion of the addressing scheme should=20 > > >>first apply > > >>to the SIPPING conferencing work. (In XCON we still need to=20 > > >>agree on the > > >>higher level architectural decomposition of the pieces that=20 > > we managed > > >>to introduce.) > > >> > > >>In particular, draft-ietf-sipping-cc-conferencing-02.txt=20 > > has different > > >>assumptions or, I should say, is less restrictive that you propose > > >>below. BTW, it does define that "calling a Factory" results in > > >>establishing a conference with its focus (either through the=20 > > >>same dialog > > >>or by redirection to a focus - both are valid cases). If we=20 > > >>disagree on > > >>this, let's start this discussion in SIPPING ASAP. > > >> > > >>Orit. > > >> > > >>-----Original Message----- > > >>From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org] On=20 > Behalf Of > > >>Rosen, Brian > > >>Sent: Monday, December 01, 2003 10:26 AM > > >>To: 'xcon@ietf.org' > > >>Subject: [XCON] Chicken and Egg - Can CPCP create a conference > > >> > > >>I'd like to re-open the requirement to create a conference=20 > > with CPCP. > > >>Somehow, I missed that one. > > >> > > >>Generally, I think it's a bad idea to have two ways to do=20 > > >>something, and > > >>we > > >>have another way to create a conference (conference factory=20 > > uri). I'd > > >>like to eliminate one of them if possible. > > >> > > >>Beyond that, it seems to me that there is a chicken and egg=20 > > >>problem with > > >>CPCP. That is, how do you "start" sending CPCP "commands",=20 > > >>and to whom > > >>do you address them? This is an issue that intertwines with the > > >>signalling > > >>protocol (sip). In my mind, the conference uri gave you an=20 > > >>address (the > > >>host of the focus) and an identifier (the userpart of the=20 > > uri). Now, > > >>in at least the first version of all of this, do we need to=20 > > have some > > >>kind > > >>of discovery mechanism for the conference policy server? I=20 > > think not, > > >>or at least I think you get it from the focus. I'd propose=20 > > that it is > > >>precisely the host of the focus, but I'd be okay with a=20 > query to the > > >>focus > > >>that returned the address of the conference policy server.=20 > > >> > > >>So, if I were choosing, I would not permit CPCP to create=20 > > conferences. > > >>I would rely on the conference factory URI (as well as out of band > > >>means). > > >>I would make the conference policy server the same host as the > > >>conference > > >>uri, or at least make the focus return the address of=20 > > >>conference policy > > >>server. > > >>If you need a conference uri to get the conference policy server > > >>address, > > >>then you can't use CPCP without a conference URI, and thus=20 > > >>using CPCP to > > >>create/discover a conference URI wouldn't work. > > >> > > >>Brian > > >> > > >>_______________________________________________ > > >>XCON mailing list > > >>XCON@ietf.org > > >>https://www1.ietf.org/mailman/listinfo/xcon > > >> > > >> > > >> > > >>_______________________________________________ > > >>XCON mailing list > > >>XCON@ietf.org > > >>https://www1.ietf.org/mailman/listinfo/xcon > > >> > > >=20 > > >=20 > > > _______________________________________________ > > > XCON mailing list > > > XCON@ietf.org > > > https://www1.ietf.org/mailman/listinfo/xcon > > >=20 > >=20 > >=20 > > _______________________________________________ > > XCON mailing list > > XCON@ietf.org > > https://www1.ietf.org/mailman/listinfo/xcon > >=20 >=20 > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon >=20 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Mon Dec 1 17:59:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08336 for ; Mon, 1 Dec 2003 17:59:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQx0T-0000tY-6B for xcon-archive@odin.ietf.org; Mon, 01 Dec 2003 17:59:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB1Mx5PF003426 for xcon-archive@odin.ietf.org; Mon, 1 Dec 2003 17:59:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQx0S-0000tA-Pt for xcon-web-archive@optimus.ietf.org; Mon, 01 Dec 2003 17:59:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08232 for ; Mon, 1 Dec 2003 17:58:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQx0P-0004aD-00 for xcon-web-archive@ietf.org; Mon, 01 Dec 2003 17:59:01 -0500 Received: from manatick.foretec.com ([4.17.168.5] helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1AQx0P-0004a9-00 for xcon-web-archive@ietf.org; Mon, 01 Dec 2003 17:59:01 -0500 Received: from [132.151.6.22] (helo=optimus.ietf.org) by manatick with esmtp (Exim 4.24) id 1AQx0Q-0007V1-1z for xcon-web-archive@ietf.org; Mon, 01 Dec 2003 17:59:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQx0O-0000ra-CZ; Mon, 01 Dec 2003 17:59:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQwzc-0000qr-BO for xcon@optimus.ietf.org; Mon, 01 Dec 2003 17:58:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08206 for ; Mon, 1 Dec 2003 17:57:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQwzZ-0004Za-00 for xcon@ietf.org; Mon, 01 Dec 2003 17:58:09 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AQwzZ-0004ZW-00 for xcon@ietf.org; Mon, 01 Dec 2003 17:58:09 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 01 Dec 2003 15:00:27 +0000 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hB1MvbAt006119; Mon, 1 Dec 2003 14:57:37 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AOA78534; Mon, 1 Dec 2003 14:57:36 -0800 (PST) Date: Mon, 1 Dec 2003 14:57:54 -0800 Subject: Re: [XCON] Chicken and Egg - Can CPCP create a conference Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) Cc: "'Alan Johnston'" , "'Orit Levin'" , xcon@ietf.org To: "Rosen, Brian" From: Rohan Mahy In-Reply-To: <313680C9A886D511A06000204840E1CF070B6147@whq-msgusr-02.pit.comms.marconi.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.553) Content-Transfer-Encoding: 7bit Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Monday, December 1, 2003, at 02:06 PM, Rosen, Brian wrote: > Guilty of not reading documents carefully enough. > Most of the "duplicate" mechanisms were, on my reading, merely > reflecting the observation that the focus is one end of the > dialog each participant has, and in SIP, either end can > initiate most operations, thus there is really no possibility > of incompatible implementations. Re-reading, I think we may > want to beef up the wording to make sure of it. > > The only case where I think CPCP actually "creates" a conference > is where there is a dial out with no-one dialing in before the > dial out occurs. It should not be possible, I think, to "create" > a conference before someone dials in or the focus dials out. I can think of several reasons to create a conference before there are any participants/legs/users: - A scheduled conference which has policies set by the creator before the creator joins - A long running conference/group chat - A dial out conference So clearly having a mechanism to create conferences using CPCP makes sense. Now if someone wants to create (possibly standardized) mechanisms in other protocols to create an XCON conference, I see no reason why this is a problem. The SIP conferencing framework describes a role (a conference factory) that has a URI you can INVITE that will create an XCON conference. You could define a similar function for HTTP, XMPP, iCal via SMTP, or H.323. thanks, -rohan > Similarly, a conference is destroyed when the last dialog is > terminated with a BYE, which may very well be by the focus, > but it is not terminated explicitly by CPCP. > > Looking at the other mechanisms: > Adding participants > Similar to creating conferences, you can dial out or dial in. > I think we might want to observe in the text that focus > implementations MUST accept INVITES and REFERS, as well as > CPCP requests to send INVITES. A UA could implement either or > both mechanisms. I would observe that if a UA wishes to promote > a two way to a conference, then it would have to use a REFER, and > no other mechanism. I'd prefer that the SIP way be the only way, > but the carriers seem to want to control who does the dialing, so > there is no way the community would support REFER only. > Removing Participants > Again, mostly a "both ends of the dialog" issue. BYE from focus > really is an acceptable way to boot someone. 3rd party REFER > really is a duplicate, but prohibiting it seems unlikely. In > most systems it wouldn't work from, say, a moderator, because > of security issues (a random user can't REFER/BYE you I hope). > Probably need to expand that wording to say "third person > (another participant) departures..." I don't want to imply > that the focus would use REFER. It would use BYE. > > I note that the text in this section about the focus manipulating > other dialogs is misplaced, because it would do the same thing > if the participant was removed by SIP or any other means. > Obtaining Membership > I don't see why we need two mechanisms. If we keep both, then we > should explicitly require a focus to implement both. I really > don't care which one we keep. > > Adding and Removing Media > "Both ends of the dialog" issues. Again, a focus probably can't > help but implement both, but it might be good to say that > explicitly somewhere. > > Brian > > >> -----Original Message----- >> From: Alan Johnston [mailto:alan.johnston@mci.com] >> Sent: Monday, December 01, 2003 4:12 PM >> To: Rosen, Brian; 'Orit Levin'; xcon@ietf.org >> Subject: RE: [XCON] Chicken and Egg - Can CPCP create a conference >> >> >> At 03:36 PM 12/1/2003 -0500, Rosen, Brian wrote: >>> Orit >>> >>> Keeping XCON separate from SIP is useful so long as it doesn't >>> get in the way of common sense. To me, that would mean, for example, >>> having a different name space for a conference ID, requiring one >>> for CPCP and another for SIP. If a conference ID in CPCP is not a >>> uri, for which a SIP uri is an excellent, but not limiting example, >>> I have a very large problem. >>> >>> I don't care if some day, someone invents a way to use CPCP without >>> SIP, and I don't have any interest in making that difficult >> in any way. >>> However, it's not a driving function, and I don't think there is >>> any reason to have more than one standardized way to create >> a conference. >>> An INVITE to a conference URI does it. A specific implementation may >>> have some other, non standardized way. I want ONE standardized way, >>> unless someone has a compelling reason why we need to have two. >>> It's a broken record; when you have multiple ways to do the >> same thing, >>> you facilitate incompatible implementations. If there are a million >>> ways, you will have a lot of incompatible systems. I have >> no interest >>> in fostering that kind of design. >> >> Brian, >> >> Please re-read the SIP Conferencing Framework document - >> practically every >> conference-related operation has both a SIP and a non-SIP >> mechanism to do so. >> >> Thanks, >> Alan >> sip:alan@sipstation.com >> >> >> >> >>> Brian >>> >>> >>> >>> >>>> -----Original Message----- >>>> From: Orit Levin [mailto:oritl@microsoft.com] >>>> Sent: Monday, December 01, 2003 3:02 PM >>>> To: Rosen, Brian; xcon@ietf.org >>>> Subject: RE: [XCON] Chicken and Egg - Can CPCP create a conference >>>> >>>> >>>> Brian! >>>> I am actually surprised by this thread. >>>> >>>> In reality, a single conference instance can be >> potentially defined / >>>> requested by million ways. Moreover, the same conference >> instance can >>>> host participants joining by very different means and >> media. Moreover, >>>> the same conference can have more than a single unique >> identifier... >>>> >>>> SIP conferencing and XCON conferencing must be able to >> coexist in the >>>> system and share same conference instances but apart from >>>> that - each is >>>> a "complete system" on its own. (SIP point-to-point CC is >> a different >>>> issue - it is one of the tools available for XCON.) >>>> >>>> As a result, the discussion of the addressing scheme should >>>> first apply >>>> to the SIPPING conferencing work. (In XCON we still need to >>>> agree on the >>>> higher level architectural decomposition of the pieces >> that we managed >>>> to introduce.) >>>> >>>> In particular, draft-ietf-sipping-cc-conferencing-02.txt >> has different >>>> assumptions or, I should say, is less restrictive that you propose >>>> below. BTW, it does define that "calling a Factory" results in >>>> establishing a conference with its focus (either through the >>>> same dialog >>>> or by redirection to a focus - both are valid cases). If we >>>> disagree on >>>> this, let's start this discussion in SIPPING ASAP. >>>> >>>> Orit. >>>> >>>> -----Original Message----- >>>> From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org] On >> Behalf Of >>>> Rosen, Brian >>>> Sent: Monday, December 01, 2003 10:26 AM >>>> To: 'xcon@ietf.org' >>>> Subject: [XCON] Chicken and Egg - Can CPCP create a conference >>>> >>>> I'd like to re-open the requirement to create a >> conference with CPCP. >>>> Somehow, I missed that one. >>>> >>>> Generally, I think it's a bad idea to have two ways to do >>>> something, and >>>> we >>>> have another way to create a conference (conference >> factory uri). I'd >>>> like to eliminate one of them if possible. >>>> >>>> Beyond that, it seems to me that there is a chicken and egg >>>> problem with >>>> CPCP. That is, how do you "start" sending CPCP "commands", >>>> and to whom >>>> do you address them? This is an issue that intertwines with the >>>> signalling >>>> protocol (sip). In my mind, the conference uri gave you an >>>> address (the >>>> host of the focus) and an identifier (the userpart of the >> uri). Now, >>>> in at least the first version of all of this, do we need >> to have some >>>> kind >>>> of discovery mechanism for the conference policy server? >> I think not, >>>> or at least I think you get it from the focus. I'd >> propose that it is >>>> precisely the host of the focus, but I'd be okay with a >> query to the >>>> focus >>>> that returned the address of the conference policy server. >>>> >>>> So, if I were choosing, I would not permit CPCP to create >> conferences. >>>> I would rely on the conference factory URI (as well as out of band >>>> means). >>>> I would make the conference policy server the same host as the >>>> conference >>>> uri, or at least make the focus return the address of >>>> conference policy >>>> server. >>>> If you need a conference uri to get the conference policy server >>>> address, >>>> then you can't use CPCP without a conference URI, and thus >>>> using CPCP to >>>> create/discover a conference URI wouldn't work. >>>> >>>> Brian >>>> >>>> _______________________________________________ >>>> XCON mailing list >>>> XCON@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/xcon >>>> >>>> >>>> >>>> _______________________________________________ >>>> XCON mailing list >>>> XCON@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/xcon >>>> >>> >>> _______________________________________________ >>> XCON mailing list >>> XCON@ietf.org >>> https://www1.ietf.org/mailman/listinfo/xcon >> > > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Mon Dec 1 18:32:55 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11438 for ; Mon, 1 Dec 2003 18:32:55 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQxWy-0003BR-KU for xcon-archive@odin.ietf.org; Mon, 01 Dec 2003 18:32:41 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB1NWeZ2012236 for xcon-archive@odin.ietf.org; Mon, 1 Dec 2003 18:32:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQxWy-0003BH-Bu for xcon-web-archive@optimus.ietf.org; Mon, 01 Dec 2003 18:32:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11357 for ; Mon, 1 Dec 2003 18:32:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQxWv-0005Pb-00 for xcon-web-archive@ietf.org; Mon, 01 Dec 2003 18:32:37 -0500 Received: from manatick.foretec.com ([4.17.168.5] helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1AQxWt-0005P9-00 for xcon-web-archive@ietf.org; Mon, 01 Dec 2003 18:32:36 -0500 Received: from [132.151.6.22] (helo=optimus.ietf.org) by manatick with esmtp (Exim 4.24) id 1AQxTo-0008Tn-Jn for xcon-web-archive@ietf.org; Mon, 01 Dec 2003 18:29:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQxTR-00035J-Sv; Mon, 01 Dec 2003 18:29:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQxSe-00031h-8x for xcon@optimus.ietf.org; Mon, 01 Dec 2003 18:28:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11157 for ; Mon, 1 Dec 2003 18:27:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQxSb-0005JP-00 for xcon@ietf.org; Mon, 01 Dec 2003 18:28:09 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1AQxSa-0005H2-00 for xcon@ietf.org; Mon, 01 Dec 2003 18:28:08 -0500 Received: from cisco.com (64.102.124.13) by sj-iport-5.cisco.com with ESMTP; 01 Dec 2003 15:27:08 -0800 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hB1NRVDM003866; Mon, 1 Dec 2003 18:27:31 -0500 (EST) Received: from cisco.com ([161.44.79.239]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AEI55369; Mon, 1 Dec 2003 18:27:30 -0500 (EST) Message-ID: <3FCBCE62.5090400@cisco.com> Date: Mon, 01 Dec 2003 18:27:30 -0500 From: Paul Kyzivat 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: "Rosen, Brian" CC: "'Orit Levin'" , xcon@ietf.org Subject: Re: [XCON] Chicken and Egg - Can CPCP create a conference References: <313680C9A886D511A06000204840E1CF070B6148@whq-msgusr-02.pit.comms.marconi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Rosen, Brian wrote: > I think you need to be able to manipulate policy before a conference > is instantiated. So, policy is available as soon as you have a valid > conference ID (ie conference uri). > > This is a reason I don't want a conference factory uri to instantiate > a conference. I want to send an INVITE to the factory URI, get a conference > ID, manipulate it's policy, and then INVITE/REFER participants. You are saying you want to send an INVITE to the factory URI to get a conference ID, and then you want to manipulate policy on this before the conference is instantiated? I don't follow this. Presumably the result of sending an INVITE to the factory URI is a dialog with something. It is my understanding that if you do things this way you will end up in a dialog with a newly created focus. Hence you at that point already have an instantiated conference. At that point you could presumably send a SUBSCRIBE for the conference event package, and from that get a URI to be used to manipulate the conference policy with CPCP. But you already have instantiated the conference, which was perhaps a needless waste if your goal is to configure a conference for some time in the future. I presume you have something else in mind. Can you spell out how you imagine things working? Paul _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Tue Dec 2 04:36:28 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09803 for ; Tue, 2 Dec 2003 04:36:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AR6wz-0005mZ-Te for xcon-archive@odin.ietf.org; Tue, 02 Dec 2003 04:36:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB29a9hh022221 for xcon-archive@odin.ietf.org; Tue, 2 Dec 2003 04:36:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AR6wz-0005mK-Bw for xcon-web-archive@optimus.ietf.org; Tue, 02 Dec 2003 04:36:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09792 for ; Tue, 2 Dec 2003 04:35:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AR6ww-00047L-00 for xcon-web-archive@ietf.org; Tue, 02 Dec 2003 04:36:06 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AR6wv-00047I-00 for xcon-web-archive@ietf.org; Tue, 02 Dec 2003 04:36:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AR6ws-0005ld-R5; Tue, 02 Dec 2003 04:36:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AR6wb-0005l5-SO for xcon@optimus.ietf.org; Tue, 02 Dec 2003 04:35:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09785 for ; Tue, 2 Dec 2003 04:35:32 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AR6wY-000473-00 for xcon@ietf.org; Tue, 02 Dec 2003 04:35:42 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AR6wX-00046z-00 for xcon@ietf.org; Tue, 02 Dec 2003 04:35:42 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hB29ZfM10895 for ; Tue, 2 Dec 2003 11:35:41 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 2 Dec 2003 11:35:34 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 2 Dec 2003 11:35:33 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] CPCP requirements to support IMS Date: Tue, 2 Dec 2003 11:35:25 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797466@esebe019.ntc.nokia.com> Thread-Topic: [XCON] CPCP requirements to support IMS Thread-Index: AcO4OgosGH3onNPSTqKfEi/YJ+ZRkAAfQGQQ To: , , Cc: X-OriginalArrivalTime: 02 Dec 2003 09:35:33.0834 (UTC) FILETIME=[A25262A0:01C3B8B7] Content-Transfer-Encoding: quoted-printable Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Brian, The way a conference factory URI is defined to be used is to create an = ad-hoc conference when sending an INVITE. With CPCP, the conference is not ad-hoc, but is rather scheduled with = predefined participants. No conference factory URI is used here. In this = case, it is up to the conference server (or a parameter in CPCP) to = start the conference on the scheduled time and wait for participants to = join or to only start the conference when the first INVITE arrives. They are not the same thing. /Hisham > -----Original Message----- > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On Behalf Of ext > Rosen, Brian > Sent: 01.December.2003 20:12 > To: 'Heil Franca Marcelo'; Mayer Georg (NMP-MSW/Helsinki) > Cc: xcon@ietf.org > Subject: RE: [XCON] CPCP requirements to support IMS >=20 >=20 > Of course, there is no right or wrong here, but I would prefer that > the conference factory URI never actually create a conference. > Among other things, a single conference factory URI may=20 > "front" a number > of entities that provide the focus function, and the conference > factory would create a conference uri on the appropriate=20 > entity in order > to do things like load balance. =20 >=20 > I also appear to be mistaked in that CPCP can be used to create a > conference. We might want to revisit this, as in general, it's not > a good idea to have two ways to do the same thing. I'm going to start > a new thread on this one. >=20 > Brian >=20 > > -----Original Message----- > > From: Heil Franca Marcelo [mailto:marcelo.heil_franca@siemens.com] > > Sent: Monday, December 01, 2003 12:20 PM > > To: 'Rosen, Brian'; 'georg.mayer@nokia.com' > > Cc: xcon@ietf.org > > Subject: AW: [XCON] CPCP requirements to support IMS > >=20 > >=20 > > Brian, Georg, > >=20 > > Please see my comments inline. > >=20 > > Marcelo=20 > > > =20 > > > > a) there may be different conferece factory URIs for=20 > > > > different types of conferences (e.g. for some only a=20 > > > > restricted number of participants might be allowed, etc.) > > > There might be more than one conference factory uri, but I think > > > that is because there might be more than one conference service > > > available to you. The example you give is not correct, > > > as you would use CPCP to control the number of allowed=20 > participants. > > >=20 > > > >=20 > > > > b) if no conference resources have been reserved up till now=20 > > > > (i.e. if there is no participant in the conference) from the=20 > > > > users point of view the result of sending an INVITE with a=20 > > > > conference factory URI or a conference URI is identical. Of=20 > > > > course in the case of the factory URI, the conference URI is=20 > > > > first created, but afterwards the conference resources are=20 > > > > reserved and the user becomes the first participant in it. > > > No, this is not my understanding. > > >=20 > > > You don't get a conference by calling the conference factory uri, > > > you only get a Contact with the conference uri. Nothing happens > > > until you call the conference uri. You could gave some > > > resources reserved prior to actually starting the conference, > > > but that comes as a result of using CPCP on the conference URI > > > that you get from the conference factory. When you call the > > > conference URI, the conference "starts" (although conferencing > > > with one user is not a conference, right? And you may only get > > > music on hold until the "organizer" arrives). > > >=20 > > > So, they are not at all the same. > >=20 > > I see no reason why a conference cannot be created by a=20 > > conference server when a request (INVITE) addressed to the=20 > > conference-factory-URI is received (on an ad-hoc basis). The=20 > > conference-URI generated for the conference is returned in=20 > > the 200 OK response, and, at this time, the conference=20 > > already started and the requesting UA is already taking part on it. > >=20 > >=20 > > > >=20 > > > > What I meant in my mails before was, that the user should get=20 > > > > via CPCP aware of a URI that finally allows him to join the=20 > > > > conference and automatically reserve the resources for it.=20 > > > No, I don't thing CPCP will give you the conference URI. You need > > > the conference URI in order to use CPCP. You get the conference > > > URI from the conference factory, from a REFER, from an INVITE (in > > > the case of a dial out conference) or possibly some out-of-band > > > mechanism. > > >=20 > >=20 > > If you use CPCP to create a conference, you will get the=20 > > conference URI back upon successful creation. =20 > >=20 > > > In the latter cases, it will usually be the case that one=20 > > participant > > > (the conference organizer) obtains the conference uri from the > > > conference factory uri. Thereafter, she will arrange to give > > > other participants the conference uri she gets from the conference > > > factory via REFER, or manipulating CPCP to cause an INVITE, or > > > by email :). You might also generate a conference URI from a=20 > > > web page (as opposed to the conference factory uri), or=20 > > your calendar > > > program, but those are out of scope of our work. > > > =20 > > >=20 > > > _______________________________________________ > > > XCON mailing list > > > XCON@ietf.org > > > https://www1.ietf.org/mailman/listinfo/xcon > > >=20 > >=20 > > _______________________________________________ > > XCON mailing list > > XCON@ietf.org > > https://www1.ietf.org/mailman/listinfo/xcon > >=20 >=20 > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon >=20 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Tue Dec 2 04:44:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09943 for ; Tue, 2 Dec 2003 04:44:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AR74e-0006IP-RI for xcon-archive@odin.ietf.org; Tue, 02 Dec 2003 04:44:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB29i4oq024200 for xcon-archive@odin.ietf.org; Tue, 2 Dec 2003 04:44:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AR74e-0006IF-Fl for xcon-web-archive@optimus.ietf.org; Tue, 02 Dec 2003 04:44:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09936 for ; Tue, 2 Dec 2003 04:43:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AR74b-0004Bc-00 for xcon-web-archive@ietf.org; Tue, 02 Dec 2003 04:44:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AR74b-0004BZ-00 for xcon-web-archive@ietf.org; Tue, 02 Dec 2003 04:44:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AR74c-0006Hx-60; Tue, 02 Dec 2003 04:44:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AR73j-0006GY-1W for xcon@optimus.ietf.org; Tue, 02 Dec 2003 04:43:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09922 for ; Tue, 2 Dec 2003 04:42:49 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AR73c-0004Aj-00 for xcon@ietf.org; Tue, 02 Dec 2003 04:43:00 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AR73b-0004Ad-00 for xcon@ietf.org; Tue, 02 Dec 2003 04:43:00 -0500 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hB29h0M21018 for ; Tue, 2 Dec 2003 11:43:00 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 2 Dec 2003 11:43:00 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 2 Dec 2003 11:43:00 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] Chicken and Egg - Can CPCP create a conference Date: Tue, 2 Dec 2003 11:43:00 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797467@esebe019.ntc.nokia.com> Thread-Topic: [XCON] Chicken and Egg - Can CPCP create a conference Thread-Index: AcO4OMszjbs1GbxzSn2zkeB7cfOKswAf14Mw To: , X-OriginalArrivalTime: 02 Dec 2003 09:43:00.0468 (UTC) FILETIME=[AC895340:01C3B8B8] Content-Transfer-Encoding: quoted-printable Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Again, you are tying ah-hoc conferences with scheduled ones. Conferences = are not always ad-hoc. There is no conference policy for an ad-hoc = conference that is created with a conference factory URI. The focus does = not create a conference policy. A conference server reading a conference = policy creates the focus at the time the conference is scheduled to = start. Conference Policy server address needs to be provisioned, just like the = conference factory URI. Regards, Hisham > -----Original Message----- > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On Behalf Of ext > Rosen, Brian > Sent: 01.December.2003 20:26 > To: 'xcon@ietf.org' > Subject: [XCON] Chicken and Egg - Can CPCP create a conference >=20 >=20 > I'd like to re-open the requirement to create a conference with CPCP. > Somehow, I missed that one. >=20 > Generally, I think it's a bad idea to have two ways to do=20 > something, and we > have another way to create a conference (conference factory uri). I'd > like to eliminate one of them if possible. >=20 > Beyond that, it seems to me that there is a chicken and egg=20 > problem with > CPCP. That is, how do you "start" sending CPCP "commands",=20 > and to whom > do you address them? This is an issue that intertwines with=20 > the signalling > protocol (sip). In my mind, the conference uri gave you an=20 > address (the > host of the focus) and an identifier (the userpart of the uri). Now, > in at least the first version of all of this, do we need to=20 > have some kind > of discovery mechanism for the conference policy server? I think not, > or at least I think you get it from the focus. I'd propose that it is > precisely the host of the focus, but I'd be okay with a query=20 > to the focus > that returned the address of the conference policy server.=20 >=20 > So, if I were choosing, I would not permit CPCP to create conferences. > I would rely on the conference factory URI (as well as out of=20 > band means). > I would make the conference policy server the same host as=20 > the conference > uri, or at least make the focus return the address of=20 > conference policy > server. > If you need a conference uri to get the conference policy=20 > server address, > then you can't use CPCP without a conference URI, and thus=20 > using CPCP to > create/discover a conference URI wouldn't work. >=20 > Brian >=20 > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon >=20 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Tue Dec 2 04:59:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10194 for ; Tue, 2 Dec 2003 04:59:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AR7JB-0006ah-9N for xcon-archive@odin.ietf.org; Tue, 02 Dec 2003 04:59:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB29x4fi025315 for xcon-archive@odin.ietf.org; Tue, 2 Dec 2003 04:59:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AR7J8-0006aE-Jk for xcon-web-archive@optimus.ietf.org; Tue, 02 Dec 2003 04:59:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10190 for ; Tue, 2 Dec 2003 04:58:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AR7J5-0004JD-00 for xcon-web-archive@ietf.org; Tue, 02 Dec 2003 04:58:59 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AR7J4-0004JA-00 for xcon-web-archive@ietf.org; Tue, 02 Dec 2003 04:58:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AR7J6-0006Zx-S1; Tue, 02 Dec 2003 04:59:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AR7Ih-0006ZW-4a for xcon@optimus.ietf.org; Tue, 02 Dec 2003 04:58:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10181 for ; Tue, 2 Dec 2003 04:58:16 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AR7IY-0004Iw-00 for xcon@ietf.org; Tue, 02 Dec 2003 04:58:26 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AR7IY-0004It-00 for xcon@ietf.org; Tue, 02 Dec 2003 04:58:26 -0500 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hB29wQM10594 for ; Tue, 2 Dec 2003 11:58:26 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 2 Dec 2003 11:58:26 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 2 Dec 2003 11:58:25 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 2 Dec 2003 11:58:25 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] Chicken and Egg - Can CPCP create a conference Date: Tue, 2 Dec 2003 11:58:24 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB70118B114@esebe019.ntc.nokia.com> Thread-Topic: [XCON] Chicken and Egg - Can CPCP create a conference Thread-Index: AcO4V58bMqQVT07FQLi9SdRfGyPJDgAYcg4Q To: , , , X-OriginalArrivalTime: 02 Dec 2003 09:58:25.0248 (UTC) FILETIME=[D3BF8E00:01C3B8BA] Content-Transfer-Encoding: quoted-printable Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On Behalf Of ext > Rosen, Brian > Sent: 02.December.2003 00:07 > To: 'Alan Johnston'; 'Orit Levin'; xcon@ietf.org > Subject: RE: [XCON] Chicken and Egg - Can CPCP create a conference >=20 >=20 > Guilty of not reading documents carefully enough. > Most of the "duplicate" mechanisms were, on my reading, merely > reflecting the observation that the focus is one end of the > dialog each participant has, and in SIP, either end can > initiate most operations, thus there is really no possibility > of incompatible implementations. Re-reading, I think we may > want to beef up the wording to make sure of it. =20 >=20 > The only case where I think CPCP actually "creates" a conference > is where there is a dial out with no-one dialing in before the > dial out occurs. It should not be possible, I think, to "create" > a conference before someone dials in or the focus dials out. This might be a local policy of the conference server, or it can be = configured using CPCP itself. >=20 > Similarly, a conference is destroyed when the last dialog is > terminated with a BYE, which may very well be by the focus, > but it is not terminated explicitly by CPCP. CPCP does not termiate, it provides a policy. Part of that policy could = be a stop-time for the confernece whre the conference focus is not = removed until the time is up. A conference policy that does not define a = stop-time could mean that a conference is terminated as soon as the last = participant departs. >=20 > Looking at the other mechanisms: > Adding participants > Similar to creating conferences, you can dial out or dial in. > I think we might want to observe in the text that focus > implementations MUST accept INVITES and REFERS, as well as > CPCP requests to send INVITES. A UA could implement either or > both mechanisms. I would observe that if a UA wishes to promote > a two way to a conference, then it would have to use a=20 > REFER, and > no other mechanism. I'd prefer that the SIP way be the=20 > only way, > but the carriers seem to want to control who does the=20 > dialing, so > there is no way the community would support REFER only. > Removing Participants > Again, mostly a "both ends of the dialog" issue. BYE from focus > really is an acceptable way to boot someone. 3rd party REFER > really is a duplicate, but prohibiting it seems unlikely. In > most systems it wouldn't work from, say, a moderator, because > of security issues (a random user can't REFER/BYE you I hope). > Probably need to expand that wording to say "third person > (another participant) departures..." I don't want to imply > that the focus would use REFER. It would use BYE. CPCP is used to indicate the desire to remove someone. The focus, after = receiving a notification on the updated policy, as a result sends a BYE = to that participant. This is only the case when the conference is currently active. But with = a scheduled conference that has not started yet. A BYE seems hardly an = appropriate mechanism to remove someone from, say, a dial-out list. A = CPCP command modifying the dial-out list is more appropriate. >=20 > I note that the text in this section about the focus=20 > manipulating > other dialogs is misplaced, because it would do the same thing > if the participant was removed by SIP or any other means. > Obtaining Membership > I don't see why we need two mechanisms. If we keep=20 > both, then we > should explicitly require a focus to implement both. I really > don't care which one we keep. Again, CPCP is used to create a conference policy, not a conference. The = focus add/removes members using the one and only one mechanism, SIP. But = remember, you can manpulate conference policy even when the conference = is not running, ie: there is no focus yet. /Hisham >=20 > Adding and Removing Media > "Both ends of the dialog" issues. Again, a focus probably can't > help but implement both, but it might be good to say that > explicitly somewhere. >=20 > Brian >=20 >=20 > > -----Original Message----- > > From: Alan Johnston [mailto:alan.johnston@mci.com] > > Sent: Monday, December 01, 2003 4:12 PM > > To: Rosen, Brian; 'Orit Levin'; xcon@ietf.org > > Subject: RE: [XCON] Chicken and Egg - Can CPCP create a conference > >=20 > >=20 > > At 03:36 PM 12/1/2003 -0500, Rosen, Brian wrote: > > >Orit > > > > > >Keeping XCON separate from SIP is useful so long as it doesn't > > >get in the way of common sense. To me, that would mean,=20 > for example, > > >having a different name space for a conference ID, requiring one > > >for CPCP and another for SIP. If a conference ID in CPCP is not a > > >uri, for which a SIP uri is an excellent, but not limiting example, > > >I have a very large problem. > > > > > >I don't care if some day, someone invents a way to use CPCP without > > >SIP, and I don't have any interest in making that difficult=20 > > in any way. > > >However, it's not a driving function, and I don't think there is > > >any reason to have more than one standardized way to create=20 > > a conference. > > >An INVITE to a conference URI does it. A specific=20 > implementation may > > >have some other, non standardized way. I want ONE=20 > standardized way, > > >unless someone has a compelling reason why we need to have two. > > >It's a broken record; when you have multiple ways to do the=20 > > same thing, > > >you facilitate incompatible implementations. If there are=20 > a million > > >ways, you will have a lot of incompatible systems. I have=20 > > no interest > > >in fostering that kind of design. > >=20 > > Brian, > >=20 > > Please re-read the SIP Conferencing Framework document -=20 > > practically every=20 > > conference-related operation has both a SIP and a non-SIP=20 > > mechanism to do so. > >=20 > > Thanks, > > Alan > > sip:alan@sipstation.com > >=20 > >=20 > >=20 > >=20 > > >Brian > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Orit Levin [mailto:oritl@microsoft.com] > > > > Sent: Monday, December 01, 2003 3:02 PM > > > > To: Rosen, Brian; xcon@ietf.org > > > > Subject: RE: [XCON] Chicken and Egg - Can CPCP create a=20 > conference > > > > > > > > > > > > Brian! > > > > I am actually surprised by this thread. > > > > > > > > In reality, a single conference instance can be=20 > > potentially defined / > > > > requested by million ways. Moreover, the same conference=20 > > instance can > > > > host participants joining by very different means and=20 > > media. Moreover, > > > > the same conference can have more than a single unique=20 > > identifier... > > > > > > > > SIP conferencing and XCON conferencing must be able to=20 > > coexist in the > > > > system and share same conference instances but apart from > > > > that - each is > > > > a "complete system" on its own. (SIP point-to-point CC is=20 > > a different > > > > issue - it is one of the tools available for XCON.) > > > > > > > > As a result, the discussion of the addressing scheme should > > > > first apply > > > > to the SIPPING conferencing work. (In XCON we still need to > > > > agree on the > > > > higher level architectural decomposition of the pieces=20 > > that we managed > > > > to introduce.) > > > > > > > > In particular, draft-ietf-sipping-cc-conferencing-02.txt=20 > > has different > > > > assumptions or, I should say, is less restrictive that=20 > you propose > > > > below. BTW, it does define that "calling a Factory" results in > > > > establishing a conference with its focus (either through the > > > > same dialog > > > > or by redirection to a focus - both are valid cases). If we > > > > disagree on > > > > this, let's start this discussion in SIPPING ASAP. > > > > > > > > Orit. > > > > > > > > -----Original Message----- > > > > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org] On=20 > > Behalf Of > > > > Rosen, Brian > > > > Sent: Monday, December 01, 2003 10:26 AM > > > > To: 'xcon@ietf.org' > > > > Subject: [XCON] Chicken and Egg - Can CPCP create a conference > > > > > > > > I'd like to re-open the requirement to create a=20 > > conference with CPCP. > > > > Somehow, I missed that one. > > > > > > > > Generally, I think it's a bad idea to have two ways to do > > > > something, and > > > > we > > > > have another way to create a conference (conference=20 > > factory uri). I'd > > > > like to eliminate one of them if possible. > > > > > > > > Beyond that, it seems to me that there is a chicken and egg > > > > problem with > > > > CPCP. That is, how do you "start" sending CPCP "commands", > > > > and to whom > > > > do you address them? This is an issue that intertwines with the > > > > signalling > > > > protocol (sip). In my mind, the conference uri gave you an > > > > address (the > > > > host of the focus) and an identifier (the userpart of the=20 > > uri). Now, > > > > in at least the first version of all of this, do we need=20 > > to have some > > > > kind > > > > of discovery mechanism for the conference policy server? =20 > > I think not, > > > > or at least I think you get it from the focus. I'd=20 > > propose that it is > > > > precisely the host of the focus, but I'd be okay with a=20 > > query to the > > > > focus > > > > that returned the address of the conference policy server. > > > > > > > > So, if I were choosing, I would not permit CPCP to create=20 > > conferences. > > > > I would rely on the conference factory URI (as well as=20 > out of band > > > > means). > > > > I would make the conference policy server the same host as the > > > > conference > > > > uri, or at least make the focus return the address of > > > > conference policy > > > > server. > > > > If you need a conference uri to get the conference policy server > > > > address, > > > > then you can't use CPCP without a conference URI, and thus > > > > using CPCP to > > > > create/discover a conference URI wouldn't work. > > > > > > > > Brian > > > > > > > > _______________________________________________ > > > > XCON mailing list > > > > XCON@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/xcon > > > > > > > > > > > > > > > > _______________________________________________ > > > > XCON mailing list > > > > XCON@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/xcon > > > > > > > > > >_______________________________________________ > > >XCON mailing list > > >XCON@ietf.org > > >https://www1.ietf.org/mailman/listinfo/xcon > >=20 >=20 > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon >=20 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Tue Dec 2 05:04:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10309 for ; Tue, 2 Dec 2003 05:04:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AR7O0-0006ju-Q0 for xcon-archive@odin.ietf.org; Tue, 02 Dec 2003 05:04:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB2A44pt025844 for xcon-archive@odin.ietf.org; Tue, 2 Dec 2003 05:04:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AR7O0-0006ia-2Q for xcon-web-archive@optimus.ietf.org; Tue, 02 Dec 2003 05:04:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10299 for ; Tue, 2 Dec 2003 05:03:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AR7Nv-0004LZ-00 for xcon-web-archive@ietf.org; Tue, 02 Dec 2003 05:03:59 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AR7Nv-0004LW-00 for xcon-web-archive@ietf.org; Tue, 02 Dec 2003 05:03:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AR7Nw-0006hw-VL; Tue, 02 Dec 2003 05:04:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AR7NC-0006gc-Mt for xcon@optimus.ietf.org; Tue, 02 Dec 2003 05:03:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10290 for ; Tue, 2 Dec 2003 05:03:00 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AR7N9-0004Kz-00 for xcon@ietf.org; Tue, 02 Dec 2003 05:03:11 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AR7N8-0004Kw-00 for xcon@ietf.org; Tue, 02 Dec 2003 05:03:10 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hB2A3Bs06167 for ; Tue, 2 Dec 2003 12:03:11 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 2 Dec 2003 12:03:05 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 2 Dec 2003 12:03:04 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] Chicken and Egg - Can CPCP create a conference Date: Tue, 2 Dec 2003 12:03:04 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797469@esebe019.ntc.nokia.com> Thread-Topic: [XCON] Chicken and Egg - Can CPCP create a conference Thread-Index: AcO4WAgfG8ciTHEPR4+iuI1A/LlcjgAYuv8g To: , Cc: , X-OriginalArrivalTime: 02 Dec 2003 10:03:04.0703 (UTC) FILETIME=[7A5100F0:01C3B8BB] Content-Transfer-Encoding: quoted-printable Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On Behalf Of ext > Rosen, Brian > Sent: 02.December.2003 00:10 > To: 'Paul Kyzivat' > Cc: 'Orit Levin'; xcon@ietf.org > Subject: RE: [XCON] Chicken and Egg - Can CPCP create a conference >=20 >=20 > I think you need to be able to manipulate policy before a conference > is instantiated. So, policy is available as soon as you have a valid > conference ID (ie conference uri). >=20 > This is a reason I don't want a conference factory uri to instantiate > a conference. I want to send an INVITE to the factory URI,=20 > get a conference > ID, manipulate it's policy, and then INVITE/REFER participants. If you want a conference with a policy, the conference factory URI is = not the write choice since it is only used for ah-hoc conferences that = don't have user specified policy. In the scenario you describe, you would upload a conference policy using = CPCP and get back a conference URI. You can manipulate that policy and = you may or may not need the conference URI to do that (our XCAP based = solution proposaql uses the XCAP URI). Users can then send INVITE requests to join the confernece when the = start-time has passed. /Hisham >=20 > Brian >=20 > > -----Original Message----- > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > Sent: Monday, December 01, 2003 4:21 PM > > To: Rosen, Brian > > Cc: 'Orit Levin'; xcon@ietf.org > > Subject: Re: [XCON] Chicken and Egg - Can CPCP create a conference > >=20 > >=20 > > Brian - inline. > >=20 > > Paul > >=20 > > Rosen, Brian wrote: > > > Orit > > >=20 > > > Keeping XCON separate from SIP is useful so long as it doesn't=20 > > > get in the way of common sense. To me, that would mean,=20 > > for example,=20 > > > having a different name space for a conference ID, requiring one=20 > > > for CPCP and another for SIP. If a conference ID in CPCP=20 > is not a=20 > > > uri, for which a SIP uri is an excellent, but not=20 > limiting example,=20 > > > I have a very large problem. > > >=20 > > > I don't care if some day, someone invents a way to use=20 > CPCP without=20 > > > SIP, and I don't have any interest in making that difficult=20 > > in any way. > > > However, it's not a driving function, and I don't think there is=20 > > > any reason to have more than one standardized way to create=20 > > a conference. =20 > > > An INVITE to a conference URI does it.=20 > >=20 > > I have one problem with this, and perhaps it is small enough=20 > > to be ignored: > >=20 > > If I want to create a scheduled conference for some time in=20 > > the future,=20 > > perhaps from an application with a web interface, then using=20 > > an INVITE=20 > > to do so seems peculiar. I don't want to establish a dialog=20 > with the=20 > > focus now. I don't even what a focus now. All I want is an=20 > > address that=20 > > uniquely addresses the conference policy server and the=20 > > conference to be=20 > > defined. I especially don't want to open any media streams,=20 > > or force the=20 > > server to assign media resources just in case I might need them. > >=20 > > But it may indeed be possible to use sip in a specific way=20 > to achieve=20 > > all that is needed. For instance, perhaps an invite could be=20 > > sent with a=20 > > medialess offer, together with some headers that indicate=20 > desire for=20 > > suitable features. If this was sufficiently specific for the=20 > > server to=20 > > get the hint, the response could be a 3xx with a contact for=20 > > the policy=20 > > server (http url). This may however be a viewed as a hack. > >=20 > > If I am forced to send a real invite, and establish and=20 > > invite dialog,=20 > > in order to learn the policy server address, then what=20 > > happens if I then=20 > > change the conference policy to start at a particular time in the=20 > > future? Does my call immediately get terminated? > >=20 > > Paul > >=20 > > > A specific implementation may > > > have some other, non standardized way. I want ONE=20 > > standardized way,=20 > > > unless someone has a compelling reason why we need to have two. =20 > > > It's a broken record; when you have multiple ways to do the=20 > > same thing,=20 > > > you facilitate incompatible implementations. If there are=20 > > a million=20 > > > ways, you will have a lot of incompatible systems. I have=20 > > no interest=20 > > > in fostering that kind of design. > > >=20 > > > Brian > > >=20 > > >=20 > > >=20 > > >=20 > > >=20 > > >>-----Original Message----- > > >>From: Orit Levin [mailto:oritl@microsoft.com] > > >>Sent: Monday, December 01, 2003 3:02 PM > > >>To: Rosen, Brian; xcon@ietf.org > > >>Subject: RE: [XCON] Chicken and Egg - Can CPCP create a conference > > >> > > >> > > >>Brian! > > >>I am actually surprised by this thread. > > >> > > >>In reality, a single conference instance can be potentially=20 > > defined / > > >>requested by million ways. Moreover, the same conference=20 > > instance can > > >>host participants joining by very different means and=20 > > media. Moreover, > > >>the same conference can have more than a single unique=20 > identifier... > > >> > > >>SIP conferencing and XCON conferencing must be able to=20 > > coexist in the > > >>system and share same conference instances but apart from=20 > > >>that - each is > > >>a "complete system" on its own. (SIP point-to-point CC is a=20 > > different > > >>issue - it is one of the tools available for XCON.) > > >> > > >>As a result, the discussion of the addressing scheme should=20 > > >>first apply > > >>to the SIPPING conferencing work. (In XCON we still need to=20 > > >>agree on the > > >>higher level architectural decomposition of the pieces that=20 > > we managed > > >>to introduce.) > > >> > > >>In particular, draft-ietf-sipping-cc-conferencing-02.txt=20 > > has different > > >>assumptions or, I should say, is less restrictive that you propose > > >>below. BTW, it does define that "calling a Factory" results in > > >>establishing a conference with its focus (either through the=20 > > >>same dialog > > >>or by redirection to a focus - both are valid cases). If we=20 > > >>disagree on > > >>this, let's start this discussion in SIPPING ASAP. > > >> > > >>Orit. > > >> > > >>-----Original Message----- > > >>From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org] On=20 > Behalf Of > > >>Rosen, Brian > > >>Sent: Monday, December 01, 2003 10:26 AM > > >>To: 'xcon@ietf.org' > > >>Subject: [XCON] Chicken and Egg - Can CPCP create a conference > > >> > > >>I'd like to re-open the requirement to create a conference=20 > > with CPCP. > > >>Somehow, I missed that one. > > >> > > >>Generally, I think it's a bad idea to have two ways to do=20 > > >>something, and > > >>we > > >>have another way to create a conference (conference factory=20 > > uri). I'd > > >>like to eliminate one of them if possible. > > >> > > >>Beyond that, it seems to me that there is a chicken and egg=20 > > >>problem with > > >>CPCP. That is, how do you "start" sending CPCP "commands",=20 > > >>and to whom > > >>do you address them? This is an issue that intertwines with the > > >>signalling > > >>protocol (sip). In my mind, the conference uri gave you an=20 > > >>address (the > > >>host of the focus) and an identifier (the userpart of the=20 > > uri). Now, > > >>in at least the first version of all of this, do we need to=20 > > have some > > >>kind > > >>of discovery mechanism for the conference policy server? I=20 > > think not, > > >>or at least I think you get it from the focus. I'd propose=20 > > that it is > > >>precisely the host of the focus, but I'd be okay with a=20 > query to the > > >>focus > > >>that returned the address of the conference policy server.=20 > > >> > > >>So, if I were choosing, I would not permit CPCP to create=20 > > conferences. > > >>I would rely on the conference factory URI (as well as out of band > > >>means). > > >>I would make the conference policy server the same host as the > > >>conference > > >>uri, or at least make the focus return the address of=20 > > >>conference policy > > >>server. > > >>If you need a conference uri to get the conference policy server > > >>address, > > >>then you can't use CPCP without a conference URI, and thus=20 > > >>using CPCP to > > >>create/discover a conference URI wouldn't work. > > >> > > >>Brian > > >> > > >>_______________________________________________ > > >>XCON mailing list > > >>XCON@ietf.org > > >>https://www1.ietf.org/mailman/listinfo/xcon > > >> > > >> > > >> > > >>_______________________________________________ > > >>XCON mailing list > > >>XCON@ietf.org > > >>https://www1.ietf.org/mailman/listinfo/xcon > > >> > > >=20 > > >=20 > > > _______________________________________________ > > > XCON mailing list > > > XCON@ietf.org > > > https://www1.ietf.org/mailman/listinfo/xcon > > >=20 > >=20 > >=20 > > _______________________________________________ > > XCON mailing list > > XCON@ietf.org > > https://www1.ietf.org/mailman/listinfo/xcon > >=20 >=20 > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon >=20 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Tue Dec 2 05:06:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10385 for ; Tue, 2 Dec 2003 05:06:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AR7Py-0006ou-JI for xcon-archive@odin.ietf.org; Tue, 02 Dec 2003 05:06:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB2A66tj026210 for xcon-archive@odin.ietf.org; Tue, 2 Dec 2003 05:06:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AR7Px-0006nv-08 for xcon-web-archive@optimus.ietf.org; Tue, 02 Dec 2003 05:06:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10371 for ; Tue, 2 Dec 2003 05:05:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AR7Pt-0004NY-00 for xcon-web-archive@ietf.org; Tue, 02 Dec 2003 05:06:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AR7Pt-0004NV-00 for xcon-web-archive@ietf.org; Tue, 02 Dec 2003 05:06:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AR7Pu-0006nQ-Ga; Tue, 02 Dec 2003 05:06:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AR7Pg-0006mX-TV for xcon@optimus.ietf.org; Tue, 02 Dec 2003 05:05:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10363 for ; Tue, 2 Dec 2003 05:05:29 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AR7PY-0004NL-00 for xcon@ietf.org; Tue, 02 Dec 2003 05:05:40 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AR7PX-0004NH-00 for xcon@ietf.org; Tue, 02 Dec 2003 05:05:40 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hB2A5ds09288 for ; Tue, 2 Dec 2003 12:05:39 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 2 Dec 2003 12:05:39 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 2 Dec 2003 12:05:38 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] Chicken and Egg - Can CPCP create a conference Date: Tue, 2 Dec 2003 12:05:38 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB70179746A@esebe019.ntc.nokia.com> Thread-Topic: [XCON] Chicken and Egg - Can CPCP create a conference Thread-Index: AcO4WAhZEYb3E6CMSD2vp/a1zy/SGQAATtgwABidsWA= To: , , Cc: , X-OriginalArrivalTime: 02 Dec 2003 10:05:38.0806 (UTC) FILETIME=[D62B4160:01C3B8BB] Content-Transfer-Encoding: quoted-printable Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On Behalf Of ext > georg.mayer@nokia.com > Sent: 02.December.2003 00:26 > To: Brian.Rosen@marconi.com; pkyzivat@cisco.com > Cc: oritl@microsoft.com; xcon@ietf.org > Subject: RE: [XCON] Chicken and Egg - Can CPCP create a conference >=20 >=20 > Hi, >=20 > > This is a reason I don't want a conference factory uri to=20 > instantiate > > a conference. I want to send an INVITE to the factory URI,=20 > > get a conference > > ID, manipulate it's policy, and then INVITE/REFER participants. >=20 > I may have problems understanding this, so I have to ask. I=20 > understand the current work on SIP conferencing in a way,=20 > that I can send a conf-factory URI to a server, which then,=20 > during establishment of the session/invite dialog, creates=20 > the conference and with it the conference URI. It returns the=20 > conference URI latest in the 200 (OK) response to me (in the=20 > Contact header) and then I am in the conference. So I would=20 > not need to dial into the conference again. >=20 > Do you think this is ok? This is how the cc-conferencing describes it in sipping, and I agree = with it. /Hisham >=20 > If not, then I would have a problem to use an INVITE request=20 > to ... "connect" to the conference-factory URI in order to=20 > create the conference URI. An INVITE is supposed to establish=20 > a media session, but in that case it would be used only for=20 > conference URI creation. Then maybe (!) the OPTIONS or some=20 > other request would be better suited. >=20 > But from my point of view it is easy, conveninant und nice=20 > that I just call the conf-facotry and <> I'm in the conference. >=20 > Best regards > Georg >=20 > > -----Original Message----- > > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On=20 > Behalf Of ext > > Rosen, Brian > > Sent: 02 December, 2003 00:10 > > To: 'Paul Kyzivat' > > Cc: 'Orit Levin'; xcon@ietf.org > > Subject: RE: [XCON] Chicken and Egg - Can CPCP create a conference > >=20 > >=20 > > I think you need to be able to manipulate policy before a conference > > is instantiated. So, policy is available as soon as you=20 > have a valid > > conference ID (ie conference uri). > >=20 > > This is a reason I don't want a conference factory uri to=20 > instantiate > > a conference. I want to send an INVITE to the factory URI,=20 > > get a conference > > ID, manipulate it's policy, and then INVITE/REFER participants. > >=20 > > Brian > >=20 > > > -----Original Message----- > > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > > Sent: Monday, December 01, 2003 4:21 PM > > > To: Rosen, Brian > > > Cc: 'Orit Levin'; xcon@ietf.org > > > Subject: Re: [XCON] Chicken and Egg - Can CPCP create a conference > > >=20 > > >=20 > > > Brian - inline. > > >=20 > > > Paul > > >=20 > > > Rosen, Brian wrote: > > > > Orit > > > >=20 > > > > Keeping XCON separate from SIP is useful so long as it doesn't=20 > > > > get in the way of common sense. To me, that would mean,=20 > > > for example,=20 > > > > having a different name space for a conference ID,=20 > requiring one=20 > > > > for CPCP and another for SIP. If a conference ID in CPCP=20 > > is not a=20 > > > > uri, for which a SIP uri is an excellent, but not=20 > > limiting example,=20 > > > > I have a very large problem. > > > >=20 > > > > I don't care if some day, someone invents a way to use=20 > > CPCP without=20 > > > > SIP, and I don't have any interest in making that difficult=20 > > > in any way. > > > > However, it's not a driving function, and I don't think=20 > there is=20 > > > > any reason to have more than one standardized way to create=20 > > > a conference. =20 > > > > An INVITE to a conference URI does it.=20 > > >=20 > > > I have one problem with this, and perhaps it is small enough=20 > > > to be ignored: > > >=20 > > > If I want to create a scheduled conference for some time in=20 > > > the future,=20 > > > perhaps from an application with a web interface, then using=20 > > > an INVITE=20 > > > to do so seems peculiar. I don't want to establish a dialog=20 > > with the=20 > > > focus now. I don't even what a focus now. All I want is an=20 > > > address that=20 > > > uniquely addresses the conference policy server and the=20 > > > conference to be=20 > > > defined. I especially don't want to open any media streams,=20 > > > or force the=20 > > > server to assign media resources just in case I might need them. > > >=20 > > > But it may indeed be possible to use sip in a specific way=20 > > to achieve=20 > > > all that is needed. For instance, perhaps an invite could be=20 > > > sent with a=20 > > > medialess offer, together with some headers that indicate=20 > > desire for=20 > > > suitable features. If this was sufficiently specific for the=20 > > > server to=20 > > > get the hint, the response could be a 3xx with a contact for=20 > > > the policy=20 > > > server (http url). This may however be a viewed as a hack. > > >=20 > > > If I am forced to send a real invite, and establish and=20 > > > invite dialog,=20 > > > in order to learn the policy server address, then what=20 > > > happens if I then=20 > > > change the conference policy to start at a particular time in the=20 > > > future? Does my call immediately get terminated? > > >=20 > > > Paul > > >=20 > > > > A specific implementation may > > > > have some other, non standardized way. I want ONE=20 > > > standardized way,=20 > > > > unless someone has a compelling reason why we need to=20 > have two. =20 > > > > It's a broken record; when you have multiple ways to do the=20 > > > same thing,=20 > > > > you facilitate incompatible implementations. If there are=20 > > > a million=20 > > > > ways, you will have a lot of incompatible systems. I have=20 > > > no interest=20 > > > > in fostering that kind of design. > > > >=20 > > > > Brian > > > >=20 > > > >=20 > > > >=20 > > > >=20 > > > >=20 > > > >>-----Original Message----- > > > >>From: Orit Levin [mailto:oritl@microsoft.com] > > > >>Sent: Monday, December 01, 2003 3:02 PM > > > >>To: Rosen, Brian; xcon@ietf.org > > > >>Subject: RE: [XCON] Chicken and Egg - Can CPCP create a=20 > conference > > > >> > > > >> > > > >>Brian! > > > >>I am actually surprised by this thread. > > > >> > > > >>In reality, a single conference instance can be potentially=20 > > > defined / > > > >>requested by million ways. Moreover, the same conference=20 > > > instance can > > > >>host participants joining by very different means and=20 > > > media. Moreover, > > > >>the same conference can have more than a single unique=20 > > identifier... > > > >> > > > >>SIP conferencing and XCON conferencing must be able to=20 > > > coexist in the > > > >>system and share same conference instances but apart from=20 > > > >>that - each is > > > >>a "complete system" on its own. (SIP point-to-point CC is a=20 > > > different > > > >>issue - it is one of the tools available for XCON.) > > > >> > > > >>As a result, the discussion of the addressing scheme should=20 > > > >>first apply > > > >>to the SIPPING conferencing work. (In XCON we still need to=20 > > > >>agree on the > > > >>higher level architectural decomposition of the pieces that=20 > > > we managed > > > >>to introduce.) > > > >> > > > >>In particular, draft-ietf-sipping-cc-conferencing-02.txt=20 > > > has different > > > >>assumptions or, I should say, is less restrictive that=20 > you propose > > > >>below. BTW, it does define that "calling a Factory" results in > > > >>establishing a conference with its focus (either through the=20 > > > >>same dialog > > > >>or by redirection to a focus - both are valid cases). If we=20 > > > >>disagree on > > > >>this, let's start this discussion in SIPPING ASAP. > > > >> > > > >>Orit. > > > >> > > > >>-----Original Message----- > > > >>From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org] On=20 > > Behalf Of > > > >>Rosen, Brian > > > >>Sent: Monday, December 01, 2003 10:26 AM > > > >>To: 'xcon@ietf.org' > > > >>Subject: [XCON] Chicken and Egg - Can CPCP create a conference > > > >> > > > >>I'd like to re-open the requirement to create a conference=20 > > > with CPCP. > > > >>Somehow, I missed that one. > > > >> > > > >>Generally, I think it's a bad idea to have two ways to do=20 > > > >>something, and > > > >>we > > > >>have another way to create a conference (conference factory=20 > > > uri). I'd > > > >>like to eliminate one of them if possible. > > > >> > > > >>Beyond that, it seems to me that there is a chicken and egg=20 > > > >>problem with > > > >>CPCP. That is, how do you "start" sending CPCP "commands",=20 > > > >>and to whom > > > >>do you address them? This is an issue that intertwines with the > > > >>signalling > > > >>protocol (sip). In my mind, the conference uri gave you an=20 > > > >>address (the > > > >>host of the focus) and an identifier (the userpart of the=20 > > > uri). Now, > > > >>in at least the first version of all of this, do we need to=20 > > > have some > > > >>kind > > > >>of discovery mechanism for the conference policy server? I=20 > > > think not, > > > >>or at least I think you get it from the focus. I'd propose=20 > > > that it is > > > >>precisely the host of the focus, but I'd be okay with a=20 > > query to the > > > >>focus > > > >>that returned the address of the conference policy server.=20 > > > >> > > > >>So, if I were choosing, I would not permit CPCP to create=20 > > > conferences. > > > >>I would rely on the conference factory URI (as well as=20 > out of band > > > >>means). > > > >>I would make the conference policy server the same host as the > > > >>conference > > > >>uri, or at least make the focus return the address of=20 > > > >>conference policy > > > >>server. > > > >>If you need a conference uri to get the conference policy server > > > >>address, > > > >>then you can't use CPCP without a conference URI, and thus=20 > > > >>using CPCP to > > > >>create/discover a conference URI wouldn't work. > > > >> > > > >>Brian > > > >> > > > >>_______________________________________________ > > > >>XCON mailing list > > > >>XCON@ietf.org > > > >>https://www1.ietf.org/mailman/listinfo/xcon > > > >> > > > >> > > > >> > > > >>_______________________________________________ > > > >>XCON mailing list > > > >>XCON@ietf.org > > > >>https://www1.ietf.org/mailman/listinfo/xcon > > > >> > > > >=20 > > > >=20 > > > > _______________________________________________ > > > > XCON mailing list > > > > XCON@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/xcon > > > >=20 > > >=20 > > >=20 > > > _______________________________________________ > > > XCON mailing list > > > XCON@ietf.org > > > https://www1.ietf.org/mailman/listinfo/xcon > > >=20 > >=20 > > _______________________________________________ > > XCON mailing list > > XCON@ietf.org > > https://www1.ietf.org/mailman/listinfo/xcon > >=20 >=20 > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon >=20 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Tue Dec 2 05:10:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10470 for ; Tue, 2 Dec 2003 05:10:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AR7Ts-0007CA-4Z for xcon-archive@odin.ietf.org; Tue, 02 Dec 2003 05:10:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB2AA7dT027654 for xcon-archive@odin.ietf.org; Tue, 2 Dec 2003 05:10:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AR7Tp-0007BX-1J for xcon-web-archive@optimus.ietf.org; Tue, 02 Dec 2003 05:10:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10462 for ; Tue, 2 Dec 2003 05:09:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AR7Tl-0004Qv-00 for xcon-web-archive@ietf.org; Tue, 02 Dec 2003 05:10:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AR7Tk-0004Qs-00 for xcon-web-archive@ietf.org; Tue, 02 Dec 2003 05:10:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AR7Tm-0007BD-Og; Tue, 02 Dec 2003 05:10:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AR7So-0007AS-O3 for xcon@optimus.ietf.org; Tue, 02 Dec 2003 05:09:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10443 for ; Tue, 2 Dec 2003 05:08:48 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AR7Sl-0004QY-00 for xcon@ietf.org; Tue, 02 Dec 2003 05:08:59 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AR7Sk-0004QV-00 for xcon@ietf.org; Tue, 02 Dec 2003 05:08:58 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hB2A8xM25663 for ; Tue, 2 Dec 2003 12:08:59 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 2 Dec 2003 12:07:30 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 2 Dec 2003 12:07:29 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] Chicken and Egg - Can CPCP create a conference Date: Tue, 2 Dec 2003 12:07:28 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB70179746B@esebe019.ntc.nokia.com> Thread-Topic: [XCON] Chicken and Egg - Can CPCP create a conference Thread-Index: AcO4Xs6TSdqS/E9KQfSUf/kQz0iAjgAXQx9A To: , Cc: , , X-OriginalArrivalTime: 02 Dec 2003 10:07:29.0122 (UTC) FILETIME=[17EC2420:01C3B8BC] Content-Transfer-Encoding: quoted-printable Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Yes. After the conference server creates the focus on the scheduled time = that was set using CPCP, the focus can use SIP INVTE or whatever = protocol it desires to invite participants into the conference, or = accpet participants to join a conference. /Hisham > -----Original Message----- > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On Behalf Of ext > Rohan Mahy > Sent: 02.December.2003 00:58 > To: Rosen, Brian > Cc: 'Alan Johnston'; 'Orit Levin'; xcon@ietf.org > Subject: Re: [XCON] Chicken and Egg - Can CPCP create a conference >=20 >=20 >=20 > On Monday, December 1, 2003, at 02:06 PM, Rosen, Brian wrote: >=20 > > Guilty of not reading documents carefully enough. > > Most of the "duplicate" mechanisms were, on my reading, merely > > reflecting the observation that the focus is one end of the > > dialog each participant has, and in SIP, either end can > > initiate most operations, thus there is really no possibility > > of incompatible implementations. Re-reading, I think we may > > want to beef up the wording to make sure of it. > > > > The only case where I think CPCP actually "creates" a conference > > is where there is a dial out with no-one dialing in before the > > dial out occurs. It should not be possible, I think, to "create" > > a conference before someone dials in or the focus dials out. >=20 > I can think of several reasons to create a conference before=20 > there are=20 > any participants/legs/users: >=20 > - A scheduled conference which has policies set by the creator before=20 > the creator joins > - A long running conference/group chat > - A dial out conference >=20 > So clearly having a mechanism to create conferences using CPCP makes=20 > sense. >=20 > Now if someone wants to create (possibly standardized) mechanisms in=20 > other protocols to create an XCON conference, I see no=20 > reason why this=20 > is a problem. The SIP conferencing framework describes a role (a=20 > conference factory) that has a URI you can INVITE that will create an=20 > XCON conference. You could define a similar function for HTTP, XMPP,=20 > iCal via SMTP, or H.323. >=20 > thanks, > -rohan >=20 > > Similarly, a conference is destroyed when the last dialog is > > terminated with a BYE, which may very well be by the focus, > > but it is not terminated explicitly by CPCP. > > > > Looking at the other mechanisms: > > Adding participants > > Similar to creating conferences, you can dial out or dial in. > > I think we might want to observe in the text that focus > > implementations MUST accept INVITES and REFERS, as well as > > CPCP requests to send INVITES. A UA could implement either or > > both mechanisms. I would observe that if a UA wishes to promote > > a two way to a conference, then it would have to use a=20 > REFER, and > > no other mechanism. I'd prefer that the SIP way be the=20 > only way, > > but the carriers seem to want to control who does the=20 > dialing, so > > there is no way the community would support REFER only. > > Removing Participants > > Again, mostly a "both ends of the dialog" issue. BYE from focus > > really is an acceptable way to boot someone. 3rd party REFER > > really is a duplicate, but prohibiting it seems unlikely. In > > most systems it wouldn't work from, say, a moderator, because > > of security issues (a random user can't REFER/BYE you I hope). > > Probably need to expand that wording to say "third person > > (another participant) departures..." I don't want to imply > > that the focus would use REFER. It would use BYE. > > > > I note that the text in this section about the focus=20 > manipulating > > other dialogs is misplaced, because it would do the same thing > > if the participant was removed by SIP or any other means. > > Obtaining Membership > > I don't see why we need two mechanisms. If we keep=20 > both, then we > > should explicitly require a focus to implement both. I really > > don't care which one we keep. > > > > Adding and Removing Media > > "Both ends of the dialog" issues. Again, a focus probably can't > > help but implement both, but it might be good to say that > > explicitly somewhere. > > > > Brian > > > > > >> -----Original Message----- > >> From: Alan Johnston [mailto:alan.johnston@mci.com] > >> Sent: Monday, December 01, 2003 4:12 PM > >> To: Rosen, Brian; 'Orit Levin'; xcon@ietf.org > >> Subject: RE: [XCON] Chicken and Egg - Can CPCP create a conference > >> > >> > >> At 03:36 PM 12/1/2003 -0500, Rosen, Brian wrote: > >>> Orit > >>> > >>> Keeping XCON separate from SIP is useful so long as it doesn't > >>> get in the way of common sense. To me, that would mean,=20 > for example, > >>> having a different name space for a conference ID, requiring one > >>> for CPCP and another for SIP. If a conference ID in CPCP is not a > >>> uri, for which a SIP uri is an excellent, but not=20 > limiting example, > >>> I have a very large problem. > >>> > >>> I don't care if some day, someone invents a way to use=20 > CPCP without > >>> SIP, and I don't have any interest in making that difficult > >> in any way. > >>> However, it's not a driving function, and I don't think there is > >>> any reason to have more than one standardized way to create > >> a conference. > >>> An INVITE to a conference URI does it. A specific=20 > implementation may > >>> have some other, non standardized way. I want ONE=20 > standardized way, > >>> unless someone has a compelling reason why we need to have two. > >>> It's a broken record; when you have multiple ways to do the > >> same thing, > >>> you facilitate incompatible implementations. If there=20 > are a million > >>> ways, you will have a lot of incompatible systems. I have > >> no interest > >>> in fostering that kind of design. > >> > >> Brian, > >> > >> Please re-read the SIP Conferencing Framework document - > >> practically every > >> conference-related operation has both a SIP and a non-SIP > >> mechanism to do so. > >> > >> Thanks, > >> Alan > >> sip:alan@sipstation.com > >> > >> > >> > >> > >>> Brian > >>> > >>> > >>> > >>> > >>>> -----Original Message----- > >>>> From: Orit Levin [mailto:oritl@microsoft.com] > >>>> Sent: Monday, December 01, 2003 3:02 PM > >>>> To: Rosen, Brian; xcon@ietf.org > >>>> Subject: RE: [XCON] Chicken and Egg - Can CPCP create a=20 > conference > >>>> > >>>> > >>>> Brian! > >>>> I am actually surprised by this thread. > >>>> > >>>> In reality, a single conference instance can be > >> potentially defined / > >>>> requested by million ways. Moreover, the same conference > >> instance can > >>>> host participants joining by very different means and > >> media. Moreover, > >>>> the same conference can have more than a single unique > >> identifier... > >>>> > >>>> SIP conferencing and XCON conferencing must be able to > >> coexist in the > >>>> system and share same conference instances but apart from > >>>> that - each is > >>>> a "complete system" on its own. (SIP point-to-point CC is > >> a different > >>>> issue - it is one of the tools available for XCON.) > >>>> > >>>> As a result, the discussion of the addressing scheme should > >>>> first apply > >>>> to the SIPPING conferencing work. (In XCON we still need to > >>>> agree on the > >>>> higher level architectural decomposition of the pieces > >> that we managed > >>>> to introduce.) > >>>> > >>>> In particular, draft-ietf-sipping-cc-conferencing-02.txt > >> has different > >>>> assumptions or, I should say, is less restrictive that=20 > you propose > >>>> below. BTW, it does define that "calling a Factory" results in > >>>> establishing a conference with its focus (either through the > >>>> same dialog > >>>> or by redirection to a focus - both are valid cases). If we > >>>> disagree on > >>>> this, let's start this discussion in SIPPING ASAP. > >>>> > >>>> Orit. > >>>> > >>>> -----Original Message----- > >>>> From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org] On > >> Behalf Of > >>>> Rosen, Brian > >>>> Sent: Monday, December 01, 2003 10:26 AM > >>>> To: 'xcon@ietf.org' > >>>> Subject: [XCON] Chicken and Egg - Can CPCP create a conference > >>>> > >>>> I'd like to re-open the requirement to create a > >> conference with CPCP. > >>>> Somehow, I missed that one. > >>>> > >>>> Generally, I think it's a bad idea to have two ways to do > >>>> something, and > >>>> we > >>>> have another way to create a conference (conference > >> factory uri). I'd > >>>> like to eliminate one of them if possible. > >>>> > >>>> Beyond that, it seems to me that there is a chicken and egg > >>>> problem with > >>>> CPCP. That is, how do you "start" sending CPCP "commands", > >>>> and to whom > >>>> do you address them? This is an issue that intertwines with the > >>>> signalling > >>>> protocol (sip). In my mind, the conference uri gave you an > >>>> address (the > >>>> host of the focus) and an identifier (the userpart of the > >> uri). Now, > >>>> in at least the first version of all of this, do we need > >> to have some > >>>> kind > >>>> of discovery mechanism for the conference policy server? > >> I think not, > >>>> or at least I think you get it from the focus. I'd > >> propose that it is > >>>> precisely the host of the focus, but I'd be okay with a > >> query to the > >>>> focus > >>>> that returned the address of the conference policy server. > >>>> > >>>> So, if I were choosing, I would not permit CPCP to create > >> conferences. > >>>> I would rely on the conference factory URI (as well as=20 > out of band > >>>> means). > >>>> I would make the conference policy server the same host as the > >>>> conference > >>>> uri, or at least make the focus return the address of > >>>> conference policy > >>>> server. > >>>> If you need a conference uri to get the conference policy server > >>>> address, > >>>> then you can't use CPCP without a conference URI, and thus > >>>> using CPCP to > >>>> create/discover a conference URI wouldn't work. > >>>> > >>>> Brian > >>>> > >>>> _______________________________________________ > >>>> XCON mailing list > >>>> XCON@ietf.org > >>>> https://www1.ietf.org/mailman/listinfo/xcon > >>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> XCON mailing list > >>>> XCON@ietf.org > >>>> https://www1.ietf.org/mailman/listinfo/xcon > >>>> > >>> > >>> _______________________________________________ > >>> XCON mailing list > >>> XCON@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/xcon > >> > > > > _______________________________________________ > > XCON mailing list > > XCON@ietf.org > > https://www1.ietf.org/mailman/listinfo/xcon >=20 >=20 > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon >=20 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Tue Dec 2 05:12:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10508 for ; Tue, 2 Dec 2003 05:12:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AR7Vj-0007Fw-1k for xcon-archive@odin.ietf.org; Tue, 02 Dec 2003 05:12:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB2AC2Rh027829 for xcon-archive@odin.ietf.org; Tue, 2 Dec 2003 05:12:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AR7Vi-0007Em-Fb for xcon-web-archive@optimus.ietf.org; Tue, 02 Dec 2003 05:12:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10505 for ; Tue, 2 Dec 2003 05:11:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AR7Vf-0004Rj-00 for xcon-web-archive@ietf.org; Tue, 02 Dec 2003 05:11:59 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AR7Ve-0004Rg-00 for xcon-web-archive@ietf.org; Tue, 02 Dec 2003 05:11:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AR7Vh-0007E9-DA; Tue, 02 Dec 2003 05:12:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AR7Uu-0007Dk-06 for xcon@optimus.ietf.org; Tue, 02 Dec 2003 05:11:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10489 for ; Tue, 2 Dec 2003 05:10:57 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AR7Uq-0004RL-00 for xcon@ietf.org; Tue, 02 Dec 2003 05:11:08 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AR7Uq-0004RI-00 for xcon@ietf.org; Tue, 02 Dec 2003 05:11:08 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hB2AB8s16953 for ; Tue, 2 Dec 2003 12:11:08 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 2 Dec 2003 12:11:07 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 2 Dec 2003 12:11:06 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] CPCP - making something simple that works Date: Tue, 2 Dec 2003 12:11:05 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB70179746C@esebe019.ntc.nokia.com> Thread-Topic: [XCON] CPCP - making something simple that works Thread-Index: AcO4JDXEAMOH8VCUSGqo5w4iwpdYOQAmDh2g To: , Cc: , X-OriginalArrivalTime: 02 Dec 2003 10:11:06.0648 (UTC) FILETIME=[9993F980:01C3B8BC] Content-Transfer-Encoding: quoted-printable Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On Behalf Of ext > Michael Hammer > Sent: 01.December.2003 17:58 > To: Henning Schulzrinne > Cc: Khartabil Hisham (NMP-MSW/Helsinki); Isomaki Markus=20 > (NRC/Helsinki); > xcon@ietf.org > Subject: Re: [XCON] CPCP - making something simple that works >=20 >=20 > Henning, >=20 > I can name two cases where explicitly expelling someone is useful: >=20 > 1) An enterprise conference is discussing company sensitive=20 > material of=20 > economic value and someone manages to join and refused to=20 > identify themselves, >=20 > 2) Someone on the conference puts it on hold improperly and=20 > plays music on=20 > hold to the conference. >=20 > Both of these happen frequently enough that an ability to eject the=20 > offending user is desirable and more preferable to wasting=20 > time getting=20 > everyone to move on to another conference. It shouldn't be=20 > necessary to=20 > get hold of a moderator to do the expelling. Of course you need the moderator to do the expelling, otherwise this = unwanted participant can expel other participants. /Hisham >=20 > Mike >=20 >=20 > At 02:27 PM 11/30/2003 -0500, Henning Schulzrinne wrote: >=20 > >>I believe timing is important and is one major advantage of=20 > CPCP over > >>ad-hoc conferences. > > > >Note, however, that this can easily be done by an external=20 > application=20 > >that uses a normal calendaring mechanism (such as the iCal=20 > extensions for=20 > >events) and then generates CPCP requests. Having a very=20 > simple single=20 > >start/end-time (no repeats) is sufficient for that and does not add=20 > >significant complexity. > > > >>What about security of the conference? is that a priority? How > >>desides on the level of security and what protocol to use? who sets > >>the password for the conference? I am ok with having a default > >>authentication mechanism like digest for joining a conference. > > > >I would find it peculiar if joining a conference required=20 > anything other=20 > >than a standard SIP client, for example. > > > >>There is also the issue of expelling users. What is the opinion on > >>that? Is it important? > > > >I have never seen that be used in real conferences, even=20 > where the feature=20 > >was available. If this is a rather rare event, it is easier=20 > to create a=20 > >new conference without the offending user and have everyone=20 > minus one move=20 > >to the new conference. The much more common case is the=20 > executive session=20 > >(or the jury session, e.g., for a thesis defense), which seems most=20 > >readily modeled as two sessions with distinct participants,=20 > set up from=20 > >the beginning. > > > >The problem with expelling is that this adds the risk of accidental=20 > >invocation and probably does not deal with the full range of=20 > Robert's=20 > >Rules stipulations and procedures. > > > >I think a natural threshold for initial inclusion is common usage in=20 > >today's conferencing systems. > > > >Henning > > > >_______________________________________________ > >XCON mailing list > >XCON@ietf.org > >https://www1.ietf.org/mailman/listinfo/xcon >=20 >=20 > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon >=20 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Tue Dec 2 08:17:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15831 for ; Tue, 2 Dec 2003 08:17:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARAOl-0006vV-V0 for xcon-archive@odin.ietf.org; Tue, 02 Dec 2003 08:17:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB2DH3UR026621 for xcon-archive@odin.ietf.org; Tue, 2 Dec 2003 08:17:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARAOl-0006vI-P5 for xcon-web-archive@optimus.ietf.org; Tue, 02 Dec 2003 08:17:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15782 for ; Tue, 2 Dec 2003 08:16:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARAOk-0007S3-00 for xcon-web-archive@ietf.org; Tue, 02 Dec 2003 08:17:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARAOk-0007Ry-00 for xcon-web-archive@ietf.org; Tue, 02 Dec 2003 08:17:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARAOk-0006uq-4G; Tue, 02 Dec 2003 08:17:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARAOJ-0006u3-BB for xcon@optimus.ietf.org; Tue, 02 Dec 2003 08:16:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15735 for ; Tue, 2 Dec 2003 08:16:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARAOI-0007QN-00 for xcon@ietf.org; Tue, 02 Dec 2003 08:16:34 -0500 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 1ARAOH-0007OA-00 for xcon@ietf.org; Tue, 02 Dec 2003 08:16:33 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA01269; Tue, 2 Dec 2003 08:15:55 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA20606; Tue, 2 Dec 2003 08:15:54 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Tue, 2 Dec 2003 08:15:54 -0500 Message-ID: <313680C9A886D511A06000204840E1CF070B614D@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'hisham.khartabil@nokia.com'" , rohan@cisco.com, "'Paul Kyzivat'" Cc: alan.johnston@mci.com, "'georg.mayer@nokia.com'" , oritl@microsoft.com, xcon@ietf.org Subject: RE: [XCON] Chicken and Egg - Can CPCP create a conference Date: Tue, 2 Dec 2003 08:15:54 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , Well it's clear that my view is different from you-all. Not an unfamiliar situation :( Let me keep trying a while, but I'll cave if I'm out here by myself for too long. Several points to make. In my view: 1. "Instantiating" a conference is a concept that is getting confusing. It's all in what you mean. I think it's when the mixer resources are actually allocated (as opposed to reserved). That starts when the first participant creates a dialog with the focus, and ends when the last dialog terminates. Getting a conference ID doesn't instantiate a conference, creating a dialog with it does. You can have a policy on whether the conference ID expires when the last dialog terminates. If it does, once the conference instantiation terminates, it cannot be re-instantiated. If it doesn't, then it can be re-instantiated. An example of the latter is a weekly sales meeting or a "meet-me" number. An example of the latter could be a 4-way call created by a CONF button. 2. You can manipulate policy before you instantiate a conference. As soon as a conference ID is created, policy is available to be manipulated on it. 3. There is almost no difference between a pre-established conference and an ad-hoc conference. Try and think of something that matters: Time between creation of conference ID and instantiation? Nope; you can pre-establish a conference and use it immediately, and there can be an arbitrary delay between requesting an ad-hoc conference and the first dialog with it. And even if there was, who cares? DialIn/DialOut Nope - both can do both, or a mixture of either "Long running conference/chat" Nope; length of time of a conference/chat is not relevant, you could start one ad-hoc and leave it run for years. Therefore, I think you can't use CPCP for pre-established conferences and SIP for ad-hoc conferences. Pick one. There is no justification for two mechanisms to do the same thing. I have a problem with policy creating a conference, and I think SIP signalling is a more appropriate way to create a conference, but I care more about having one and only one way to do it. 4. My view of the conference factory was that you didn't get a conference instantiation from it, you only got a conference ID. Either end would immediately terminate the conference factory dialog, either by an actual BYE or a REFER. If you wanted to immediately instantiate the conference after getting the conferenceID, fine, but you don't have to; you can just get the conference ID and instantiate later. Later could be milliseconds or, if policy allowed, years. 5. I agree that non-SIP signalling mechanisms could be standardized to create conferences (H.323, iCal) if there is a SIP way to do it. There wouldn't be any interoperability issues with that like there would if both CPCP and SIP can do it. Even a single device that had, say, both SIP and iCAL mechanisms would have no interoperability issues with devices that were, say, SIP-only. On the other hand, if you standardize on CPCP to do it, then you would not expect to see any other standardized mechanism. Brian > -----Original Message----- > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > Sent: Tuesday, December 02, 2003 5:07 AM > To: rohan@cisco.com; Brian.Rosen@marconi.com > Cc: alan.johnston@mci.com; oritl@microsoft.com; xcon@ietf.org > Subject: RE: [XCON] Chicken and Egg - Can CPCP create a conference > > > Yes. After the conference server creates the focus on the > scheduled time that was set using CPCP, the focus can use SIP > INVTE or whatever protocol it desires to invite participants > into the conference, or accpet participants to join a conference. > > /Hisham > > > -----Original Message----- > > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On > Behalf Of ext > > Rohan Mahy > > Sent: 02.December.2003 00:58 > > To: Rosen, Brian > > Cc: 'Alan Johnston'; 'Orit Levin'; xcon@ietf.org > > Subject: Re: [XCON] Chicken and Egg - Can CPCP create a conference > > > > > > > > On Monday, December 1, 2003, at 02:06 PM, Rosen, Brian wrote: > > > > > Guilty of not reading documents carefully enough. > > > Most of the "duplicate" mechanisms were, on my reading, merely > > > reflecting the observation that the focus is one end of the > > > dialog each participant has, and in SIP, either end can > > > initiate most operations, thus there is really no possibility > > > of incompatible implementations. Re-reading, I think we may > > > want to beef up the wording to make sure of it. > > > > > > The only case where I think CPCP actually "creates" a conference > > > is where there is a dial out with no-one dialing in before the > > > dial out occurs. It should not be possible, I think, to "create" > > > a conference before someone dials in or the focus dials out. > > > > I can think of several reasons to create a conference before > > there are > > any participants/legs/users: > > > > - A scheduled conference which has policies set by the > creator before > > the creator joins > > - A long running conference/group chat > > - A dial out conference > > > > So clearly having a mechanism to create conferences using > CPCP makes > > sense. > > > > Now if someone wants to create (possibly standardized) > mechanisms in > > other protocols to create an XCON conference, I see no > > reason why this > > is a problem. The SIP conferencing framework describes a role (a > > conference factory) that has a URI you can INVITE that will > create an > > XCON conference. You could define a similar function for > HTTP, XMPP, > > iCal via SMTP, or H.323. > > > > thanks, > > -rohan > > > > > Similarly, a conference is destroyed when the last dialog is > > > terminated with a BYE, which may very well be by the focus, > > > but it is not terminated explicitly by CPCP. > > > > > > Looking at the other mechanisms: > > > Adding participants > > > Similar to creating conferences, you can dial out or dial in. > > > I think we might want to observe in the text that focus > > > implementations MUST accept INVITES and REFERS, as well as > > > CPCP requests to send INVITES. A UA could implement either or > > > both mechanisms. I would observe that if a UA wishes to promote > > > a two way to a conference, then it would have to use a > > REFER, and > > > no other mechanism. I'd prefer that the SIP way be the > > only way, > > > but the carriers seem to want to control who does the > > dialing, so > > > there is no way the community would support REFER only. > > > Removing Participants > > > Again, mostly a "both ends of the dialog" issue. BYE from focus > > > really is an acceptable way to boot someone. 3rd party REFER > > > really is a duplicate, but prohibiting it seems unlikely. In > > > most systems it wouldn't work from, say, a moderator, because > > > of security issues (a random user can't REFER/BYE you I hope). > > > Probably need to expand that wording to say "third person > > > (another participant) departures..." I don't want to imply > > > that the focus would use REFER. It would use BYE. > > > > > > I note that the text in this section about the focus > > manipulating > > > other dialogs is misplaced, because it would do the same thing > > > if the participant was removed by SIP or any other means. > > > Obtaining Membership > > > I don't see why we need two mechanisms. If we keep > > both, then we > > > should explicitly require a focus to implement both. I really > > > don't care which one we keep. > > > > > > Adding and Removing Media > > > "Both ends of the dialog" issues. Again, a focus probably can't > > > help but implement both, but it might be good to say that > > > explicitly somewhere. > > > > > > Brian > > > > > > > > >> -----Original Message----- > > >> From: Alan Johnston [mailto:alan.johnston@mci.com] > > >> Sent: Monday, December 01, 2003 4:12 PM > > >> To: Rosen, Brian; 'Orit Levin'; xcon@ietf.org > > >> Subject: RE: [XCON] Chicken and Egg - Can CPCP create a > conference > > >> > > >> > > >> At 03:36 PM 12/1/2003 -0500, Rosen, Brian wrote: > > >>> Orit > > >>> > > >>> Keeping XCON separate from SIP is useful so long as it doesn't > > >>> get in the way of common sense. To me, that would mean, > > for example, > > >>> having a different name space for a conference ID, requiring one > > >>> for CPCP and another for SIP. If a conference ID in > CPCP is not a > > >>> uri, for which a SIP uri is an excellent, but not > > limiting example, > > >>> I have a very large problem. > > >>> > > >>> I don't care if some day, someone invents a way to use > > CPCP without > > >>> SIP, and I don't have any interest in making that difficult > > >> in any way. > > >>> However, it's not a driving function, and I don't think there is > > >>> any reason to have more than one standardized way to create > > >> a conference. > > >>> An INVITE to a conference URI does it. A specific > > implementation may > > >>> have some other, non standardized way. I want ONE > > standardized way, > > >>> unless someone has a compelling reason why we need to have two. > > >>> It's a broken record; when you have multiple ways to do the > > >> same thing, > > >>> you facilitate incompatible implementations. If there > > are a million > > >>> ways, you will have a lot of incompatible systems. I have > > >> no interest > > >>> in fostering that kind of design. > > >> > > >> Brian, > > >> > > >> Please re-read the SIP Conferencing Framework document - > > >> practically every > > >> conference-related operation has both a SIP and a non-SIP > > >> mechanism to do so. > > >> > > >> Thanks, > > >> Alan > > >> sip:alan@sipstation.com > > >> > > >> > > >> > > >> > > >>> Brian > > >>> > > >>> > > >>> > > >>> > > >>>> -----Original Message----- > > >>>> From: Orit Levin [mailto:oritl@microsoft.com] > > >>>> Sent: Monday, December 01, 2003 3:02 PM > > >>>> To: Rosen, Brian; xcon@ietf.org > > >>>> Subject: RE: [XCON] Chicken and Egg - Can CPCP create a > > conference > > >>>> > > >>>> > > >>>> Brian! > > >>>> I am actually surprised by this thread. > > >>>> > > >>>> In reality, a single conference instance can be > > >> potentially defined / > > >>>> requested by million ways. Moreover, the same conference > > >> instance can > > >>>> host participants joining by very different means and > > >> media. Moreover, > > >>>> the same conference can have more than a single unique > > >> identifier... > > >>>> > > >>>> SIP conferencing and XCON conferencing must be able to > > >> coexist in the > > >>>> system and share same conference instances but apart from > > >>>> that - each is > > >>>> a "complete system" on its own. (SIP point-to-point CC is > > >> a different > > >>>> issue - it is one of the tools available for XCON.) > > >>>> > > >>>> As a result, the discussion of the addressing scheme should > > >>>> first apply > > >>>> to the SIPPING conferencing work. (In XCON we still need to > > >>>> agree on the > > >>>> higher level architectural decomposition of the pieces > > >> that we managed > > >>>> to introduce.) > > >>>> > > >>>> In particular, draft-ietf-sipping-cc-conferencing-02.txt > > >> has different > > >>>> assumptions or, I should say, is less restrictive that > > you propose > > >>>> below. BTW, it does define that "calling a Factory" results in > > >>>> establishing a conference with its focus (either through the > > >>>> same dialog > > >>>> or by redirection to a focus - both are valid cases). If we > > >>>> disagree on > > >>>> this, let's start this discussion in SIPPING ASAP. > > >>>> > > >>>> Orit. > > >>>> > > >>>> -----Original Message----- > > >>>> From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org] On > > >> Behalf Of > > >>>> Rosen, Brian > > >>>> Sent: Monday, December 01, 2003 10:26 AM > > >>>> To: 'xcon@ietf.org' > > >>>> Subject: [XCON] Chicken and Egg - Can CPCP create a conference > > >>>> > > >>>> I'd like to re-open the requirement to create a > > >> conference with CPCP. > > >>>> Somehow, I missed that one. > > >>>> > > >>>> Generally, I think it's a bad idea to have two ways to do > > >>>> something, and > > >>>> we > > >>>> have another way to create a conference (conference > > >> factory uri). I'd > > >>>> like to eliminate one of them if possible. > > >>>> > > >>>> Beyond that, it seems to me that there is a chicken and egg > > >>>> problem with > > >>>> CPCP. That is, how do you "start" sending CPCP "commands", > > >>>> and to whom > > >>>> do you address them? This is an issue that > intertwines with the > > >>>> signalling > > >>>> protocol (sip). In my mind, the conference uri gave you an > > >>>> address (the > > >>>> host of the focus) and an identifier (the userpart of the > > >> uri). Now, > > >>>> in at least the first version of all of this, do we need > > >> to have some > > >>>> kind > > >>>> of discovery mechanism for the conference policy server? > > >> I think not, > > >>>> or at least I think you get it from the focus. I'd > > >> propose that it is > > >>>> precisely the host of the focus, but I'd be okay with a > > >> query to the > > >>>> focus > > >>>> that returned the address of the conference policy server. > > >>>> > > >>>> So, if I were choosing, I would not permit CPCP to create > > >> conferences. > > >>>> I would rely on the conference factory URI (as well as > > out of band > > >>>> means). > > >>>> I would make the conference policy server the same host as the > > >>>> conference > > >>>> uri, or at least make the focus return the address of > > >>>> conference policy > > >>>> server. > > >>>> If you need a conference uri to get the conference > policy server > > >>>> address, > > >>>> then you can't use CPCP without a conference URI, and thus > > >>>> using CPCP to > > >>>> create/discover a conference URI wouldn't work. > > >>>> > > >>>> Brian > > >>>> > > >>>> _______________________________________________ > > >>>> XCON mailing list > > >>>> XCON@ietf.org > > >>>> https://www1.ietf.org/mailman/listinfo/xcon > > >>>> > > >>>> > > >>>> > > >>>> _______________________________________________ > > >>>> XCON mailing list > > >>>> XCON@ietf.org > > >>>> https://www1.ietf.org/mailman/listinfo/xcon > > >>>> > > >>> > > >>> _______________________________________________ > > >>> XCON mailing list > > >>> XCON@ietf.org > > >>> https://www1.ietf.org/mailman/listinfo/xcon > > >> > > > > > > _______________________________________________ > > > XCON mailing list > > > XCON@ietf.org > > > https://www1.ietf.org/mailman/listinfo/xcon > > > > > > _______________________________________________ > > XCON mailing list > > XCON@ietf.org > > https://www1.ietf.org/mailman/listinfo/xcon > > > _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Tue Dec 2 09:27:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18656 for ; Tue, 2 Dec 2003 09:27:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARBUU-0001eO-QD for xcon-archive@odin.ietf.org; Tue, 02 Dec 2003 09:27:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB2ER2nB006343 for xcon-archive@odin.ietf.org; Tue, 2 Dec 2003 09:27:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARBUU-0001eE-K7 for xcon-web-archive@optimus.ietf.org; Tue, 02 Dec 2003 09:27:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18637 for ; Tue, 2 Dec 2003 09:26:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARBUT-0001UY-00 for xcon-web-archive@ietf.org; Tue, 02 Dec 2003 09:27:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARBUS-0001UV-00 for xcon-web-archive@ietf.org; Tue, 02 Dec 2003 09:27:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARBUS-0001dx-N0; Tue, 02 Dec 2003 09:27:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARBTh-0001cw-CS for xcon@optimus.ietf.org; Tue, 02 Dec 2003 09:26:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18615 for ; Tue, 2 Dec 2003 09:25:59 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARBTf-0001Tz-00 for xcon@ietf.org; Tue, 02 Dec 2003 09:26:11 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1ARBTe-0001Tv-00 for xcon@ietf.org; Tue, 02 Dec 2003 09:26:10 -0500 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hB2EQ9E10311 for ; Tue, 2 Dec 2003 16:26:09 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 2 Dec 2003 16:26:08 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 2 Dec 2003 16:26:08 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] Chicken and Egg - Can CPCP create a conference Date: Tue, 2 Dec 2003 16:26:08 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB70118B116@esebe019.ntc.nokia.com> Thread-Topic: [XCON] Chicken and Egg - Can CPCP create a conference Thread-Index: AcO41oT2atfEKGBKQTqla0og8q38cgAB8unQ To: , , Cc: , , , X-OriginalArrivalTime: 02 Dec 2003 14:26:08.0557 (UTC) FILETIME=[3A39FDD0:01C3B8E0] Content-Transfer-Encoding: quoted-printable Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ext Rosen, Brian [mailto:Brian.Rosen@marconi.com] > Sent: 02.December.2003 15:16 > To: Khartabil Hisham (NMP-MSW/Helsinki); rohan@cisco.com;=20 > 'Paul Kyzivat' > Cc: alan.johnston@mci.com; Mayer Georg (NMP-MSW/Helsinki); > oritl@microsoft.com; xcon@ietf.org > Subject: RE: [XCON] Chicken and Egg - Can CPCP create a conference >=20 >=20 > Well it's clear that my view is different from you-all. > Not an unfamiliar situation :( > Let me keep trying a while, but I'll cave if I'm out here > by myself for too long. >=20 > Several points to make. In my view: > 1. "Instantiating" a conference is a concept that is getting=20 > confusing. > It's all in what you mean. I think it's when the mixer resources > are actually allocated (as opposed to reserved). That starts when > the first participant creates a dialog with the focus, and ends > when the last dialog terminates. Getting a conference ID doesn't > instantiate a conference, creating a dialog with it does. Some chat type conferences can exist without any participants. = Participants come and go as they please. Why is there a requirement that = at least one participant is needed for the conference to ever exist? >=20 > You can have a policy on whether the conference ID expires when=20 > the last dialog terminates. If it does, once the conference > instantiation terminates, it cannot be re-instantiated. =20 > If it doesn't, then it can be re-instantiated. An example of the=20 > latter is a weekly sales meeting or a "meet-me" number. =20 > An example of the latter could be a 4-way call created by a CONF=20 > button. >=20 > 2. You can manipulate policy before you instantiate a conference. > As soon as a conference ID is created, policy is available to be > manipulated on it. =20 Agreed on the part, but I don't think you need the conferece ID (that is = the SIP URI for the conference) in order to manipulate the policy. CPCP = can provide its own conference policy ID that is somehow mapped to a = conference ID. This depends on the protocol chosen for CPCP. >=20 > 3. There is almost no difference between a pre-established=20 > conference and an ad-hoc conference. Try and think of something=20 > that matters: > Time between creation of conference ID and instantiation? > Nope; you can pre-establish a conference and use it=20 > immediately, and there can be an arbitrary=20 > delay between=20 > requesting an ad-hoc conference and the first dialog=20 > with it. And even if there was, who cares? You are asking to redefine the whole concept of ah-hoc conferencing = using SIP. The INVITE creates a conference, and creates a dialog. > DialIn/DialOut=20 > Nope - both can do both, or a mixture of either How can you limit the dail-in list in an ad-hoc conference. Let me = remind you that an ad-hoc conference does not have a policy. For dial-out list, it is true that you can send REFER requests for the = focus, but again, you cannot predefine that list. Also, you have to send = a REFER to the focus for each potential participant, creating x number = of dialogs, one for each REFER request. > "Long running conference/chat" Nope; length of time of a > conference/chat is not relevant, you could start one=20 > ad-hoc and leave it run for years. again, with ad-hoc conferences, there is no policy to dictate this. I = think I will stop commenting now until someone agrues that I am wrong = and an ah-hoc conference also needs a policy (where my reply would be: = why is it called ah-hoc then?). Regards, Hisham > Therefore, I think you can't use CPCP for pre-established=20 > conferences and SIP for ad-hoc conferences. Pick one. There is no=20 > justification for two mechanisms to do the same thing. I have a=20 > problem with policy creating a conference, and I think SIP=20 > signalling is a more appropriate way to create a conference, but=20 > I care more about having one and only one way to do it. >=20 > 4. My view of the conference factory was that you didn't get a=20 > conference instantiation from it, you only got a conference ID. =20 > Either end would immediately terminate the conference factory dialog,=20 > either by an actual BYE or a REFER. If you wanted to immediately=20 > instantiate the conference after getting the conferenceID, fine,=20 > but you don't have to; you can just get the conference ID and > instantiate later. Later could be milliseconds or, if policy=20 > allowed, years. >=20 > 5. I agree that non-SIP signalling mechanisms could be standardized=20 > to create conferences (H.323, iCal) if there is a SIP way to do it. =20 > There wouldn't be any interoperability issues with that like there=20 > would if both CPCP and SIP can do it. Even a single device that had,=20 > say, both SIP and iCAL mechanisms would have no interoperability=20 > issues with devices that were, say, SIP-only. On the other hand,=20 > if you standardize on CPCP to do it, then you would not expect to=20 > see any other standardized mechanism. >=20 > Brian >=20 > > -----Original Message----- > > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > > Sent: Tuesday, December 02, 2003 5:07 AM > > To: rohan@cisco.com; Brian.Rosen@marconi.com > > Cc: alan.johnston@mci.com; oritl@microsoft.com; xcon@ietf.org > > Subject: RE: [XCON] Chicken and Egg - Can CPCP create a conference > >=20 > >=20 > > Yes. After the conference server creates the focus on the=20 > > scheduled time that was set using CPCP, the focus can use SIP=20 > > INVTE or whatever protocol it desires to invite participants=20 > > into the conference, or accpet participants to join a conference. > >=20 > > /Hisham > >=20 > > > -----Original Message----- > > > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On=20 > > Behalf Of ext > > > Rohan Mahy > > > Sent: 02.December.2003 00:58 > > > To: Rosen, Brian > > > Cc: 'Alan Johnston'; 'Orit Levin'; xcon@ietf.org > > > Subject: Re: [XCON] Chicken and Egg - Can CPCP create a conference > > >=20 > > >=20 > > >=20 > > > On Monday, December 1, 2003, at 02:06 PM, Rosen, Brian wrote: > > >=20 > > > > Guilty of not reading documents carefully enough. > > > > Most of the "duplicate" mechanisms were, on my reading, merely > > > > reflecting the observation that the focus is one end of the > > > > dialog each participant has, and in SIP, either end can > > > > initiate most operations, thus there is really no possibility > > > > of incompatible implementations. Re-reading, I think we may > > > > want to beef up the wording to make sure of it. > > > > > > > > The only case where I think CPCP actually "creates" a conference > > > > is where there is a dial out with no-one dialing in before the > > > > dial out occurs. It should not be possible, I think,=20 > to "create" > > > > a conference before someone dials in or the focus dials out. > > >=20 > > > I can think of several reasons to create a conference before=20 > > > there are=20 > > > any participants/legs/users: > > >=20 > > > - A scheduled conference which has policies set by the=20 > > creator before=20 > > > the creator joins > > > - A long running conference/group chat > > > - A dial out conference > > >=20 > > > So clearly having a mechanism to create conferences using=20 > > CPCP makes=20 > > > sense. > > >=20 > > > Now if someone wants to create (possibly standardized)=20 > > mechanisms in=20 > > > other protocols to create an XCON conference, I see no=20 > > > reason why this=20 > > > is a problem. The SIP conferencing framework describes a role (a=20 > > > conference factory) that has a URI you can INVITE that will=20 > > create an=20 > > > XCON conference. You could define a similar function for=20 > > HTTP, XMPP,=20 > > > iCal via SMTP, or H.323. > > >=20 > > > thanks, > > > -rohan > > >=20 > > > > Similarly, a conference is destroyed when the last dialog is > > > > terminated with a BYE, which may very well be by the focus, > > > > but it is not terminated explicitly by CPCP. > > > > > > > > Looking at the other mechanisms: > > > > Adding participants > > > > Similar to creating conferences, you can dial=20 > out or dial in. > > > > I think we might want to observe in the text that focus > > > > implementations MUST accept INVITES and REFERS,=20 > as well as > > > > CPCP requests to send INVITES. A UA could=20 > implement either or > > > > both mechanisms. I would observe that if a UA=20 > wishes to promote > > > > a two way to a conference, then it would have to use a=20 > > > REFER, and > > > > no other mechanism. I'd prefer that the SIP way be the=20 > > > only way, > > > > but the carriers seem to want to control who does the=20 > > > dialing, so > > > > there is no way the community would support REFER only. > > > > Removing Participants > > > > Again, mostly a "both ends of the dialog"=20 > issue. BYE from focus > > > > really is an acceptable way to boot someone. =20 > 3rd party REFER > > > > really is a duplicate, but prohibiting it seems=20 > unlikely. In > > > > most systems it wouldn't work from, say, a=20 > moderator, because > > > > of security issues (a random user can't=20 > REFER/BYE you I hope). > > > > Probably need to expand that wording to say=20 > "third person > > > > (another participant) departures..." I don't=20 > want to imply > > > > that the focus would use REFER. It would use BYE. > > > > > > > > I note that the text in this section about the focus=20 > > > manipulating > > > > other dialogs is misplaced, because it would do=20 > the same thing > > > > if the participant was removed by SIP or any=20 > other means. > > > > Obtaining Membership > > > > I don't see why we need two mechanisms. If we keep=20 > > > both, then we > > > > should explicitly require a focus to implement=20 > both. I really > > > > don't care which one we keep. > > > > > > > > Adding and Removing Media > > > > "Both ends of the dialog" issues. Again, a=20 > focus probably can't > > > > help but implement both, but it might be good=20 > to say that > > > > explicitly somewhere. > > > > > > > > Brian > > > > > > > > > > > >> -----Original Message----- > > > >> From: Alan Johnston [mailto:alan.johnston@mci.com] > > > >> Sent: Monday, December 01, 2003 4:12 PM > > > >> To: Rosen, Brian; 'Orit Levin'; xcon@ietf.org > > > >> Subject: RE: [XCON] Chicken and Egg - Can CPCP create a=20 > > conference > > > >> > > > >> > > > >> At 03:36 PM 12/1/2003 -0500, Rosen, Brian wrote: > > > >>> Orit > > > >>> > > > >>> Keeping XCON separate from SIP is useful so long as it doesn't > > > >>> get in the way of common sense. To me, that would mean,=20 > > > for example, > > > >>> having a different name space for a conference ID,=20 > requiring one > > > >>> for CPCP and another for SIP. If a conference ID in=20 > > CPCP is not a > > > >>> uri, for which a SIP uri is an excellent, but not=20 > > > limiting example, > > > >>> I have a very large problem. > > > >>> > > > >>> I don't care if some day, someone invents a way to use=20 > > > CPCP without > > > >>> SIP, and I don't have any interest in making that difficult > > > >> in any way. > > > >>> However, it's not a driving function, and I don't=20 > think there is > > > >>> any reason to have more than one standardized way to create > > > >> a conference. > > > >>> An INVITE to a conference URI does it. A specific=20 > > > implementation may > > > >>> have some other, non standardized way. I want ONE=20 > > > standardized way, > > > >>> unless someone has a compelling reason why we need to=20 > have two. > > > >>> It's a broken record; when you have multiple ways to do the > > > >> same thing, > > > >>> you facilitate incompatible implementations. If there=20 > > > are a million > > > >>> ways, you will have a lot of incompatible systems. I have > > > >> no interest > > > >>> in fostering that kind of design. > > > >> > > > >> Brian, > > > >> > > > >> Please re-read the SIP Conferencing Framework document - > > > >> practically every > > > >> conference-related operation has both a SIP and a non-SIP > > > >> mechanism to do so. > > > >> > > > >> Thanks, > > > >> Alan > > > >> sip:alan@sipstation.com > > > >> > > > >> > > > >> > > > >> > > > >>> Brian > > > >>> > > > >>> > > > >>> > > > >>> > > > >>>> -----Original Message----- > > > >>>> From: Orit Levin [mailto:oritl@microsoft.com] > > > >>>> Sent: Monday, December 01, 2003 3:02 PM > > > >>>> To: Rosen, Brian; xcon@ietf.org > > > >>>> Subject: RE: [XCON] Chicken and Egg - Can CPCP create a=20 > > > conference > > > >>>> > > > >>>> > > > >>>> Brian! > > > >>>> I am actually surprised by this thread. > > > >>>> > > > >>>> In reality, a single conference instance can be > > > >> potentially defined / > > > >>>> requested by million ways. Moreover, the same conference > > > >> instance can > > > >>>> host participants joining by very different means and > > > >> media. Moreover, > > > >>>> the same conference can have more than a single unique > > > >> identifier... > > > >>>> > > > >>>> SIP conferencing and XCON conferencing must be able to > > > >> coexist in the > > > >>>> system and share same conference instances but apart from > > > >>>> that - each is > > > >>>> a "complete system" on its own. (SIP point-to-point CC is > > > >> a different > > > >>>> issue - it is one of the tools available for XCON.) > > > >>>> > > > >>>> As a result, the discussion of the addressing scheme should > > > >>>> first apply > > > >>>> to the SIPPING conferencing work. (In XCON we still need to > > > >>>> agree on the > > > >>>> higher level architectural decomposition of the pieces > > > >> that we managed > > > >>>> to introduce.) > > > >>>> > > > >>>> In particular, draft-ietf-sipping-cc-conferencing-02.txt > > > >> has different > > > >>>> assumptions or, I should say, is less restrictive that=20 > > > you propose > > > >>>> below. BTW, it does define that "calling a Factory"=20 > results in > > > >>>> establishing a conference with its focus (either through the > > > >>>> same dialog > > > >>>> or by redirection to a focus - both are valid cases). If we > > > >>>> disagree on > > > >>>> this, let's start this discussion in SIPPING ASAP. > > > >>>> > > > >>>> Orit. > > > >>>> > > > >>>> -----Original Message----- > > > >>>> From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org] On > > > >> Behalf Of > > > >>>> Rosen, Brian > > > >>>> Sent: Monday, December 01, 2003 10:26 AM > > > >>>> To: 'xcon@ietf.org' > > > >>>> Subject: [XCON] Chicken and Egg - Can CPCP create a=20 > conference > > > >>>> > > > >>>> I'd like to re-open the requirement to create a > > > >> conference with CPCP. > > > >>>> Somehow, I missed that one. > > > >>>> > > > >>>> Generally, I think it's a bad idea to have two ways to do > > > >>>> something, and > > > >>>> we > > > >>>> have another way to create a conference (conference > > > >> factory uri). I'd > > > >>>> like to eliminate one of them if possible. > > > >>>> > > > >>>> Beyond that, it seems to me that there is a chicken and egg > > > >>>> problem with > > > >>>> CPCP. That is, how do you "start" sending CPCP "commands", > > > >>>> and to whom > > > >>>> do you address them? This is an issue that=20 > > intertwines with the > > > >>>> signalling > > > >>>> protocol (sip). In my mind, the conference uri gave you an > > > >>>> address (the > > > >>>> host of the focus) and an identifier (the userpart of the > > > >> uri). Now, > > > >>>> in at least the first version of all of this, do we need > > > >> to have some > > > >>>> kind > > > >>>> of discovery mechanism for the conference policy server? > > > >> I think not, > > > >>>> or at least I think you get it from the focus. I'd > > > >> propose that it is > > > >>>> precisely the host of the focus, but I'd be okay with a > > > >> query to the > > > >>>> focus > > > >>>> that returned the address of the conference policy server. > > > >>>> > > > >>>> So, if I were choosing, I would not permit CPCP to create > > > >> conferences. > > > >>>> I would rely on the conference factory URI (as well as=20 > > > out of band > > > >>>> means). > > > >>>> I would make the conference policy server the same=20 > host as the > > > >>>> conference > > > >>>> uri, or at least make the focus return the address of > > > >>>> conference policy > > > >>>> server. > > > >>>> If you need a conference uri to get the conference=20 > > policy server > > > >>>> address, > > > >>>> then you can't use CPCP without a conference URI, and thus > > > >>>> using CPCP to > > > >>>> create/discover a conference URI wouldn't work. > > > >>>> > > > >>>> Brian > > > >>>> > > > >>>> _______________________________________________ > > > >>>> XCON mailing list > > > >>>> XCON@ietf.org > > > >>>> https://www1.ietf.org/mailman/listinfo/xcon > > > >>>> > > > >>>> > > > >>>> > > > >>>> _______________________________________________ > > > >>>> XCON mailing list > > > >>>> XCON@ietf.org > > > >>>> https://www1.ietf.org/mailman/listinfo/xcon > > > >>>> > > > >>> > > > >>> _______________________________________________ > > > >>> XCON mailing list > > > >>> XCON@ietf.org > > > >>> https://www1.ietf.org/mailman/listinfo/xcon > > > >> > > > > > > > > _______________________________________________ > > > > XCON mailing list > > > > XCON@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/xcon > > >=20 > > >=20 > > > _______________________________________________ > > > XCON mailing list > > > XCON@ietf.org > > > https://www1.ietf.org/mailman/listinfo/xcon > > >=20 > >=20 >=20 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Tue Dec 2 09:53:18 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19518 for ; Tue, 2 Dec 2003 09:53:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARBte-0002Vo-5K for xcon-archive@odin.ietf.org; Tue, 02 Dec 2003 09:53:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB2Er2k4009650 for xcon-archive@odin.ietf.org; Tue, 2 Dec 2003 09:53:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARBtd-0002VV-V4 for xcon-web-archive@optimus.ietf.org; Tue, 02 Dec 2003 09:53:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19512 for ; Tue, 2 Dec 2003 09:52:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARBtc-0001rN-00 for xcon-web-archive@ietf.org; Tue, 02 Dec 2003 09:53:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARBtb-0001rK-00 for xcon-web-archive@ietf.org; Tue, 02 Dec 2003 09:52:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARBtc-0002VC-C6; Tue, 02 Dec 2003 09:53:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARBt7-0002UY-Lw for xcon@optimus.ietf.org; Tue, 02 Dec 2003 09:52:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19509 for ; Tue, 2 Dec 2003 09:52:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARBt5-0001rF-00 for xcon@ietf.org; Tue, 02 Dec 2003 09:52:27 -0500 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 1ARBt5-0001rB-00 for xcon@ietf.org; Tue, 02 Dec 2003 09:52:27 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA05281; Tue, 2 Dec 2003 09:51:53 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA06607; Tue, 2 Dec 2003 09:51:53 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Tue, 2 Dec 2003 09:51:53 -0500 Message-ID: <313680C9A886D511A06000204840E1CF070B6150@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'hisham.khartabil@nokia.com'" , rohan@cisco.com, pkyzivat@cisco.com Cc: alan.johnston@mci.com, georg.mayer@nokia.com, oritl@microsoft.com, xcon@ietf.org Subject: RE: [XCON] Chicken and Egg - Can CPCP create a conference Date: Tue, 2 Dec 2003 09:51:51 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , So, two fundamental differences: 1. You think CPCP has some separate namespace independent of a URI (of which a SIP uri is a good, but not exclusive example). I am opposed to that. A conferenceID is a uri. I can imagine a specific instance of a conference service that could have multiple IDs for the same conference, for example, an H.323 URI and a SIP URI that resolves to the same conference. That's fine, and it's not subject to standardization. However, I think that the ID you use with the focus is always the ID you use with CPCP for the same conference. 2. You think ad-hoc conferences don't have policy. I am fundamentally opposed to that. Ad-hoc conferences should have all of the functionality of a pre-established conference and I can't imagine any reason why we can't provide that. We also have a nit, at least I think it's a nit, about Instantiation. I'm not sure there is any real difference between a re-usable conference ID and an instantiated conference that has no participants. Since I define instantiated as allocated mixer resources, if I'm not using resources I don't have the conference instantiated. If you define instantiation differently, then you could. It would be good, I think, to have a common agreement on what instantiation means, because we use it in the documents, but I'm not sure we disagree on what can happen. We both agree you can manipulate policy, and we both agree participants can come and go. I guess I would ask you if you have some notion of a re-usable conference ID that is somehow different from an instantiated conference with no participants. Brian > -----Original Message----- > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > Sent: Tuesday, December 02, 2003 9:26 AM > To: Brian.Rosen@marconi.com; rohan@cisco.com; pkyzivat@cisco.com > Cc: alan.johnston@mci.com; georg.mayer@nokia.com; oritl@microsoft.com; > xcon@ietf.org > Subject: RE: [XCON] Chicken and Egg - Can CPCP create a conference > > > > > > -----Original Message----- > > From: ext Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > Sent: 02.December.2003 15:16 > > To: Khartabil Hisham (NMP-MSW/Helsinki); rohan@cisco.com; > > 'Paul Kyzivat' > > Cc: alan.johnston@mci.com; Mayer Georg (NMP-MSW/Helsinki); > > oritl@microsoft.com; xcon@ietf.org > > Subject: RE: [XCON] Chicken and Egg - Can CPCP create a conference > > > > > > Well it's clear that my view is different from you-all. > > Not an unfamiliar situation :( > > Let me keep trying a while, but I'll cave if I'm out here > > by myself for too long. > > > > Several points to make. In my view: > > 1. "Instantiating" a conference is a concept that is getting > > confusing. > > It's all in what you mean. I think it's when the mixer resources > > are actually allocated (as opposed to reserved). That starts when > > the first participant creates a dialog with the focus, and ends > > when the last dialog terminates. Getting a conference ID doesn't > > instantiate a conference, creating a dialog with it does. > > Some chat type conferences can exist without any > participants. Participants come and go as they please. Why is > there a requirement that at least one participant is needed > for the conference to ever exist? > > > > > You can have a policy on whether the conference ID expires when > > the last dialog terminates. If it does, once the conference > > instantiation terminates, it cannot be re-instantiated. > > If it doesn't, then it can be re-instantiated. An example of the > > latter is a weekly sales meeting or a "meet-me" number. > > An example of the latter could be a 4-way call created by a CONF > > button. > > > > 2. You can manipulate policy before you instantiate a conference. > > As soon as a conference ID is created, policy is available to be > > manipulated on it. > > Agreed on the part, but I don't think you need the conferece > ID (that is the SIP URI for the conference) in order to > manipulate the policy. CPCP can provide its own conference > policy ID that is somehow mapped to a conference ID. This > depends on the protocol chosen for CPCP. > > > > > 3. There is almost no difference between a pre-established > > conference and an ad-hoc conference. Try and think of something > > that matters: > > Time between creation of conference ID and instantiation? > > Nope; you can pre-establish a conference and use it > > immediately, and there can be an arbitrary > > delay between > > requesting an ad-hoc conference and the first dialog > > with it. And even if there was, who cares? > > You are asking to redefine the whole concept of ah-hoc > conferencing using SIP. The INVITE creates a conference, and > creates a dialog. > > > DialIn/DialOut > > Nope - both can do both, or a mixture of either > > How can you limit the dail-in list in an ad-hoc conference. > Let me remind you that an ad-hoc conference does not have a policy. > > For dial-out list, it is true that you can send REFER > requests for the focus, but again, you cannot predefine that > list. Also, you have to send a REFER to the focus for each > potential participant, creating x number of dialogs, one for > each REFER request. > > > > "Long running conference/chat" Nope; length of time of a > > conference/chat is not relevant, you could start one > > ad-hoc and leave it run for years. > > again, with ad-hoc conferences, there is no policy to dictate > this. I think I will stop commenting now until someone agrues > that I am wrong and an ah-hoc conference also needs a policy > (where my reply would be: why is it called ah-hoc then?). > > Regards, > Hisham > > > Therefore, I think you can't use CPCP for pre-established > > conferences and SIP for ad-hoc conferences. Pick one. There is no > > justification for two mechanisms to do the same thing. I have a > > problem with policy creating a conference, and I think SIP > > signalling is a more appropriate way to create a conference, but > > I care more about having one and only one way to do it. > > > > 4. My view of the conference factory was that you didn't get a > > conference instantiation from it, you only got a conference ID. > > Either end would immediately terminate the conference > factory dialog, > > either by an actual BYE or a REFER. If you wanted to immediately > > instantiate the conference after getting the conferenceID, fine, > > but you don't have to; you can just get the conference ID and > > instantiate later. Later could be milliseconds or, if policy > > allowed, years. > > > > 5. I agree that non-SIP signalling mechanisms could be standardized > > to create conferences (H.323, iCal) if there is a SIP way > to do it. > > There wouldn't be any interoperability issues with that like there > > would if both CPCP and SIP can do it. Even a single device > that had, > > say, both SIP and iCAL mechanisms would have no interoperability > > issues with devices that were, say, SIP-only. On the other hand, > > if you standardize on CPCP to do it, then you would not expect to > > see any other standardized mechanism. > > > > Brian > > > _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Tue Dec 2 10:05:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19997 for ; Tue, 2 Dec 2003 10:05:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARC5H-0002r2-NE for xcon-archive@odin.ietf.org; Tue, 02 Dec 2003 10:05:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB2F53a9010966 for xcon-archive@odin.ietf.org; Tue, 2 Dec 2003 10:05:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARC5G-0002qn-Tq for xcon-web-archive@optimus.ietf.org; Tue, 02 Dec 2003 10:05:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19915 for ; Tue, 2 Dec 2003 10:04:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARC5E-0001xC-00 for xcon-web-archive@ietf.org; Tue, 02 Dec 2003 10:05:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARC5E-0001x9-00 for xcon-web-archive@ietf.org; Tue, 02 Dec 2003 10:05:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARC5F-0002qV-GV; Tue, 02 Dec 2003 10:05:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARC4O-0002pZ-Up for xcon@optimus.ietf.org; Tue, 02 Dec 2003 10:04:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19805 for ; Tue, 2 Dec 2003 10:03:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARC4M-0001wh-00 for xcon@ietf.org; Tue, 02 Dec 2003 10:04:06 -0500 Received: from thoth.sbs.de ([192.35.17.2]) by ietf-mx with esmtp (Exim 4.12) id 1ARC4M-0001we-00 for xcon@ietf.org; Tue, 02 Dec 2003 10:04:06 -0500 Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by thoth.sbs.de (8.11.7/8.11.7) with ESMTP id hB2F3S209845; Tue, 2 Dec 2003 16:03:28 +0100 (MET) Received: from moody.mchh.siemens.de (moody.mchh.siemens.de [139.21.205.85]) by mail2.siemens.de (8.11.7/8.11.7) with ESMTP id hB2F3RP13830; Tue, 2 Dec 2003 16:03:27 +0100 (MET) Received: from mchh273e.mchh.siemens.de (mchh273e.mchh.siemens.de [139.21.200.83]) by moody.mchh.siemens.de (8.9.3/8.9.1) with ESMTP id QAA17155; Tue, 2 Dec 2003 16:03:26 +0100 (MET) Received: by mchh273e.mchh.siemens.de with Internet Mail Service (5.5.2656.59) id ; Tue, 2 Dec 2003 16:03:24 +0100 Message-ID: <76592C4D3DA1AC4FB8424084D10D31A8D5CE69@mchh2c4e.mchh.siemens.de> From: Heil Franca Marcelo To: "'hisham.khartabil@nokia.com'" , Brian.Rosen@marconi.com, rohan@cisco.com, pkyzivat@cisco.com Cc: alan.johnston@mci.com, georg.mayer@nokia.com, oritl@microsoft.com, xcon@ietf.org Subject: AW: [XCON] Chicken and Egg - Can CPCP create a conference Date: Tue, 2 Dec 2003 16:03:23 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hisham, please see my comments below. > -----Urspr=FCngliche Nachricht----- > Von: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com]=20 > Gesendet: Dienstag, 2. Dezember 2003 15:26 > An: Brian.Rosen@marconi.com; rohan@cisco.com; pkyzivat@cisco.com > Cc: alan.johnston@mci.com; georg.mayer@nokia.com;=20 > oritl@microsoft.com; xcon@ietf.org > Betreff: RE: [XCON] Chicken and Egg - Can CPCP create a conference >=20 >=20 >=20 >=20 > > -----Original Message----- > > From: ext Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > Sent: 02.December.2003 15:16 > > To: Khartabil Hisham (NMP-MSW/Helsinki); rohan@cisco.com;=20 > > 'Paul Kyzivat' > > Cc: alan.johnston@mci.com; Mayer Georg (NMP-MSW/Helsinki); > > oritl@microsoft.com; xcon@ietf.org > > Subject: RE: [XCON] Chicken and Egg - Can CPCP create a conference > >=20 > >=20 > > Well it's clear that my view is different from you-all. > > Not an unfamiliar situation :( > > Let me keep trying a while, but I'll cave if I'm out here > > by myself for too long. > >=20 > > Several points to make. In my view: > > 1. "Instantiating" a conference is a concept that is getting=20 > > confusing. > > It's all in what you mean. I think it's when the mixer resources > > are actually allocated (as opposed to reserved). That starts when > > the first participant creates a dialog with the focus, and ends > > when the last dialog terminates. Getting a conference ID doesn't > > instantiate a conference, creating a dialog with it does. >=20 > Some chat type conferences can exist without any=20 > participants. Participants come and go as they please. Why is=20 > there a requirement that at least one participant is needed=20 > for the conference to ever exist? >=20 > >=20 > > You can have a policy on whether the conference ID expires when=20 > > the last dialog terminates. If it does, once the conference > > instantiation terminates, it cannot be re-instantiated. =20 > > If it doesn't, then it can be re-instantiated. An example of the=20 > > latter is a weekly sales meeting or a "meet-me" number. =20 > > An example of the latter could be a 4-way call created by a CONF=20 > > button. > >=20 > > 2. You can manipulate policy before you instantiate a conference. > > As soon as a conference ID is created, policy is available to be > > manipulated on it. =20 >=20 > Agreed on the part, but I don't think you need the conferece=20 > ID (that is the SIP URI for the conference) in order to=20 > manipulate the policy. CPCP can provide its own conference=20 > policy ID that is somehow mapped to a conference ID. This=20 > depends on the protocol chosen for CPCP. >=20 > >=20 > > 3. There is almost no difference between a pre-established=20 > > conference and an ad-hoc conference. Try and think of something=20 > > that matters: > > Time between creation of conference ID and instantiation? > > Nope; you can pre-establish a conference and use it=20 > > immediately, and there can be an arbitrary=20 > > delay between=20 > > requesting an ad-hoc conference and the first dialog=20 > > with it. And even if there was, who cares? >=20 > You are asking to redefine the whole concept of ah-hoc=20 > conferencing using SIP. The INVITE creates a conference, and=20 > creates a dialog. >=20 > > DialIn/DialOut=20 > > Nope - both can do both, or a mixture of either >=20 > How can you limit the dail-in list in an ad-hoc conference.=20 > Let me remind you that an ad-hoc conference does not have a policy. >=20 > For dial-out list, it is true that you can send REFER=20 > requests for the focus, but again, you cannot predefine that=20 > list. Also, you have to send a REFER to the focus for each=20 > potential participant, creating x number of dialogs, one for=20 > each REFER request. >=20 >=20 > > "Long running conference/chat" Nope; length of time of a > > conference/chat is not relevant, you could start one > > ad-hoc and leave it run for years. >=20 > again, with ad-hoc conferences, there is no policy to dictate=20 > this. I think I will stop commenting now until someone agrues=20 > that I am wrong and an ah-hoc conference also needs a policy=20 > (where my reply would be: why is it called ah-hoc then?). >=20 > Regards, > Hisham >=20 I think that it is too strong to state that there is no policy for = ad-hoc conferences. Surely there is no pre-configured policy for it, = but when it is created a set of parameters regarding membership and = media policy are (automatically) assigned to it. They may result from = the ad-hoc conference setup procedure and from the default = configuration of the conference server. In the course of the conference = these parameters may be eventually accessed via a CPCP.=20 Regards, Marcelo > > Therefore, I think you can't use CPCP for pre-established=20 > > conferences and SIP for ad-hoc conferences. Pick one. There is no = > > justification for two mechanisms to do the same thing. I have a=20 > > problem with policy creating a conference, and I think SIP=20 > > signalling is a more appropriate way to create a conference, but=20 > > I care more about having one and only one way to do it. > >=20 > > 4. My view of the conference factory was that you didn't get a=20 > > conference instantiation from it, you only got a conference ID. =20 > > Either end would immediately terminate the conference=20 > factory dialog,=20 > > either by an actual BYE or a REFER. If you wanted to immediately=20 > > instantiate the conference after getting the conferenceID, fine,=20 > > but you don't have to; you can just get the conference ID and > > instantiate later. Later could be milliseconds or, if policy=20 > > allowed, years. > >=20 > > 5. I agree that non-SIP signalling mechanisms could be standardized = > > to create conferences (H.323, iCal) if there is a SIP way=20 > to do it. =20 > > There wouldn't be any interoperability issues with that like there=20 > > would if both CPCP and SIP can do it. Even a single device=20 > that had,=20 > > say, both SIP and iCAL mechanisms would have no interoperability=20 > > issues with devices that were, say, SIP-only. On the other hand,=20 > > if you standardize on CPCP to do it, then you would not expect to=20 > > see any other standardized mechanism. > >=20 > > Brian > >=20 > > > -----Original Message----- > > > From: hisham.khartabil@nokia.com=20 > [mailto:hisham.khartabil@nokia.com] > > > Sent: Tuesday, December 02, 2003 5:07 AM > > > To: rohan@cisco.com; Brian.Rosen@marconi.com > > > Cc: alan.johnston@mci.com; oritl@microsoft.com; xcon@ietf.org > > > Subject: RE: [XCON] Chicken and Egg - Can CPCP create a = conference > > >=20 > > >=20 > > > Yes. After the conference server creates the focus on the=20 > > > scheduled time that was set using CPCP, the focus can use SIP=20 > > > INVTE or whatever protocol it desires to invite participants=20 > > > into the conference, or accpet participants to join a conference. > > >=20 > > > /Hisham > > >=20 > > > > -----Original Message----- > > > > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On=20 > > > Behalf Of ext > > > > Rohan Mahy > > > > Sent: 02.December.2003 00:58 > > > > To: Rosen, Brian > > > > Cc: 'Alan Johnston'; 'Orit Levin'; xcon@ietf.org > > > > Subject: Re: [XCON] Chicken and Egg - Can CPCP create a=20 > conference > > > >=20 > > > >=20 > > > >=20 > > > > On Monday, December 1, 2003, at 02:06 PM, Rosen, Brian wrote: > > > >=20 > > > > > Guilty of not reading documents carefully enough. > > > > > Most of the "duplicate" mechanisms were, on my reading, = merely > > > > > reflecting the observation that the focus is one end of the > > > > > dialog each participant has, and in SIP, either end can > > > > > initiate most operations, thus there is really no possibility > > > > > of incompatible implementations. Re-reading, I think we may > > > > > want to beef up the wording to make sure of it. > > > > > > > > > > The only case where I think CPCP actually "creates" a=20 > conference > > > > > is where there is a dial out with no-one dialing in before = the > > > > > dial out occurs. It should not be possible, I think,=20 > > to "create" > > > > > a conference before someone dials in or the focus dials out. > > > >=20 > > > > I can think of several reasons to create a conference before=20 > > > > there are=20 > > > > any participants/legs/users: > > > >=20 > > > > - A scheduled conference which has policies set by the=20 > > > creator before=20 > > > > the creator joins > > > > - A long running conference/group chat > > > > - A dial out conference > > > >=20 > > > > So clearly having a mechanism to create conferences using=20 > > > CPCP makes=20 > > > > sense. > > > >=20 > > > > Now if someone wants to create (possibly standardized)=20 > > > mechanisms in=20 > > > > other protocols to create an XCON conference, I see no=20 > > > > reason why this=20 > > > > is a problem. The SIP conferencing framework describes=20 > a role (a=20 > > > > conference factory) that has a URI you can INVITE that will=20 > > > create an=20 > > > > XCON conference. You could define a similar function for=20 > > > HTTP, XMPP,=20 > > > > iCal via SMTP, or H.323. > > > >=20 > > > > thanks, > > > > -rohan > > > >=20 > > > > > Similarly, a conference is destroyed when the last dialog is > > > > > terminated with a BYE, which may very well be by the focus, > > > > > but it is not terminated explicitly by CPCP. > > > > > > > > > > Looking at the other mechanisms: > > > > > Adding participants > > > > > Similar to creating conferences, you can dial=20 > > out or dial in. > > > > > I think we might want to observe in the text that focus > > > > > implementations MUST accept INVITES and REFERS,=20 > > as well as > > > > > CPCP requests to send INVITES. A UA could=20 > > implement either or > > > > > both mechanisms. I would observe that if a UA=20 > > wishes to promote > > > > > a two way to a conference, then it would have to use a=20 > > > > REFER, and > > > > > no other mechanism. I'd prefer that the SIP way be the=20 > > > > only way, > > > > > but the carriers seem to want to control who does the=20 > > > > dialing, so > > > > > there is no way the community would support REFER only. > > > > > Removing Participants > > > > > Again, mostly a "both ends of the dialog"=20 > > issue. BYE from focus > > > > > really is an acceptable way to boot someone. =20 > > 3rd party REFER > > > > > really is a duplicate, but prohibiting it seems=20 > > unlikely. In > > > > > most systems it wouldn't work from, say, a=20 > > moderator, because > > > > > of security issues (a random user can't=20 > > REFER/BYE you I hope). > > > > > Probably need to expand that wording to say=20 > > "third person > > > > > (another participant) departures..." I don't=20 > > want to imply > > > > > that the focus would use REFER. It would use BYE. > > > > > > > > > > I note that the text in this section about the focus=20 > > > > manipulating > > > > > other dialogs is misplaced, because it would do=20 > > the same thing > > > > > if the participant was removed by SIP or any=20 > > other means. > > > > > Obtaining Membership > > > > > I don't see why we need two mechanisms. If we keep=20 > > > > both, then we > > > > > should explicitly require a focus to implement=20 > > both. I really > > > > > don't care which one we keep. > > > > > > > > > > Adding and Removing Media > > > > > "Both ends of the dialog" issues. Again, a=20 > > focus probably can't > > > > > help but implement both, but it might be good=20 > > to say that > > > > > explicitly somewhere. > > > > > > > > > > Brian > > > > > > > > > > > > > > >> -----Original Message----- > > > > >> From: Alan Johnston [mailto:alan.johnston@mci.com] > > > > >> Sent: Monday, December 01, 2003 4:12 PM > > > > >> To: Rosen, Brian; 'Orit Levin'; xcon@ietf.org > > > > >> Subject: RE: [XCON] Chicken and Egg - Can CPCP create a=20 > > > conference > > > > >> > > > > >> > > > > >> At 03:36 PM 12/1/2003 -0500, Rosen, Brian wrote: > > > > >>> Orit > > > > >>> > > > > >>> Keeping XCON separate from SIP is useful so long as=20 > it doesn't > > > > >>> get in the way of common sense. To me, that would mean,=20 > > > > for example, > > > > >>> having a different name space for a conference ID,=20 > > requiring one > > > > >>> for CPCP and another for SIP. If a conference ID in=20 > > > CPCP is not a > > > > >>> uri, for which a SIP uri is an excellent, but not=20 > > > > limiting example, > > > > >>> I have a very large problem. > > > > >>> > > > > >>> I don't care if some day, someone invents a way to use=20 > > > > CPCP without > > > > >>> SIP, and I don't have any interest in making that difficult > > > > >> in any way. > > > > >>> However, it's not a driving function, and I don't=20 > > think there is > > > > >>> any reason to have more than one standardized way to create > > > > >> a conference. > > > > >>> An INVITE to a conference URI does it. A specific=20 > > > > implementation may > > > > >>> have some other, non standardized way. I want ONE=20 > > > > standardized way, > > > > >>> unless someone has a compelling reason why we need to=20 > > have two. > > > > >>> It's a broken record; when you have multiple ways to do the > > > > >> same thing, > > > > >>> you facilitate incompatible implementations. If there=20 > > > > are a million > > > > >>> ways, you will have a lot of incompatible systems. I have > > > > >> no interest > > > > >>> in fostering that kind of design. > > > > >> > > > > >> Brian, > > > > >> > > > > >> Please re-read the SIP Conferencing Framework document - > > > > >> practically every > > > > >> conference-related operation has both a SIP and a non-SIP > > > > >> mechanism to do so. > > > > >> > > > > >> Thanks, > > > > >> Alan > > > > >> sip:alan@sipstation.com > > > > >> > > > > >> > > > > >> > > > > >> > > > > >>> Brian > > > > >>> > > > > >>> > > > > >>> > > > > >>> > > > > >>>> -----Original Message----- > > > > >>>> From: Orit Levin [mailto:oritl@microsoft.com] > > > > >>>> Sent: Monday, December 01, 2003 3:02 PM > > > > >>>> To: Rosen, Brian; xcon@ietf.org > > > > >>>> Subject: RE: [XCON] Chicken and Egg - Can CPCP create a=20 > > > > conference > > > > >>>> > > > > >>>> > > > > >>>> Brian! > > > > >>>> I am actually surprised by this thread. > > > > >>>> > > > > >>>> In reality, a single conference instance can be > > > > >> potentially defined / > > > > >>>> requested by million ways. Moreover, the same conference > > > > >> instance can > > > > >>>> host participants joining by very different means and > > > > >> media. Moreover, > > > > >>>> the same conference can have more than a single unique > > > > >> identifier... > > > > >>>> > > > > >>>> SIP conferencing and XCON conferencing must be able to > > > > >> coexist in the > > > > >>>> system and share same conference instances but apart from > > > > >>>> that - each is > > > > >>>> a "complete system" on its own. (SIP point-to-point CC is > > > > >> a different > > > > >>>> issue - it is one of the tools available for XCON.) > > > > >>>> > > > > >>>> As a result, the discussion of the addressing scheme = should > > > > >>>> first apply > > > > >>>> to the SIPPING conferencing work. (In XCON we still need = to > > > > >>>> agree on the > > > > >>>> higher level architectural decomposition of the pieces > > > > >> that we managed > > > > >>>> to introduce.) > > > > >>>> > > > > >>>> In particular, draft-ietf-sipping-cc-conferencing-02.txt > > > > >> has different > > > > >>>> assumptions or, I should say, is less restrictive that=20 > > > > you propose > > > > >>>> below. BTW, it does define that "calling a Factory"=20 > > results in > > > > >>>> establishing a conference with its focus (either=20 > through the > > > > >>>> same dialog > > > > >>>> or by redirection to a focus - both are valid cases). If = we > > > > >>>> disagree on > > > > >>>> this, let's start this discussion in SIPPING ASAP. > > > > >>>> > > > > >>>> Orit. > > > > >>>> > > > > >>>> -----Original Message----- > > > > >>>> From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org] On > > > > >> Behalf Of > > > > >>>> Rosen, Brian > > > > >>>> Sent: Monday, December 01, 2003 10:26 AM > > > > >>>> To: 'xcon@ietf.org' > > > > >>>> Subject: [XCON] Chicken and Egg - Can CPCP create a=20 > > conference > > > > >>>> > > > > >>>> I'd like to re-open the requirement to create a > > > > >> conference with CPCP. > > > > >>>> Somehow, I missed that one. > > > > >>>> > > > > >>>> Generally, I think it's a bad idea to have two ways to do > > > > >>>> something, and > > > > >>>> we > > > > >>>> have another way to create a conference (conference > > > > >> factory uri). I'd > > > > >>>> like to eliminate one of them if possible. > > > > >>>> > > > > >>>> Beyond that, it seems to me that there is a chicken and = egg > > > > >>>> problem with > > > > >>>> CPCP. That is, how do you "start" sending CPCP = "commands", > > > > >>>> and to whom > > > > >>>> do you address them? This is an issue that=20 > > > intertwines with the > > > > >>>> signalling > > > > >>>> protocol (sip). In my mind, the conference uri gave you = an > > > > >>>> address (the > > > > >>>> host of the focus) and an identifier (the userpart of the > > > > >> uri). Now, > > > > >>>> in at least the first version of all of this, do we need > > > > >> to have some > > > > >>>> kind > > > > >>>> of discovery mechanism for the conference policy server? > > > > >> I think not, > > > > >>>> or at least I think you get it from the focus. I'd > > > > >> propose that it is > > > > >>>> precisely the host of the focus, but I'd be okay with a > > > > >> query to the > > > > >>>> focus > > > > >>>> that returned the address of the conference policy server. > > > > >>>> > > > > >>>> So, if I were choosing, I would not permit CPCP to create > > > > >> conferences. > > > > >>>> I would rely on the conference factory URI (as well as=20 > > > > out of band > > > > >>>> means). > > > > >>>> I would make the conference policy server the same=20 > > host as the > > > > >>>> conference > > > > >>>> uri, or at least make the focus return the address of > > > > >>>> conference policy > > > > >>>> server. > > > > >>>> If you need a conference uri to get the conference=20 > > > policy server > > > > >>>> address, > > > > >>>> then you can't use CPCP without a conference URI, and thus > > > > >>>> using CPCP to > > > > >>>> create/discover a conference URI wouldn't work. > > > > >>>> > > > > >>>> Brian > > > > >>>> > > > > >>>> _______________________________________________ > > > > >>>> XCON mailing list > > > > >>>> XCON@ietf.org > > > > >>>> https://www1.ietf.org/mailman/listinfo/xcon > > > > >>>> > > > > >>>> > > > > >>>> > > > > >>>> _______________________________________________ > > > > >>>> XCON mailing list > > > > >>>> XCON@ietf.org > > > > >>>> https://www1.ietf.org/mailman/listinfo/xcon > > > > >>>> > > > > >>> > > > > >>> _______________________________________________ > > > > >>> XCON mailing list > > > > >>> XCON@ietf.org > > > > >>> https://www1.ietf.org/mailman/listinfo/xcon > > > > >> > > > > > > > > > > _______________________________________________ > > > > > XCON mailing list > > > > > XCON@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/xcon > > > >=20 > > > >=20 > > > > _______________________________________________ > > > > XCON mailing list > > > > XCON@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/xcon > > > >=20 > > >=20 > >=20 >=20 > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon >=20 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Tue Dec 2 10:27:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21739 for ; Tue, 2 Dec 2003 10:27:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARCQb-0003m6-4T for xcon-archive@odin.ietf.org; Tue, 02 Dec 2003 10:27:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB2FR5bV014510 for xcon-archive@odin.ietf.org; Tue, 2 Dec 2003 10:27:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARCQa-0003lx-V2 for xcon-web-archive@optimus.ietf.org; Tue, 02 Dec 2003 10:27:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21731 for ; Tue, 2 Dec 2003 10:26:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARCQY-0002HB-00 for xcon-web-archive@ietf.org; Tue, 02 Dec 2003 10:27:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARCQY-0002H8-00 for xcon-web-archive@ietf.org; Tue, 02 Dec 2003 10:27:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARCQX-0003lY-Qx; Tue, 02 Dec 2003 10:27:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARCQD-0003kr-FU for xcon@optimus.ietf.org; Tue, 02 Dec 2003 10:26:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21709 for ; Tue, 2 Dec 2003 10:26:26 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARCQA-0002Ge-00 for xcon@ietf.org; Tue, 02 Dec 2003 10:26:38 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1ARCQ9-0002GR-00 for xcon@ietf.org; Tue, 02 Dec 2003 10:26:38 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hB2FQZ708117 for ; Tue, 2 Dec 2003 17:26:35 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 2 Dec 2003 17:26:35 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 2 Dec 2003 17:26:35 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] Chicken and Egg - Can CPCP create a conference Date: Tue, 2 Dec 2003 17:26:35 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB70118B117@esebe019.ntc.nokia.com> Thread-Topic: [XCON] Chicken and Egg - Can CPCP create a conference Thread-Index: AcO44+xqUe3mWMlCQPW65y57DCmlCQAANSjw To: , , Cc: , , , X-OriginalArrivalTime: 02 Dec 2003 15:26:35.0850 (UTC) FILETIME=[AC42FAA0:01C3B8E8] Content-Transfer-Encoding: quoted-printable Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ext Rosen, Brian [mailto:Brian.Rosen@marconi.com] > Sent: 02.December.2003 16:52 > To: Khartabil Hisham (NMP-MSW/Helsinki); rohan@cisco.com; > pkyzivat@cisco.com > Cc: alan.johnston@mci.com; Mayer Georg (NMP-MSW/Helsinki); > oritl@microsoft.com; xcon@ietf.org > Subject: RE: [XCON] Chicken and Egg - Can CPCP create a conference >=20 >=20 > So, two fundamental differences: > 1. You think CPCP has some separate namespace independent of a URI=20 > (of which a SIP uri is a good, but not exclusive example). =20 > I am opposed to that. A conferenceID is a uri. I can imagine a=20 > specific instance of a conference service that could have multiple=20 > IDs for the same conference, for example, an H.323 URI and a SIP URI=20 > that resolves to the same conference. That's fine, and it's=20 > not subject=20 > to standardization. However, I think that the ID you use with the=20 > focus is always the ID you use with CPCP for the same conference. I don't understand why the ID for the conference needs to be the same as = the ID for the conference policy.=20 If you look at XCAP list usage for example, you will see that the = list-URI used when sending SIP SUBSCRIBE requests to the list is not the = same as the URI used to manipulate the list using XCAP. They certainly = need to be linked, but not necessarily the same. Depending on the protocol we chose, a SIP URI can or cannot be used to = identify a conference policy. >=20 > 2. You think ad-hoc conferences don't have policy. I am=20 > fundamentally=20 > opposed to that. Ad-hoc conferences should have all of the=20 > functionality of a pre-established conference and I can't imagine any=20 > reason why we can't provide that. If we replicate everything that a scheduled conference can have to = ad-hoc conferences, then we don't need scheduled conferences at all. = Perhaps we need to define the scope of an ad-hoc conference. To me an = ad-hoc is just that; a conference created instantaneously for discussing = an urgent matter or whatever. You REFER other participants and it = terminated as soon as the last participant leaves. There are no start = and stop times, there are no dial-out and dial-in lists configured, = there is no general conference info, and there are no media policies. >=20 > We also have a nit, at least I think it's a nit, about Instantiation. > I'm not sure there is any real difference between a re-usable=20 > conference ID and an instantiated conference that has no=20 > participants. =20 > Since I define instantiated as allocated mixer resources, if I'm not=20 > using resources I don't have the conference instantiated. =20 I agree about the definition of "instantiated". But if there are no = current participants in a conference, and a server releases resources = and keeps the conference ID, it needs to guarantee what resources will = be available as soon as a participant enters. This might be not = releasing the resources. Perhaps all this is an implementation issue.=20 > If you define instantiation differently, then you could. =20 > It would be good, I think, to have a common agreement on what=20 > instantiation means, because we use it in the documents, but I'm=20 > not sure we disagree on what can happen. We both agree you can=20 > manipulate policy, and we both agree participants can come and go. =20 > I guess I would ask you if you have some notion of a re-usable=20 > conference ID that is somehow different from an instantiated=20 > conference with no participants. A conference ID can exist even if a conference is not instantiated. But = what I was trying to say is that a conference can be instantiated = without any participants, unless as I said, the resources can be = guaranteed to be reallocated. Regards, Hisham >=20 > Brian >=20 >=20 > > -----Original Message----- > > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > > Sent: Tuesday, December 02, 2003 9:26 AM > > To: Brian.Rosen@marconi.com; rohan@cisco.com; pkyzivat@cisco.com > > Cc: alan.johnston@mci.com; georg.mayer@nokia.com;=20 > oritl@microsoft.com; > > xcon@ietf.org > > Subject: RE: [XCON] Chicken and Egg - Can CPCP create a conference > >=20 > >=20 > >=20 > >=20 > > > -----Original Message----- > > > From: ext Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > > Sent: 02.December.2003 15:16 > > > To: Khartabil Hisham (NMP-MSW/Helsinki); rohan@cisco.com;=20 > > > 'Paul Kyzivat' > > > Cc: alan.johnston@mci.com; Mayer Georg (NMP-MSW/Helsinki); > > > oritl@microsoft.com; xcon@ietf.org > > > Subject: RE: [XCON] Chicken and Egg - Can CPCP create a conference > > >=20 > > >=20 > > > Well it's clear that my view is different from you-all. > > > Not an unfamiliar situation :( > > > Let me keep trying a while, but I'll cave if I'm out here > > > by myself for too long. > > >=20 > > > Several points to make. In my view: > > > 1. "Instantiating" a conference is a concept that is getting=20 > > > confusing. > > > It's all in what you mean. I think it's when the mixer resources > > > are actually allocated (as opposed to reserved). That starts when > > > the first participant creates a dialog with the focus, and ends > > > when the last dialog terminates. Getting a conference ID doesn't > > > instantiate a conference, creating a dialog with it does. > >=20 > > Some chat type conferences can exist without any=20 > > participants. Participants come and go as they please. Why is=20 > > there a requirement that at least one participant is needed=20 > > for the conference to ever exist? > >=20 > > >=20 > > > You can have a policy on whether the conference ID expires when=20 > > > the last dialog terminates. If it does, once the conference > > > instantiation terminates, it cannot be re-instantiated. =20 > > > If it doesn't, then it can be re-instantiated. An example of the=20 > > > latter is a weekly sales meeting or a "meet-me" number. =20 > > > An example of the latter could be a 4-way call created by a CONF=20 > > > button. > > >=20 > > > 2. You can manipulate policy before you instantiate a conference. > > > As soon as a conference ID is created, policy is available to be > > > manipulated on it. =20 > >=20 > > Agreed on the part, but I don't think you need the conferece=20 > > ID (that is the SIP URI for the conference) in order to=20 > > manipulate the policy. CPCP can provide its own conference=20 > > policy ID that is somehow mapped to a conference ID. This=20 > > depends on the protocol chosen for CPCP. > >=20 > > >=20 > > > 3. There is almost no difference between a pre-established=20 > > > conference and an ad-hoc conference. Try and think of something=20 > > > that matters: > > > Time between creation of conference ID and instantiation? > > > Nope; you can pre-establish a conference and use it=20 > > > immediately, and there can be an arbitrary=20 > > > delay between=20 > > > requesting an ad-hoc conference and the first dialog=20 > > > with it. And even if there was, who cares? > >=20 > > You are asking to redefine the whole concept of ah-hoc=20 > > conferencing using SIP. The INVITE creates a conference, and=20 > > creates a dialog. > >=20 > > > DialIn/DialOut=20 > > > Nope - both can do both, or a mixture of either > >=20 > > How can you limit the dail-in list in an ad-hoc conference.=20 > > Let me remind you that an ad-hoc conference does not have a policy. > >=20 > > For dial-out list, it is true that you can send REFER=20 > > requests for the focus, but again, you cannot predefine that=20 > > list. Also, you have to send a REFER to the focus for each=20 > > potential participant, creating x number of dialogs, one for=20 > > each REFER request. > >=20 > >=20 > > > "Long running conference/chat" Nope; length of time of a > > > conference/chat is not relevant, you could start one=20 > > > ad-hoc and leave it run for years. > >=20 > > again, with ad-hoc conferences, there is no policy to dictate=20 > > this. I think I will stop commenting now until someone agrues=20 > > that I am wrong and an ah-hoc conference also needs a policy=20 > > (where my reply would be: why is it called ah-hoc then?). > >=20 > > Regards, > > Hisham > >=20 > > > Therefore, I think you can't use CPCP for pre-established=20 > > > conferences and SIP for ad-hoc conferences. Pick one. =20 > There is no=20 > > > justification for two mechanisms to do the same thing. I have a=20 > > > problem with policy creating a conference, and I think SIP=20 > > > signalling is a more appropriate way to create a conference, but=20 > > > I care more about having one and only one way to do it. > > >=20 > > > 4. My view of the conference factory was that you didn't get a=20 > > > conference instantiation from it, you only got a conference ID. =20 > > > Either end would immediately terminate the conference=20 > > factory dialog,=20 > > > either by an actual BYE or a REFER. If you wanted to immediately=20 > > > instantiate the conference after getting the conferenceID, fine,=20 > > > but you don't have to; you can just get the conference ID and > > > instantiate later. Later could be milliseconds or, if policy=20 > > > allowed, years. > > >=20 > > > 5. I agree that non-SIP signalling mechanisms could be=20 > standardized=20 > > > to create conferences (H.323, iCal) if there is a SIP way=20 > > to do it. =20 > > > There wouldn't be any interoperability issues with that=20 > like there=20 > > > would if both CPCP and SIP can do it. Even a single device=20 > > that had,=20 > > > say, both SIP and iCAL mechanisms would have no interoperability=20 > > > issues with devices that were, say, SIP-only. On the other hand,=20 > > > if you standardize on CPCP to do it, then you would not expect to=20 > > > see any other standardized mechanism. > > >=20 > > > Brian > > >=20 >=20 > >=20 >=20 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Tue Dec 2 10:34:18 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22235 for ; Tue, 2 Dec 2003 10:34:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARCXL-00040e-0M for xcon-archive@odin.ietf.org; Tue, 02 Dec 2003 10:34:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB2FY224015406 for xcon-archive@odin.ietf.org; Tue, 2 Dec 2003 10:34:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARCXK-000404-J7 for xcon-web-archive@optimus.ietf.org; Tue, 02 Dec 2003 10:34:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22226 for ; Tue, 2 Dec 2003 10:33:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARCXI-0002Rh-00 for xcon-web-archive@ietf.org; Tue, 02 Dec 2003 10:34:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARCXH-0002Re-00 for xcon-web-archive@ietf.org; Tue, 02 Dec 2003 10:33:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARCXJ-0003zq-LR; Tue, 02 Dec 2003 10:34:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARCWd-0003zN-23 for xcon@optimus.ietf.org; Tue, 02 Dec 2003 10:33:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22149 for ; Tue, 2 Dec 2003 10:33:04 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARCWa-0002QV-00 for xcon@ietf.org; Tue, 02 Dec 2003 10:33:16 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1ARCWZ-0002QS-00 for xcon@ietf.org; Tue, 02 Dec 2003 10:33:16 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hB2FXE717713 for ; Tue, 2 Dec 2003 17:33:14 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 2 Dec 2003 17:33:14 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 2 Dec 2003 17:33:13 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 2 Dec 2003 17:33:13 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] Chicken and Egg - Can CPCP create a conference Date: Tue, 2 Dec 2003 17:33:13 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB70118B118@esebe019.ntc.nokia.com> Thread-Topic: [XCON] Chicken and Egg - Can CPCP create a conference Thread-Index: AcO45XkZzn1wtDYBT7ubY6gBaJCFUQAA3boA To: , , , Cc: , , , X-OriginalArrivalTime: 02 Dec 2003 15:33:13.0388 (UTC) FILETIME=[993676C0:01C3B8E9] Content-Transfer-Encoding: quoted-printable Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ext Heil Franca Marcelo [mailto:marcelo.heil_franca@siemens.com] > Sent: 02.December.2003 17:03 > To: Khartabil Hisham (NMP-MSW/Helsinki); Brian.Rosen@marconi.com; > rohan@cisco.com; pkyzivat@cisco.com > Cc: alan.johnston@mci.com; Mayer Georg (NMP-MSW/Helsinki); > oritl@microsoft.com; xcon@ietf.org > Subject: AW: [XCON] Chicken and Egg - Can CPCP create a conference >=20 > >=20 > I think that it is too strong to state that there is no=20 > policy for ad-hoc conferences. Surely there is no=20 > pre-configured policy for it, but when it is created a set of=20 > parameters regarding membership and media policy are=20 > (automatically) assigned to it. They may result from the=20 > ad-hoc conference setup procedure and from the default=20 > configuration of the conference server. In the course of the=20 > conference these parameters may be eventually accessed via a CPCP.=20 If you want this, then we go back to Brian's original point of why do we = want 2 ways of achieving the same thing? Instead of creating the conference policy then instantiating the = conference, you want to instantiate the conference then create its = policy. We need one solution for quick conferences created on the fly, and ones = that are more controlled and scheduled with policies, etc. /Hisham >=20 > Regards, > Marcelo >=20 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Tue Dec 2 10:40:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22456 for ; Tue, 2 Dec 2003 10:40:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARCdC-0004PI-CI for xcon-archive@odin.ietf.org; Tue, 02 Dec 2003 10:40:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB2Fe6Pn016934 for xcon-archive@odin.ietf.org; Tue, 2 Dec 2003 10:40:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARCdA-0004Oy-RF for xcon-web-archive@optimus.ietf.org; Tue, 02 Dec 2003 10:40:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22448 for ; Tue, 2 Dec 2003 10:39:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARCd8-0002Uj-00 for xcon-web-archive@ietf.org; Tue, 02 Dec 2003 10:40:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARCd8-0002Ug-00 for xcon-web-archive@ietf.org; Tue, 02 Dec 2003 10:40:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARCd9-0004OR-Id; Tue, 02 Dec 2003 10:40:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARCcD-0004NE-21 for xcon@optimus.ietf.org; Tue, 02 Dec 2003 10:39:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22430 for ; Tue, 2 Dec 2003 10:38:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARCcA-0002UA-00 for xcon@ietf.org; Tue, 02 Dec 2003 10:39:02 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1ARCcA-0002Ts-00 for xcon@ietf.org; Tue, 02 Dec 2003 10:39:02 -0500 Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hB2FcSDM027554; Tue, 2 Dec 2003 10:38:29 -0500 (EST) Received: from mhammer-w2k03.cisco.com (dhcp-hrn-64-100-229-166.cisco.com [64.100.229.166]) by fruitpie.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AVI60441; Tue, 2 Dec 2003 07:38:27 -0800 (PST) Message-Id: <4.3.2.7.2.20031202103122.00b3a580@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 02 Dec 2003 10:38:26 -0500 To: From: Michael Hammer Subject: RE: [XCON] CPCP - making something simple that works Cc: , , In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB70179746C@esebe019.ntc.noki a.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , At 12:11 PM 12/2/2003 +0200, hisham.khartabil@nokia.com wrote: > > -----Original Message----- > > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On Behalf Of ext > > Michael Hammer > > Sent: 01.December.2003 17:58 > > To: Henning Schulzrinne > > Cc: Khartabil Hisham (NMP-MSW/Helsinki); Isomaki Markus > > (NRC/Helsinki); > > xcon@ietf.org > > Subject: Re: [XCON] CPCP - making something simple that works > > > > > > Henning, > > > > I can name two cases where explicitly expelling someone is useful: > > > > 1) An enterprise conference is discussing company sensitive > > material of > > economic value and someone manages to join and refused to > > identify themselves, On thinking further, I would hope that the authentication and authorization capabilities (presumable a white list) would prevent this problem in the first place. > > > > 2) Someone on the conference puts it on hold improperly and > > plays music on > > hold to the conference. I agree that having the ability to mute that one offending party is better; much kinder than my original suggestion. But, part of me wants to provide some negative feedback to the offender, so they have to work to get back in, and thus less likely to offend again. :) > > > > Both of these happen frequently enough that an ability to eject the > > offending user is desirable and more preferable to wasting > > time getting > > everyone to move on to another conference. It shouldn't be > > necessary to > > get hold of a moderator to do the expelling. > >Of course you need the moderator to do the expelling, otherwise this >unwanted participant can expel other participants. Your moderator being someone participating in the conference and the one I was referring to being an operator somewhere that has to be fetched, as is sometimes the case today, are two different things. A user-friendly well-designed self-service interface would be very desirable. Mike >/Hisham > > > > Mike > > > > > > At 02:27 PM 11/30/2003 -0500, Henning Schulzrinne wrote: > > > > >>I believe timing is important and is one major advantage of > > CPCP over > > >>ad-hoc conferences. > > > > > >Note, however, that this can easily be done by an external > > application > > >that uses a normal calendaring mechanism (such as the iCal > > extensions for > > >events) and then generates CPCP requests. Having a very > > simple single > > >start/end-time (no repeats) is sufficient for that and does not add > > >significant complexity. > > > > > >>What about security of the conference? is that a priority? How > > >>desides on the level of security and what protocol to use? who sets > > >>the password for the conference? I am ok with having a default > > >>authentication mechanism like digest for joining a conference. > > > > > >I would find it peculiar if joining a conference required > > anything other > > >than a standard SIP client, for example. > > > > > >>There is also the issue of expelling users. What is the opinion on > > >>that? Is it important? > > > > > >I have never seen that be used in real conferences, even > > where the feature > > >was available. If this is a rather rare event, it is easier > > to create a > > >new conference without the offending user and have everyone > > minus one move > > >to the new conference. The much more common case is the > > executive session > > >(or the jury session, e.g., for a thesis defense), which seems most > > >readily modeled as two sessions with distinct participants, > > set up from > > >the beginning. > > > > > >The problem with expelling is that this adds the risk of accidental > > >invocation and probably does not deal with the full range of > > Robert's > > >Rules stipulations and procedures. > > > > > >I think a natural threshold for initial inclusion is common usage in > > >today's conferencing systems. > > > > > >Henning > > > > > >_______________________________________________ > > >XCON mailing list > > >XCON@ietf.org > > >https://www1.ietf.org/mailman/listinfo/xcon > > > > > > _______________________________________________ > > XCON mailing list > > XCON@ietf.org > > https://www1.ietf.org/mailman/listinfo/xcon > > _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Tue Dec 2 10:44:18 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22563 for ; Tue, 2 Dec 2003 10:44:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARCh0-0004ZK-1y for xcon-archive@odin.ietf.org; Tue, 02 Dec 2003 10:44:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB2Fi2DN017555 for xcon-archive@odin.ietf.org; Tue, 2 Dec 2003 10:44:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARCgz-0004Z4-Sl for xcon-web-archive@optimus.ietf.org; Tue, 02 Dec 2003 10:44:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22555 for ; Tue, 2 Dec 2003 10:43:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARCgx-0002Xa-00 for xcon-web-archive@ietf.org; Tue, 02 Dec 2003 10:43:59 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARCgx-0002XX-00 for xcon-web-archive@ietf.org; Tue, 02 Dec 2003 10:43:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARCgy-0004Xt-Iz; Tue, 02 Dec 2003 10:44:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARCgK-0004WX-87 for xcon@optimus.ietf.org; Tue, 02 Dec 2003 10:43:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22531 for ; Tue, 2 Dec 2003 10:43:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARCgH-0002Wt-00 for xcon@ietf.org; Tue, 02 Dec 2003 10:43:17 -0500 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 1ARCgH-0002Vc-00 for xcon@ietf.org; Tue, 02 Dec 2003 10:43:17 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA07485; Tue, 2 Dec 2003 10:42:43 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA15810; Tue, 2 Dec 2003 10:42:43 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Tue, 2 Dec 2003 10:42:43 -0500 Message-ID: <313680C9A886D511A06000204840E1CF070B6151@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'hisham.khartabil@nokia.com'" , rohan@cisco.com, pkyzivat@cisco.com Cc: alan.johnston@mci.com, georg.mayer@nokia.com, oritl@microsoft.com, xcon@ietf.org Subject: RE: [XCON] Chicken and Egg - Can CPCP create a conference Date: Tue, 2 Dec 2003 10:42:42 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , > > So, two fundamental differences: > > 1. You think CPCP has some separate namespace independent of a URI > > (of which a SIP uri is a good, but not exclusive example). > > I am opposed to that. A conferenceID is a uri. I can imagine a > > specific instance of a conference service that could have multiple > > IDs for the same conference, for example, an H.323 URI and > a SIP URI > > that resolves to the same conference. That's fine, and it's > > not subject > > to standardization. However, I think that the ID you use with the > > focus is always the ID you use with CPCP for the same conference. > > I don't understand why the ID for the conference needs to be > the same as the ID for the conference policy. > > If you look at XCAP list usage for example, you will see that > the list-URI used when sending SIP SUBSCRIBE requests to the > list is not the same as the URI used to manipulate the list > using XCAP. They certainly need to be linked, but not > necessarily the same. > > Depending on the protocol we chose, a SIP URI can or cannot > be used to identify a conference policy. I think we CAN always have the same ID. I think there is a lot of value in one ID I don't think there is any problem in having one ID So, I think there should be one. If there is a good reason, we can burden the conference policy server with keeping the relationship, but unless there is a good reason, history suggests that one namespace is better than two with linkage. > > > > > 2. You think ad-hoc conferences don't have policy. I am > > fundamentally > > opposed to that. Ad-hoc conferences should have all of the > > functionality of a pre-established conference and I can't > imagine any > > reason why we can't provide that. > > If we replicate everything that a scheduled conference can > have to ad-hoc conferences, then we don't need scheduled > conferences at all. Perhaps we need to define the scope of an > ad-hoc conference. To me an ad-hoc is just that; a conference > created instantaneously for discussing an urgent matter or > whatever. You REFER other participants and it terminated as > soon as the last participant leaves. There are no start and > stop times, there are no dial-out and dial-in lists > configured, there is no general conference info, and there > are no media policies. Well, basically, I agree; we don't need to distinguish between an ad-hoc conference and a pre-established one. I think we definitely need policy for ad-hoc conferences (as you define them), and don't see any reason we need to differentiate. Why can't someone ask the conference policy server to dial out to add someone to an ad-hoc conference? It's crystal clear that you need media policy, otherwise, you can't control mixing at all, and we already do that (for something that clearly meets you definition of an ad-hoc conference). Shouldn't I be able, as the conference creator, to control who is in my conference, or can any participant add any other participant? That's up to me, isn't it? So, I think there is very much a requirement for conference policy for ad-hoc, and there is no need, nor reason to have anything special for ad-hoc, or for pre-established conferences. > > > > > We also have a nit, at least I think it's a nit, about > Instantiation. > > I'm not sure there is any real difference between a re-usable > > conference ID and an instantiated conference that has no > > participants. > > Since I define instantiated as allocated mixer resources, > if I'm not > > using resources I don't have the conference instantiated. > > I agree about the definition of "instantiated". But if there > are no current participants in a conference, and a server > releases resources and keeps the conference ID, it needs to > guarantee what resources will be available as soon as a > participant enters. This might be not releasing the > resources. Perhaps all this is an implementation issue. If you schedule a conference for a week from now, you need to "guarantee" that resources will be available in a week for that conference. That is resource reservation. A re-usable conference which has no time schedule would have to have resources reserved, just like a "meet-me" number. Of course, like a "meet-me", a given implementation may use some statistics to guide what kind of actual reservation mechanism it employs. > > > If you define instantiation differently, then you could. > > It would be good, I think, to have a common agreement on what > > instantiation means, because we use it in the documents, but I'm > > not sure we disagree on what can happen. We both agree you can > > manipulate policy, and we both agree participants can come and go. > > I guess I would ask you if you have some notion of a re-usable > > conference ID that is somehow different from an instantiated > > conference with no participants. > > A conference ID can exist even if a conference is not > instantiated. But what I was trying to say is that a > conference can be instantiated without any participants, > unless as I said, the resources can be guaranteed to be reallocated. _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Tue Dec 2 10:57:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23080 for ; Tue, 2 Dec 2003 10:57:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARCtc-000579-1E for xcon-archive@odin.ietf.org; Tue, 02 Dec 2003 10:57:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB2Fv3TC019653 for xcon-archive@odin.ietf.org; Tue, 2 Dec 2003 10:57:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARCtb-00056Y-0s for xcon-web-archive@optimus.ietf.org; Tue, 02 Dec 2003 10:57:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23071 for ; Tue, 2 Dec 2003 10:56:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARCtY-0002jm-00 for xcon-web-archive@ietf.org; Tue, 02 Dec 2003 10:57:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARCtX-0002jc-00 for xcon-web-archive@ietf.org; Tue, 02 Dec 2003 10:56:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARCtZ-00055j-9y; Tue, 02 Dec 2003 10:57:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARCtD-00054v-6W for xcon@optimus.ietf.org; Tue, 02 Dec 2003 10:56:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23051 for ; Tue, 2 Dec 2003 10:56:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARCtA-0002jC-00 for xcon@ietf.org; Tue, 02 Dec 2003 10:56:36 -0500 Received: from dgesmtp01.wcom.com ([199.249.16.16]) by ietf-mx with esmtp (Exim 4.12) id 1ARCtA-0002il-00 for xcon@ietf.org; Tue, 02 Dec 2003 10:56:36 -0500 Received: from pmismtp01.wcomnet.com ([166.38.62.36]) by firewall.wcom.com (Iplanet MTA 5.2) with ESMTP id <0HP9006IXYQIXO@firewall.wcom.com> for xcon@ietf.org; Tue, 02 Dec 2003 15:51:55 +0000 (GMT) Received: from pmismtp01.wcomnet.com by pmismtp01.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0HP900C01YQIJP@pmismtp01.wcomnet.com>; Tue, 02 Dec 2003 15:51:54 +0000 (GMT) Received: from xs578v3521.mci.com ([166.50.97.237]) by pmismtp01.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0HP900AP9YQFLK@pmismtp01.wcomnet.com>; Tue, 02 Dec 2003 15:51:54 +0000 (GMT) Date: Tue, 02 Dec 2003 09:51:50 -0600 From: Alan Johnston Subject: RE: [XCON] Chicken and Egg - Can CPCP create a conference In-reply-to: <2038BCC78B1AD641891A0D1AE133DBB70118B117@esebe019.ntc.noki a.com> X-Sender: Alan.Johnston@pop.mcit.com To: hisham.khartabil@nokia.com, Brian.Rosen@marconi.com, rohan@cisco.com, pkyzivat@cisco.com Cc: georg.mayer@nokia.com, oritl@microsoft.com, xcon@ietf.org Message-id: <5.2.1.1.0.20031202094347.02a5d008@pop.mcit.com> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Content-type: text/plain; charset=us-ascii; format=flowed Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , At 05:26 PM 12/2/2003 +0200, hisham.khartabil@nokia.com wrote: > > -----Original Message----- > > From: ext Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > Sent: 02.December.2003 16:52 > > To: Khartabil Hisham (NMP-MSW/Helsinki); rohan@cisco.com; > > pkyzivat@cisco.com > > Cc: alan.johnston@mci.com; Mayer Georg (NMP-MSW/Helsinki); > > oritl@microsoft.com; xcon@ietf.org > > Subject: RE: [XCON] Chicken and Egg - Can CPCP create a conference > > > > > > So, two fundamental differences: > > 1. You think CPCP has some separate namespace independent of a URI > > (of which a SIP uri is a good, but not exclusive example). > > I am opposed to that. A conferenceID is a uri. I can imagine a > > specific instance of a conference service that could have multiple > > IDs for the same conference, for example, an H.323 URI and a SIP URI > > that resolves to the same conference. That's fine, and it's > > not subject > > to standardization. However, I think that the ID you use with the > > focus is always the ID you use with CPCP for the same conference. > >I don't understand why the ID for the conference needs to be the same as >the ID for the conference policy. I agree with Brian here. The conference identifier is the URI. It is the means by which a participant joins the conference and depends on the signaling protocol (SIP, H.323, PSTN, etc.). It can't just be some random string. This is a fundamental idea in the framework. >If you look at XCAP list usage for example, you will see that the list-URI >used when sending SIP SUBSCRIBE requests to the list is not the same as >the URI used to manipulate the list using XCAP. They certainly need to be >linked, but not necessarily the same. I don't understand what you are saying. The policy URI and the conference URI can not be the same since they are different protocols, right? >Depending on the protocol we chose, a SIP URI can or cannot be used to >identify a conference policy. Knowing only the conference URI, it must be possible to determine the conference policy URI. > > > > 2. You think ad-hoc conferences don't have policy. I am > > fundamentally > > opposed to that. Ad-hoc conferences should have all of the > > functionality of a pre-established conference and I can't imagine any > > reason why we can't provide that. > >If we replicate everything that a scheduled conference can have to ad-hoc >conferences, then we don't need scheduled conferences at all. Perhaps we >need to define the scope of an ad-hoc conference. To me an ad-hoc is just >that; a conference created instantaneously for discussing an urgent matter >or whatever. You REFER other participants and it terminated as soon as the >last participant leaves. There are no start and stop times, there are no >dial-out and dial-in lists configured, there is no general conference >info, and there are no media policies. I agree 100% with Brian. An ad-hoc conference does have policy, but it is a default (non-unique) policy. The creator of the conference factory URI sets that policy. It is possible for this policy to be manipulated once the conference has begun, but again this is up to the application. There is no such thing as an "ad-hoc conference" or a "scheduled conference" - however,there are "ad-hoc methods" of joining or being added to a conference, and scheduled means. When joining a pre-established, the conference URI is typically sent out-of-band, often in advance, to participants using say email or IM. When a participant is added using ad-hoc means, they often will not know (see) the conference URI - they will just be added in via a REFER or transfer. Trying to come up with a strict definition for one vs. the other is very difficult and probably not all that productive. I would encourage everyone to carefully read the SIPPING Conference Framework document - it details many of these issues. Thanks, Alan Johnston MCI sip:alan@sipstation.com > > > > We also have a nit, at least I think it's a nit, about Instantiation. > > I'm not sure there is any real difference between a re-usable > > conference ID and an instantiated conference that has no > > participants. > > Since I define instantiated as allocated mixer resources, if I'm not > > using resources I don't have the conference instantiated. > >I agree about the definition of "instantiated". But if there are no >current participants in a conference, and a server releases resources and >keeps the conference ID, it needs to guarantee what resources will be >available as soon as a participant enters. This might be not releasing the >resources. Perhaps all this is an implementation issue. > > > If you define instantiation differently, then you could. > > It would be good, I think, to have a common agreement on what > > instantiation means, because we use it in the documents, but I'm > > not sure we disagree on what can happen. We both agree you can > > manipulate policy, and we both agree participants can come and go. > > I guess I would ask you if you have some notion of a re-usable > > conference ID that is somehow different from an instantiated > > conference with no participants. > >A conference ID can exist even if a conference is not instantiated. But >what I was trying to say is that a conference can be instantiated without >any participants, unless as I said, the resources can be guaranteed to be >reallocated. > >Regards, >Hisham > > > > Brian > > > > > > > -----Original Message----- > > > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > > > Sent: Tuesday, December 02, 2003 9:26 AM > > > To: Brian.Rosen@marconi.com; rohan@cisco.com; pkyzivat@cisco.com > > > Cc: alan.johnston@mci.com; georg.mayer@nokia.com; > > oritl@microsoft.com; > > > xcon@ietf.org > > > Subject: RE: [XCON] Chicken and Egg - Can CPCP create a conference > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: ext Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > > > Sent: 02.December.2003 15:16 > > > > To: Khartabil Hisham (NMP-MSW/Helsinki); rohan@cisco.com; > > > > 'Paul Kyzivat' > > > > Cc: alan.johnston@mci.com; Mayer Georg (NMP-MSW/Helsinki); > > > > oritl@microsoft.com; xcon@ietf.org > > > > Subject: RE: [XCON] Chicken and Egg - Can CPCP create a conference > > > > > > > > > > > > Well it's clear that my view is different from you-all. > > > > Not an unfamiliar situation :( > > > > Let me keep trying a while, but I'll cave if I'm out here > > > > by myself for too long. > > > > > > > > Several points to make. In my view: > > > > 1. "Instantiating" a conference is a concept that is getting > > > > confusing. > > > > It's all in what you mean. I think it's when the mixer resources > > > > are actually allocated (as opposed to reserved). That starts when > > > > the first participant creates a dialog with the focus, and ends > > > > when the last dialog terminates. Getting a conference ID doesn't > > > > instantiate a conference, creating a dialog with it does. > > > > > > Some chat type conferences can exist without any > > > participants. Participants come and go as they please. Why is > > > there a requirement that at least one participant is needed > > > for the conference to ever exist? > > > > > > > > > > > You can have a policy on whether the conference ID expires when > > > > the last dialog terminates. If it does, once the conference > > > > instantiation terminates, it cannot be re-instantiated. > > > > If it doesn't, then it can be re-instantiated. An example of the > > > > latter is a weekly sales meeting or a "meet-me" number. > > > > An example of the latter could be a 4-way call created by a CONF > > > > button. > > > > > > > > 2. You can manipulate policy before you instantiate a conference. > > > > As soon as a conference ID is created, policy is available to be > > > > manipulated on it. > > > > > > Agreed on the part, but I don't think you need the conferece > > > ID (that is the SIP URI for the conference) in order to > > > manipulate the policy. CPCP can provide its own conference > > > policy ID that is somehow mapped to a conference ID. This > > > depends on the protocol chosen for CPCP. > > > > > > > > > > > 3. There is almost no difference between a pre-established > > > > conference and an ad-hoc conference. Try and think of something > > > > that matters: > > > > Time between creation of conference ID and instantiation? > > > > Nope; you can pre-establish a conference and use it > > > > immediately, and there can be an arbitrary > > > > delay between > > > > requesting an ad-hoc conference and the first dialog > > > > with it. And even if there was, who cares? > > > > > > You are asking to redefine the whole concept of ah-hoc > > > conferencing using SIP. The INVITE creates a conference, and > > > creates a dialog. > > > > > > > DialIn/DialOut > > > > Nope - both can do both, or a mixture of either > > > > > > How can you limit the dail-in list in an ad-hoc conference. > > > Let me remind you that an ad-hoc conference does not have a policy. > > > > > > For dial-out list, it is true that you can send REFER > > > requests for the focus, but again, you cannot predefine that > > > list. Also, you have to send a REFER to the focus for each > > > potential participant, creating x number of dialogs, one for > > > each REFER request. > > > > > > > > > > "Long running conference/chat" Nope; length of time of a > > > > conference/chat is not relevant, you could start one > > > > ad-hoc and leave it run for years. > > > > > > again, with ad-hoc conferences, there is no policy to dictate > > > this. I think I will stop commenting now until someone agrues > > > that I am wrong and an ah-hoc conference also needs a policy > > > (where my reply would be: why is it called ah-hoc then?). > > > > > > Regards, > > > Hisham > > > > > > > Therefore, I think you can't use CPCP for pre-established > > > > conferences and SIP for ad-hoc conferences. Pick one. > > There is no > > > > justification for two mechanisms to do the same thing. I have a > > > > problem with policy creating a conference, and I think SIP > > > > signalling is a more appropriate way to create a conference, but > > > > I care more about having one and only one way to do it. > > > > > > > > 4. My view of the conference factory was that you didn't get a > > > > conference instantiation from it, you only got a conference ID. > > > > Either end would immediately terminate the conference > > > factory dialog, > > > > either by an actual BYE or a REFER. If you wanted to immediately > > > > instantiate the conference after getting the conferenceID, fine, > > > > but you don't have to; you can just get the conference ID and > > > > instantiate later. Later could be milliseconds or, if policy > > > > allowed, years. > > > > > > > > 5. I agree that non-SIP signalling mechanisms could be > > standardized > > > > to create conferences (H.323, iCal) if there is a SIP way > > > to do it. > > > > There wouldn't be any interoperability issues with that > > like there > > > > would if both CPCP and SIP can do it. Even a single device > > > that had, > > > > say, both SIP and iCAL mechanisms would have no interoperability > > > > issues with devices that were, say, SIP-only. On the other hand, > > > > if you standardize on CPCP to do it, then you would not expect to > > > > see any other standardized mechanism. > > > > > > > > Brian > > > > > > > > > > > _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Tue Dec 2 11:16:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24622 for ; Tue, 2 Dec 2003 11:16:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARDC0-0006WU-B5 for xcon-archive@odin.ietf.org; Tue, 02 Dec 2003 11:16:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB2GG4Du025068 for xcon-archive@odin.ietf.org; Tue, 2 Dec 2003 11:16:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARDC0-0006WF-4O for xcon-web-archive@optimus.ietf.org; Tue, 02 Dec 2003 11:16:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24582 for ; Tue, 2 Dec 2003 11:15:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARDBz-0003I6-00 for xcon-web-archive@ietf.org; Tue, 02 Dec 2003 11:16:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARDBy-0003I3-00 for xcon-web-archive@ietf.org; Tue, 02 Dec 2003 11:16:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARDBy-0006Uk-EN; Tue, 02 Dec 2003 11:16:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARDBS-0006SN-Dt for xcon@optimus.ietf.org; Tue, 02 Dec 2003 11:15:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24468 for ; Tue, 2 Dec 2003 11:15:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARDBR-0003GJ-00 for xcon@ietf.org; Tue, 02 Dec 2003 11:15:29 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1ARDBR-0003Dx-00 for xcon@ietf.org; Tue, 02 Dec 2003 11:15:29 -0500 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hB2GErAt012198; Tue, 2 Dec 2003 08:14:54 -0800 (PST) Received: from cisco.com ([161.44.79.239]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AEI92850; Tue, 2 Dec 2003 11:14:51 -0500 (EST) Message-ID: <3FCCBA75.60504@cisco.com> Date: Tue, 02 Dec 2003 11:14:45 -0500 From: Paul Kyzivat 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: hisham.khartabil@nokia.com CC: Brian.Rosen@marconi.com, rohan@cisco.com, alan.johnston@mci.com, georg.mayer@nokia.com, oritl@microsoft.com, xcon@ietf.org Subject: Re: [XCON] Chicken and Egg - Can CPCP create a conference References: <2038BCC78B1AD641891A0D1AE133DBB70118B116@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit hisham.khartabil@nokia.com wrote: > >>Several points to make. In my view: >>1. "Instantiating" a conference is a concept that is getting >>confusing. >>It's all in what you mean. I think it's when the mixer resources >>are actually allocated (as opposed to reserved). That starts when >>the first participant creates a dialog with the focus, and ends >>when the last dialog terminates. Getting a conference ID doesn't >>instantiate a conference, creating a dialog with it does. > > Some chat type conferences can exist without any participants. > Participants come and go as they please. Why is there a requirement > that at least one participant is needed for the conference to ever exist? I agree. Defining the conference by the allocation of mixer resources seems wrong to me. That is very implementation specific - I might choose to allocate mixer resources differently than Brian does. In case of chat conferences where mixing is trivial, there may not be any explicitly allocated mixing resources at all. IMO a conference is defined by a valid address. So as long as the sip address constituting the conference ID, which names a unique focus, is valid, it *is* a conference. The only real question is what state that conference is in. If the conference isn't scheduled to start yet, then I would hope that a request directed to it would yield some meaningful error - perhaps 480 Temporarily Unavailable, giving the time until it will be available. If a request is directed to it after policy says it should have expired, then a 404 Not Found error would be appropriate. > You are asking to redefine the whole concept of ah-hoc conferencing > using SIP. The INVITE creates a conference, and creates a dialog. ... > again, with ad-hoc conferences, there is no policy to dictate this. > I think I will stop commenting now until someone agrues that I am > wrong and an ah-hoc conference also needs a policy (where my reply > would be: why is it called ah-hoc then?). I have to disagree with you and agree with Brian here. I don't think it makes sense to say a conference has no policy. It may be that you can neither query nor manipulate the policy, but conceptually it still has a policy. Fancier conferencing products would hopefully provide the ability to query and manipulate policy on ad hoc conferences. I think the only real difference is that if you create an ad hoc conference by sending an invitation to a conference factory, you get a conference with some *default* policy determined by the factory in its infinite wisdom. Paul _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Tue Dec 2 11:29:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25266 for ; Tue, 2 Dec 2003 11:29:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARDOa-0007ci-Nx for xcon-archive@odin.ietf.org; Tue, 02 Dec 2003 11:29:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB2GT4GX029281 for xcon-archive@odin.ietf.org; Tue, 2 Dec 2003 11:29:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARDOZ-0007c2-Mt for xcon-web-archive@optimus.ietf.org; Tue, 02 Dec 2003 11:29:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25246 for ; Tue, 2 Dec 2003 11:28:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARDOY-0003a9-00 for xcon-web-archive@ietf.org; Tue, 02 Dec 2003 11:29:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARDOY-0003a1-00 for xcon-web-archive@ietf.org; Tue, 02 Dec 2003 11:29:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARDOY-0007b5-1B; Tue, 02 Dec 2003 11:29:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARDNq-0007ZI-6h for xcon@optimus.ietf.org; Tue, 02 Dec 2003 11:28:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25186 for ; Tue, 2 Dec 2003 11:28:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARDNo-0003Xu-00 for xcon@ietf.org; Tue, 02 Dec 2003 11:28:16 -0500 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 1ARDNn-0003XT-00 for xcon@ietf.org; Tue, 02 Dec 2003 11:28:15 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA09515; Tue, 2 Dec 2003 11:27:42 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA24138; Tue, 2 Dec 2003 11:27:43 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Tue, 2 Dec 2003 11:27:42 -0500 Message-ID: <313680C9A886D511A06000204840E1CF070B6153@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Alan Johnston'" , hisham.khartabil@nokia.com, rohan@cisco.com, pkyzivat@cisco.com Cc: georg.mayer@nokia.com, oritl@microsoft.com, xcon@ietf.org Subject: RE: [XCON] Chicken and Egg - Can CPCP create a conference Date: Tue, 2 Dec 2003 11:27:41 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , Agree with one nit. Every conference starts with a default policy. You then use CPCP to modify it. The conference service defines the default policy. It may also enforce limits on what kinds of changes could be made to policy with CPCP, but that is beyond the scope of our work. The default policy for an ad-hoc conference may or may not be different from the default policy for a pre-scheduled conference; that's an implementation issue. If you create a conference ID, connect to the conference policy server and request it's current conference policy, you should get a coherent answer. > -----Original Message----- > From: Alan Johnston [mailto:alan.johnston@mci.com] > Sent: Tuesday, December 02, 2003 10:52 AM > To: hisham.khartabil@nokia.com; Brian.Rosen@marconi.com; > rohan@cisco.com; pkyzivat@cisco.com > Cc: georg.mayer@nokia.com; oritl@microsoft.com; xcon@ietf.org > Subject: RE: [XCON] Chicken and Egg - Can CPCP create a conference > > > At 05:26 PM 12/2/2003 +0200, hisham.khartabil@nokia.com wrote: > > > > > -----Original Message----- > > > From: ext Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > > Sent: 02.December.2003 16:52 > > > To: Khartabil Hisham (NMP-MSW/Helsinki); rohan@cisco.com; > > > pkyzivat@cisco.com > > > Cc: alan.johnston@mci.com; Mayer Georg (NMP-MSW/Helsinki); > > > oritl@microsoft.com; xcon@ietf.org > > > Subject: RE: [XCON] Chicken and Egg - Can CPCP create a conference > > > > > > > > > So, two fundamental differences: > > > 1. You think CPCP has some separate namespace independent of a URI > > > (of which a SIP uri is a good, but not exclusive example). > > > I am opposed to that. A conferenceID is a uri. I can imagine a > > > specific instance of a conference service that could have multiple > > > IDs for the same conference, for example, an H.323 URI > and a SIP URI > > > that resolves to the same conference. That's fine, and it's > > > not subject > > > to standardization. However, I think that the ID you use with the > > > focus is always the ID you use with CPCP for the same conference. > > > >I don't understand why the ID for the conference needs to be > the same as > >the ID for the conference policy. > > I agree with Brian here. The conference identifier is the > URI. It is the > means by which a participant joins the conference and depends on the > signaling protocol (SIP, H.323, PSTN, etc.). It can't just > be some random > string. This is a fundamental idea in the framework. > > >If you look at XCAP list usage for example, you will see > that the list-URI > >used when sending SIP SUBSCRIBE requests to the list is not > the same as > >the URI used to manipulate the list using XCAP. They > certainly need to be > >linked, but not necessarily the same. > > I don't understand what you are saying. The policy URI and > the conference > URI can not be the same since they are different protocols, right? > > > >Depending on the protocol we chose, a SIP URI can or cannot > be used to > >identify a conference policy. > > Knowing only the conference URI, it must be possible to determine the > conference policy URI. > > > > > > > > 2. You think ad-hoc conferences don't have policy. I am > > > fundamentally > > > opposed to that. Ad-hoc conferences should have all of the > > > functionality of a pre-established conference and I can't > imagine any > > > reason why we can't provide that. > > > >If we replicate everything that a scheduled conference can > have to ad-hoc > >conferences, then we don't need scheduled conferences at > all. Perhaps we > >need to define the scope of an ad-hoc conference. To me an > ad-hoc is just > >that; a conference created instantaneously for discussing an > urgent matter > >or whatever. You REFER other participants and it terminated > as soon as the > >last participant leaves. There are no start and stop times, > there are no > >dial-out and dial-in lists configured, there is no general > conference > >info, and there are no media policies. > > I agree 100% with Brian. An ad-hoc conference does have > policy, but it is > a default (non-unique) policy. The creator of the conference > factory URI > sets that policy. It is possible for this policy to be > manipulated once > the conference has begun, but again this is up to the application. > > There is no such thing as an "ad-hoc conference" or a "scheduled > conference" - however,there are "ad-hoc methods" of joining > or being added > to a conference, and scheduled means. > > When joining a pre-established, the conference URI is typically sent > out-of-band, often in advance, to participants using say > email or IM. When > a participant is added using ad-hoc means, they often will > not know (see) > the conference URI - they will just be added in via a REFER or > transfer. Trying to come up with a strict definition for one > vs. the other > is very difficult and probably not all that productive. > > I would encourage everyone to carefully read the SIPPING Conference > Framework document - it details many of these issues. > > Thanks, > Alan Johnston > MCI > sip:alan@sipstation.com > > > > > > > We also have a nit, at least I think it's a nit, about > Instantiation. > > > I'm not sure there is any real difference between a re-usable > > > conference ID and an instantiated conference that has no > > > participants. > > > Since I define instantiated as allocated mixer resources, > if I'm not > > > using resources I don't have the conference instantiated. > > > >I agree about the definition of "instantiated". But if there are no > >current participants in a conference, and a server releases > resources and > >keeps the conference ID, it needs to guarantee what > resources will be > >available as soon as a participant enters. This might be not > releasing the > >resources. Perhaps all this is an implementation issue. > > > > > If you define instantiation differently, then you could. > > > It would be good, I think, to have a common agreement on what > > > instantiation means, because we use it in the documents, but I'm > > > not sure we disagree on what can happen. We both agree you can > > > manipulate policy, and we both agree participants can come and go. > > > I guess I would ask you if you have some notion of a re-usable > > > conference ID that is somehow different from an instantiated > > > conference with no participants. > > > >A conference ID can exist even if a conference is not > instantiated. But > >what I was trying to say is that a conference can be > instantiated without > >any participants, unless as I said, the resources can be > guaranteed to be > >reallocated. > > > >Regards, > >Hisham > > > > > > Brian > > > > > > > > > > -----Original Message----- > > > > From: hisham.khartabil@nokia.com > [mailto:hisham.khartabil@nokia.com] > > > > Sent: Tuesday, December 02, 2003 9:26 AM > > > > To: Brian.Rosen@marconi.com; rohan@cisco.com; pkyzivat@cisco.com > > > > Cc: alan.johnston@mci.com; georg.mayer@nokia.com; > > > oritl@microsoft.com; > > > > xcon@ietf.org > > > > Subject: RE: [XCON] Chicken and Egg - Can CPCP create a > conference > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: ext Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > > > > Sent: 02.December.2003 15:16 > > > > > To: Khartabil Hisham (NMP-MSW/Helsinki); rohan@cisco.com; > > > > > 'Paul Kyzivat' > > > > > Cc: alan.johnston@mci.com; Mayer Georg (NMP-MSW/Helsinki); > > > > > oritl@microsoft.com; xcon@ietf.org > > > > > Subject: RE: [XCON] Chicken and Egg - Can CPCP create > a conference > > > > > > > > > > > > > > > Well it's clear that my view is different from you-all. > > > > > Not an unfamiliar situation :( > > > > > Let me keep trying a while, but I'll cave if I'm out here > > > > > by myself for too long. > > > > > > > > > > Several points to make. In my view: > > > > > 1. "Instantiating" a conference is a concept that is getting > > > > > confusing. > > > > > It's all in what you mean. I think it's when the > mixer resources > > > > > are actually allocated (as opposed to reserved). > That starts when > > > > > the first participant creates a dialog with the > focus, and ends > > > > > when the last dialog terminates. Getting a > conference ID doesn't > > > > > instantiate a conference, creating a dialog with it does. > > > > > > > > Some chat type conferences can exist without any > > > > participants. Participants come and go as they please. Why is > > > > there a requirement that at least one participant is needed > > > > for the conference to ever exist? > > > > > > > > > > > > > > You can have a policy on whether the conference ID > expires when > > > > > the last dialog terminates. If it does, once the conference > > > > > instantiation terminates, it cannot be re-instantiated. > > > > > If it doesn't, then it can be re-instantiated. An > example of the > > > > > latter is a weekly sales meeting or a "meet-me" number. > > > > > An example of the latter could be a 4-way call > created by a CONF > > > > > button. > > > > > > > > > > 2. You can manipulate policy before you instantiate a > conference. > > > > > As soon as a conference ID is created, policy is > available to be > > > > > manipulated on it. > > > > > > > > Agreed on the part, but I don't think you need the conferece > > > > ID (that is the SIP URI for the conference) in order to > > > > manipulate the policy. CPCP can provide its own conference > > > > policy ID that is somehow mapped to a conference ID. This > > > > depends on the protocol chosen for CPCP. > > > > > > > > > > > > > > 3. There is almost no difference between a pre-established > > > > > conference and an ad-hoc conference. Try and think > of something > > > > > that matters: > > > > > Time between creation of conference ID and instantiation? > > > > > Nope; you can pre-establish a conference and use it > > > > > immediately, and there can be an arbitrary > > > > > delay between > > > > > requesting an ad-hoc conference and the first dialog > > > > > with it. And even if there was, who cares? > > > > > > > > You are asking to redefine the whole concept of ah-hoc > > > > conferencing using SIP. The INVITE creates a conference, and > > > > creates a dialog. > > > > > > > > > DialIn/DialOut > > > > > Nope - both can do both, or a mixture of either > > > > > > > > How can you limit the dail-in list in an ad-hoc conference. > > > > Let me remind you that an ad-hoc conference does not > have a policy. > > > > > > > > For dial-out list, it is true that you can send REFER > > > > requests for the focus, but again, you cannot predefine that > > > > list. Also, you have to send a REFER to the focus for each > > > > potential participant, creating x number of dialogs, one for > > > > each REFER request. > > > > > > > > > > > > > "Long running conference/chat" Nope; length of time of a > > > > > conference/chat is not relevant, you could start one > > > > > ad-hoc and leave it run for years. > > > > > > > > again, with ad-hoc conferences, there is no policy to dictate > > > > this. I think I will stop commenting now until someone agrues > > > > that I am wrong and an ah-hoc conference also needs a policy > > > > (where my reply would be: why is it called ah-hoc then?). > > > > > > > > Regards, > > > > Hisham > > > > > > > > > Therefore, I think you can't use CPCP for pre-established > > > > > conferences and SIP for ad-hoc conferences. Pick one. > > > There is no > > > > > justification for two mechanisms to do the same > thing. I have a > > > > > problem with policy creating a conference, and I think SIP > > > > > signalling is a more appropriate way to create a > conference, but > > > > > I care more about having one and only one way to do it. > > > > > > > > > > 4. My view of the conference factory was that you didn't get a > > > > > conference instantiation from it, you only got a > conference ID. > > > > > Either end would immediately terminate the conference > > > > factory dialog, > > > > > either by an actual BYE or a REFER. If you wanted to > immediately > > > > > instantiate the conference after getting the > conferenceID, fine, > > > > > but you don't have to; you can just get the conference ID and > > > > > instantiate later. Later could be milliseconds or, if policy > > > > > allowed, years. > > > > > > > > > > 5. I agree that non-SIP signalling mechanisms could be > > > standardized > > > > > to create conferences (H.323, iCal) if there is a SIP way > > > > to do it. > > > > > There wouldn't be any interoperability issues with that > > > like there > > > > > would if both CPCP and SIP can do it. Even a single device > > > > that had, > > > > > say, both SIP and iCAL mechanisms would have no > interoperability > > > > > issues with devices that were, say, SIP-only. On the > other hand, > > > > > if you standardize on CPCP to do it, then you would > not expect to > > > > > see any other standardized mechanism. > > > > > > > > > > Brian > > > > > > > > > > > > > > > > _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Tue Dec 2 11:36:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25558 for ; Tue, 2 Dec 2003 11:36:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARDVN-00085x-Uq for xcon-archive@odin.ietf.org; Tue, 02 Dec 2003 11:36:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB2Ga5Lj031058 for xcon-archive@odin.ietf.org; Tue, 2 Dec 2003 11:36:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARDVM-00084p-Gf for xcon-web-archive@optimus.ietf.org; Tue, 02 Dec 2003 11:36:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25544 for ; Tue, 2 Dec 2003 11:35:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARDVL-0003iv-00 for xcon-web-archive@ietf.org; Tue, 02 Dec 2003 11:36:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARDVK-0003is-00 for xcon-web-archive@ietf.org; Tue, 02 Dec 2003 11:36:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARDVK-00084H-O8; Tue, 02 Dec 2003 11:36:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARDUt-00083I-MF for xcon@optimus.ietf.org; Tue, 02 Dec 2003 11:35:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25529 for ; Tue, 2 Dec 2003 11:35:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARDUr-0003iD-00 for xcon@ietf.org; Tue, 02 Dec 2003 11:35:33 -0500 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 1ARDUq-0003hf-00 for xcon@ietf.org; Tue, 02 Dec 2003 11:35:32 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA09777; Tue, 2 Dec 2003 11:35:00 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA25757; Tue, 2 Dec 2003 11:35:00 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Tue, 2 Dec 2003 11:34:59 -0500 Message-ID: <313680C9A886D511A06000204840E1CF070B6154@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Paul Kyzivat'" , hisham.khartabil@nokia.com Cc: rohan@cisco.com, alan.johnston@mci.com, georg.mayer@nokia.com, oritl@microsoft.com, xcon@ietf.org Subject: RE: [XCON] Chicken and Egg - Can CPCP create a conference Date: Tue, 2 Dec 2003 11:34:58 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , We need a consistent definition of "instantiation" or we need to not use the term in the documents. I think we are still just having a semantic discussion, and not arguing over much substance. I think we all agree that once you have a conference ID, you can do things with it: You can use it to change policy You can INVITE yourself to it You can REFER someone to it Depending on the policy in force at the time, an INVITE or REFER may not be accepted, and that could be because of the time, or who you are, or what your SDP offer is. All of those are conference or media policy decisions, and nothing else. I can argue your objections to my definition of "instantiate" or you can propose another definition on instantiation, or propose that we eliminate the word from our documents. Brian > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Tuesday, December 02, 2003 11:15 AM > To: hisham.khartabil@nokia.com > Cc: Brian.Rosen@marconi.com; rohan@cisco.com; alan.johnston@mci.com; > georg.mayer@nokia.com; oritl@microsoft.com; xcon@ietf.org > Subject: Re: [XCON] Chicken and Egg - Can CPCP create a conference > > > > > hisham.khartabil@nokia.com wrote: > > > >>Several points to make. In my view: > >>1. "Instantiating" a conference is a concept that is getting > >>confusing. > >>It's all in what you mean. I think it's when the mixer resources > >>are actually allocated (as opposed to reserved). That starts when > >>the first participant creates a dialog with the focus, and ends > >>when the last dialog terminates. Getting a conference ID doesn't > >>instantiate a conference, creating a dialog with it does. > > > > Some chat type conferences can exist without any participants. > > Participants come and go as they please. Why is there a requirement > > that at least one participant is needed for the conference > to ever exist? > > I agree. Defining the conference by the allocation of mixer resources > seems wrong to me. That is very implementation specific - I > might choose > to allocate mixer resources differently than Brian does. In > case of chat > conferences where mixing is trivial, there may not be any explicitly > allocated mixing resources at all. > > IMO a conference is defined by a valid address. So as long as the sip > address constituting the conference ID, which names a unique > focus, is > valid, it *is* a conference. The only real question is what > state that > conference is in. If the conference isn't scheduled to start > yet, then I > would hope that a request directed to it would yield some meaningful > error - perhaps 480 Temporarily Unavailable, giving the time until it > will be available. If a request is directed to it after > policy says it > should have expired, then a 404 Not Found error would be appropriate. > > > You are asking to redefine the whole concept of ah-hoc conferencing > > using SIP. The INVITE creates a conference, and creates a dialog. > ... > > again, with ad-hoc conferences, there is no policy to dictate this. > > I think I will stop commenting now until someone agrues that I am > > wrong and an ah-hoc conference also needs a policy (where my reply > > would be: why is it called ah-hoc then?). > > I have to disagree with you and agree with Brian here. > I don't think it makes sense to say a conference has no policy. > It may be that you can neither query nor manipulate the policy, but > conceptually it still has a policy. Fancier conferencing > products would > hopefully provide the ability to query and manipulate policy > on ad hoc > conferences. > > I think the only real difference is that if you create an ad hoc > conference by sending an invitation to a conference factory, > you get a > conference with some *default* policy determined by the > factory in its > infinite wisdom. > > Paul > > > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon > _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Tue Dec 2 12:00:46 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27209 for ; Tue, 2 Dec 2003 12:00:46 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARDsn-0002E5-I0 for xcon-archive@odin.ietf.org; Tue, 02 Dec 2003 12:00:28 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB2H0G4X008549 for xcon-archive@odin.ietf.org; Tue, 2 Dec 2003 12:00:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARDsl-0002Dg-Ny for xcon-web-archive@optimus.ietf.org; Tue, 02 Dec 2003 12:00:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27161 for ; Tue, 2 Dec 2003 12:00:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARDsk-0004Kc-00 for xcon-web-archive@ietf.org; Tue, 02 Dec 2003 12:00:14 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARDsj-0004KZ-00 for xcon-web-archive@ietf.org; Tue, 02 Dec 2003 12:00:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARDsf-0002Cq-TT; Tue, 02 Dec 2003 12:00:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARDs3-0002BU-4i for xcon@optimus.ietf.org; Tue, 02 Dec 2003 11:59:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27063 for ; Tue, 2 Dec 2003 11:59:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARDs1-0004Ir-00 for xcon@ietf.org; Tue, 02 Dec 2003 11:59:29 -0500 Received: from thoth.sbs.de ([192.35.17.2]) by ietf-mx with esmtp (Exim 4.12) id 1ARDs0-0004Ih-00 for xcon@ietf.org; Tue, 02 Dec 2003 11:59:29 -0500 Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by thoth.sbs.de (8.11.7/8.11.7) with ESMTP id hB2GwT215837; Tue, 2 Dec 2003 17:58:29 +0100 (MET) Received: from blues.mchh.siemens.de (blues.mchh.siemens.de [139.21.204.206]) by mail2.siemens.de (8.11.7/8.11.7) with ESMTP id hB2GwSP29478; Tue, 2 Dec 2003 17:58:28 +0100 (MET) Received: from mchh247e.mchh.siemens.de (mchh247e.mchh.siemens.de [139.21.200.57]) by blues.mchh.siemens.de (8.9.3/8.9.1) with ESMTP id RAA28777; Tue, 2 Dec 2003 17:58:24 +0100 (MET) Received: by mchh247e.mchh.siemens.de with Internet Mail Service (5.5.2656.59) id ; Tue, 2 Dec 2003 17:58:26 +0100 Message-ID: <76592C4D3DA1AC4FB8424084D10D31A8D5CE6A@mchh2c4e.mchh.siemens.de> From: Heil Franca Marcelo To: "'Rosen, Brian'" , "'Alan Johnston'" , hisham.khartabil@nokia.com, rohan@cisco.com, pkyzivat@cisco.com Cc: georg.mayer@nokia.com, oritl@microsoft.com, xcon@ietf.org Subject: AW: [XCON] Chicken and Egg - Can CPCP create a conference Date: Tue, 2 Dec 2003 17:58:24 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > -----Urspr=FCngliche Nachricht----- > Von: Rosen, Brian [mailto:Brian.Rosen@marconi.com]=20 > Gesendet: Dienstag, 2. Dezember 2003 17:28 > An: 'Alan Johnston'; hisham.khartabil@nokia.com;=20 > rohan@cisco.com; pkyzivat@cisco.com > Cc: georg.mayer@nokia.com; oritl@microsoft.com; xcon@ietf.org > Betreff: RE: [XCON] Chicken and Egg - Can CPCP create a conference >=20 >=20 > Agree with one nit. >=20 > Every conference starts with a default policy. You then use CPCP to > modify it. The conference service defines the default policy. It = may > also enforce limits on what kinds of changes could be made to policy > with CPCP, but that is beyond the scope of our work. The=20 > default policy > for an ad-hoc conference may or may not be different from the default > policy for a pre-scheduled conference; that's an implementation = issue. >=20 I see one point here: pre-scheduled conferences may start with a policy = which is different from the default one, as the policy could have been = changed at conference creation (scheduling) time. (This is of course = application dependent.) > If you create a conference ID, connect to the conference policy = server > and request it's current conference policy, you should get a coherent > answer. >=20 I think that the conference server is the entity that creates the = conference ID (on request), not "me"... Marcelo > > -----Original Message----- > > From: Alan Johnston [mailto:alan.johnston@mci.com] > > Sent: Tuesday, December 02, 2003 10:52 AM > > To: hisham.khartabil@nokia.com; Brian.Rosen@marconi.com; > > rohan@cisco.com; pkyzivat@cisco.com > > Cc: georg.mayer@nokia.com; oritl@microsoft.com; xcon@ietf.org > > Subject: RE: [XCON] Chicken and Egg - Can CPCP create a conference > >=20 > >=20 > > At 05:26 PM 12/2/2003 +0200, hisham.khartabil@nokia.com wrote: > >=20 > >=20 > > > > -----Original Message----- > > > > From: ext Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > > > Sent: 02.December.2003 16:52 > > > > To: Khartabil Hisham (NMP-MSW/Helsinki); rohan@cisco.com; > > > > pkyzivat@cisco.com > > > > Cc: alan.johnston@mci.com; Mayer Georg (NMP-MSW/Helsinki); > > > > oritl@microsoft.com; xcon@ietf.org > > > > Subject: RE: [XCON] Chicken and Egg - Can CPCP create a=20 > conference > > > > > > > > > > > > So, two fundamental differences: > > > > 1. You think CPCP has some separate namespace=20 > independent of a URI > > > > (of which a SIP uri is a good, but not exclusive example). > > > > I am opposed to that. A conferenceID is a uri. I can imagine = a > > > > specific instance of a conference service that could=20 > have multiple > > > > IDs for the same conference, for example, an H.323 URI=20 > > and a SIP URI > > > > that resolves to the same conference. That's fine, and it's > > > > not subject > > > > to standardization. However, I think that the ID you=20 > use with the > > > > focus is always the ID you use with CPCP for the same=20 > conference. > > > > > >I don't understand why the ID for the conference needs to be=20 > > the same as=20 > > >the ID for the conference policy. > >=20 > > I agree with Brian here. The conference identifier is the=20 > > URI. It is the=20 > > means by which a participant joins the conference and=20 > depends on the=20 > > signaling protocol (SIP, H.323, PSTN, etc.). It can't just=20 > > be some random=20 > > string. This is a fundamental idea in the framework. > >=20 > > >If you look at XCAP list usage for example, you will see=20 > > that the list-URI=20 > > >used when sending SIP SUBSCRIBE requests to the list is not=20 > > the same as=20 > > >the URI used to manipulate the list using XCAP. They=20 > > certainly need to be=20 > > >linked, but not necessarily the same. > >=20 > > I don't understand what you are saying. The policy URI and=20 > > the conference=20 > > URI can not be the same since they are different protocols, right? > >=20 > >=20 > > >Depending on the protocol we chose, a SIP URI can or cannot=20 > > be used to=20 > > >identify a conference policy. > >=20 > > Knowing only the conference URI, it must be possible to=20 > determine the=20 > > conference policy URI. > >=20 > >=20 > > > > > > > > 2. You think ad-hoc conferences don't have policy. I am > > > > fundamentally > > > > opposed to that. Ad-hoc conferences should have all of the > > > > functionality of a pre-established conference and I can't=20 > > imagine any > > > > reason why we can't provide that. > > > > > >If we replicate everything that a scheduled conference can=20 > > have to ad-hoc=20 > > >conferences, then we don't need scheduled conferences at=20 > > all. Perhaps we=20 > > >need to define the scope of an ad-hoc conference. To me an=20 > > ad-hoc is just=20 > > >that; a conference created instantaneously for discussing an=20 > > urgent matter=20 > > >or whatever. You REFER other participants and it terminated=20 > > as soon as the=20 > > >last participant leaves. There are no start and stop times,=20 > > there are no=20 > > >dial-out and dial-in lists configured, there is no general=20 > > conference=20 > > >info, and there are no media policies. > >=20 > > I agree 100% with Brian. An ad-hoc conference does have=20 > > policy, but it is=20 > > a default (non-unique) policy. The creator of the conference=20 > > factory URI=20 > > sets that policy. It is possible for this policy to be=20 > > manipulated once=20 > > the conference has begun, but again this is up to the application. > >=20 > > There is no such thing as an "ad-hoc conference" or a "scheduled=20 > > conference" - however,there are "ad-hoc methods" of joining=20 > > or being added=20 > > to a conference, and scheduled means. > >=20 > > When joining a pre-established, the conference URI is=20 > typically sent=20 > > out-of-band, often in advance, to participants using say=20 > > email or IM. When=20 > > a participant is added using ad-hoc means, they often will=20 > > not know (see)=20 > > the conference URI - they will just be added in via a REFER or=20 > > transfer. Trying to come up with a strict definition for one=20 > > vs. the other=20 > > is very difficult and probably not all that productive. > >=20 > > I would encourage everyone to carefully read the SIPPING Conference = > > Framework document - it details many of these issues. > >=20 > > Thanks, > > Alan Johnston > > MCI > > sip:alan@sipstation.com > >=20 > > > > > > > > We also have a nit, at least I think it's a nit, about=20 > > Instantiation. > > > > I'm not sure there is any real difference between a re-usable > > > > conference ID and an instantiated conference that has no > > > > participants. > > > > Since I define instantiated as allocated mixer resources,=20 > > if I'm not > > > > using resources I don't have the conference instantiated. > > > > > >I agree about the definition of "instantiated". But if=20 > there are no=20 > > >current participants in a conference, and a server releases=20 > > resources and=20 > > >keeps the conference ID, it needs to guarantee what=20 > > resources will be=20 > > >available as soon as a participant enters. This might be not=20 > > releasing the=20 > > >resources. Perhaps all this is an implementation issue. > > > > > > > If you define instantiation differently, then you could. > > > > It would be good, I think, to have a common agreement on what > > > > instantiation means, because we use it in the documents, but = I'm > > > > not sure we disagree on what can happen. We both agree you can > > > > manipulate policy, and we both agree participants can=20 > come and go. > > > > I guess I would ask you if you have some notion of a re-usable > > > > conference ID that is somehow different from an instantiated > > > > conference with no participants. > > > > > >A conference ID can exist even if a conference is not=20 > > instantiated. But=20 > > >what I was trying to say is that a conference can be=20 > > instantiated without=20 > > >any participants, unless as I said, the resources can be=20 > > guaranteed to be=20 > > >reallocated. > > > > > >Regards, > > >Hisham > > > > > > > > Brian > > > > > > > > > > > > > -----Original Message----- > > > > > From: hisham.khartabil@nokia.com=20 > > [mailto:hisham.khartabil@nokia.com] > > > > > Sent: Tuesday, December 02, 2003 9:26 AM > > > > > To: Brian.Rosen@marconi.com; rohan@cisco.com;=20 > pkyzivat@cisco.com > > > > > Cc: alan.johnston@mci.com; georg.mayer@nokia.com; > > > > oritl@microsoft.com; > > > > > xcon@ietf.org > > > > > Subject: RE: [XCON] Chicken and Egg - Can CPCP create a=20 > > conference > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: ext Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > > > > > Sent: 02.December.2003 15:16 > > > > > > To: Khartabil Hisham (NMP-MSW/Helsinki); rohan@cisco.com; > > > > > > 'Paul Kyzivat' > > > > > > Cc: alan.johnston@mci.com; Mayer Georg (NMP-MSW/Helsinki); > > > > > > oritl@microsoft.com; xcon@ietf.org > > > > > > Subject: RE: [XCON] Chicken and Egg - Can CPCP create=20 > > a conference > > > > > > > > > > > > > > > > > > Well it's clear that my view is different from you-all. > > > > > > Not an unfamiliar situation :( > > > > > > Let me keep trying a while, but I'll cave if I'm out here > > > > > > by myself for too long. > > > > > > > > > > > > Several points to make. In my view: > > > > > > 1. "Instantiating" a conference is a concept that is = getting > > > > > > confusing. > > > > > > It's all in what you mean. I think it's when the=20 > > mixer resources > > > > > > are actually allocated (as opposed to reserved). =20 > > That starts when > > > > > > the first participant creates a dialog with the=20 > > focus, and ends > > > > > > when the last dialog terminates. Getting a=20 > > conference ID doesn't > > > > > > instantiate a conference, creating a dialog with it does. > > > > > > > > > > Some chat type conferences can exist without any > > > > > participants. Participants come and go as they please. Why is > > > > > there a requirement that at least one participant is needed > > > > > for the conference to ever exist? > > > > > > > > > > > > > > > > > You can have a policy on whether the conference ID=20 > > expires when > > > > > > the last dialog terminates. If it does, once the = conference > > > > > > instantiation terminates, it cannot be re-instantiated. > > > > > > If it doesn't, then it can be re-instantiated. An=20 > > example of the > > > > > > latter is a weekly sales meeting or a "meet-me" number. > > > > > > An example of the latter could be a 4-way call=20 > > created by a CONF > > > > > > button. > > > > > > > > > > > > 2. You can manipulate policy before you instantiate a=20 > > conference. > > > > > > As soon as a conference ID is created, policy is=20 > > available to be > > > > > > manipulated on it. > > > > > > > > > > Agreed on the part, but I don't think you need the conferece > > > > > ID (that is the SIP URI for the conference) in order to > > > > > manipulate the policy. CPCP can provide its own conference > > > > > policy ID that is somehow mapped to a conference ID. This > > > > > depends on the protocol chosen for CPCP. > > > > > > > > > > > > > > > > > 3. There is almost no difference between a pre-established > > > > > > conference and an ad-hoc conference. Try and think=20 > > of something > > > > > > that matters: > > > > > > Time between creation of conference ID and instantiation? > > > > > > Nope; you can pre-establish a conference=20 > and use it > > > > > > immediately, and there can be an arbitrary > > > > > > delay between > > > > > > requesting an ad-hoc conference and the=20 > first dialog > > > > > > with it. And even if there was, who cares? > > > > > > > > > > You are asking to redefine the whole concept of ah-hoc > > > > > conferencing using SIP. The INVITE creates a conference, and > > > > > creates a dialog. > > > > > > > > > > > DialIn/DialOut > > > > > > Nope - both can do both, or a mixture of either > > > > > > > > > > How can you limit the dail-in list in an ad-hoc conference. > > > > > Let me remind you that an ad-hoc conference does not=20 > > have a policy. > > > > > > > > > > For dial-out list, it is true that you can send REFER > > > > > requests for the focus, but again, you cannot predefine that > > > > > list. Also, you have to send a REFER to the focus for each > > > > > potential participant, creating x number of dialogs, one for > > > > > each REFER request. > > > > > > > > > > > > > > > > "Long running conference/chat" Nope; length of time of a > > > > > > conference/chat is not relevant, you=20 > could start one > > > > > > ad-hoc and leave it run for years. > > > > > > > > > > again, with ad-hoc conferences, there is no policy to dictate > > > > > this. I think I will stop commenting now until someone agrues > > > > > that I am wrong and an ah-hoc conference also needs a policy > > > > > (where my reply would be: why is it called ah-hoc then?). > > > > > > > > > > Regards, > > > > > Hisham > > > > > > > > > > > Therefore, I think you can't use CPCP for pre-established > > > > > > conferences and SIP for ad-hoc conferences. Pick one. > > > > There is no > > > > > > justification for two mechanisms to do the same=20 > > thing. I have a > > > > > > problem with policy creating a conference, and I think SIP > > > > > > signalling is a more appropriate way to create a=20 > > conference, but > > > > > > I care more about having one and only one way to do it. > > > > > > > > > > > > 4. My view of the conference factory was that you=20 > didn't get a > > > > > > conference instantiation from it, you only got a=20 > > conference ID. > > > > > > Either end would immediately terminate the conference > > > > > factory dialog, > > > > > > either by an actual BYE or a REFER. If you wanted to=20 > > immediately > > > > > > instantiate the conference after getting the=20 > > conferenceID, fine, > > > > > > but you don't have to; you can just get the=20 > conference ID and > > > > > > instantiate later. Later could be milliseconds or,=20 > if policy > > > > > > allowed, years. > > > > > > > > > > > > 5. I agree that non-SIP signalling mechanisms could be > > > > standardized > > > > > > to create conferences (H.323, iCal) if there is a SIP way > > > > > to do it. > > > > > > There wouldn't be any interoperability issues with that > > > > like there > > > > > > would if both CPCP and SIP can do it. Even a single device > > > > > that had, > > > > > > say, both SIP and iCAL mechanisms would have no=20 > > interoperability > > > > > > issues with devices that were, say, SIP-only. On the=20 > > other hand, > > > > > > if you standardize on CPCP to do it, then you would=20 > > not expect to > > > > > > see any other standardized mechanism. > > > > > > > > > > > > Brian > > > > > > > > > > > > > > > > > > > > >=20 >=20 > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon >=20 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Tue Dec 2 12:12:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28151 for ; Tue, 2 Dec 2003 12:12:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARE4C-0004ij-Ba for xcon-archive@odin.ietf.org; Tue, 02 Dec 2003 12:12:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB2HC4So018139 for xcon-archive@odin.ietf.org; Tue, 2 Dec 2003 12:12:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARE4C-0004iU-5P for xcon-web-archive@optimus.ietf.org; Tue, 02 Dec 2003 12:12:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28126 for ; Tue, 2 Dec 2003 12:11:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARE4A-0004gC-00 for xcon-web-archive@ietf.org; Tue, 02 Dec 2003 12:12:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARE4A-0004g9-00 for xcon-web-archive@ietf.org; Tue, 02 Dec 2003 12:12:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARE4A-0004i3-9v; Tue, 02 Dec 2003 12:12:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARE3b-0004gG-Nz for xcon@optimus.ietf.org; Tue, 02 Dec 2003 12:11:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28093 for ; Tue, 2 Dec 2003 12:11:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARE3a-0004f0-00 for xcon@ietf.org; Tue, 02 Dec 2003 12:11:26 -0500 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 1ARE3Z-0004dj-00 for xcon@ietf.org; Tue, 02 Dec 2003 12:11:25 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA11205; Tue, 2 Dec 2003 12:10:50 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA02098; Tue, 2 Dec 2003 12:10:51 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Tue, 2 Dec 2003 12:10:50 -0500 Message-ID: <313680C9A886D511A06000204840E1CF070B6156@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Heil Franca Marcelo'" , "'Alan Johnston'" , hisham.khartabil@nokia.com, rohan@cisco.com, pkyzivat@cisco.com Cc: georg.mayer@nokia.com, oritl@microsoft.com, xcon@ietf.org Subject: RE: [XCON] Chicken and Egg - Can CPCP create a conference Date: Tue, 2 Dec 2003 12:10:49 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Well, now you might see why I think the Conference Factory URI does not instantiate a conference; it just returns a conference ID. That way, you could, if you wanted to, change the default policy before you "started" it. If you go to a scheduler and create a conference, you may or may not have to enter any more questions other than start time. You may not even be asked that; it's implementation dependent. When the service gives you a conference uri, you have what you need to modify the conference policy with CPCP. You can do it immediately after you get the uri, just before the conference starts, immediately after it starts, or just before it ends. Doesn't matter. The protocol mechanism is the same. That's why I don't think CPCP has to create conference uris. It's duplicative of the conference factory uri. We can get rid of one of these mechanisms and not lose anything. I think we should. Brian > -----Original Message----- > From: Heil Franca Marcelo [mailto:marcelo.heil_franca@siemens.com] > Sent: Tuesday, December 02, 2003 11:58 AM > To: 'Rosen, Brian'; 'Alan Johnston'; hisham.khartabil@nokia.com; > rohan@cisco.com; pkyzivat@cisco.com > Cc: georg.mayer@nokia.com; oritl@microsoft.com; xcon@ietf.org > Subject: AW: [XCON] Chicken and Egg - Can CPCP create a conference >=20 >=20 >=20 >=20 > > -----Urspr=FCngliche Nachricht----- > > Von: Rosen, Brian [mailto:Brian.Rosen@marconi.com]=20 > > Gesendet: Dienstag, 2. Dezember 2003 17:28 > > An: 'Alan Johnston'; hisham.khartabil@nokia.com;=20 > > rohan@cisco.com; pkyzivat@cisco.com > > Cc: georg.mayer@nokia.com; oritl@microsoft.com; xcon@ietf.org > > Betreff: RE: [XCON] Chicken and Egg - Can CPCP create a conference > >=20 > >=20 > > Agree with one nit. > >=20 > > Every conference starts with a default policy. You then use CPCP = to > > modify it. The conference service defines the default=20 > policy. It may > > also enforce limits on what kinds of changes could be made to = policy > > with CPCP, but that is beyond the scope of our work. The=20 > > default policy > > for an ad-hoc conference may or may not be different from=20 > the default > > policy for a pre-scheduled conference; that's an=20 > implementation issue. > >=20 > I see one point here: pre-scheduled conferences may start=20 > with a policy which is different from the default one, as the=20 > policy could have been changed at conference creation=20 > (scheduling) time. (This is of course application dependent.) >=20 >=20 > > If you create a conference ID, connect to the conference=20 > policy server > > and request it's current conference policy, you should get=20 > a coherent > > answer. > >=20 > I think that the conference server is the entity that creates=20 > the conference ID (on request), not "me"... >=20 > Marcelo >=20 > > > -----Original Message----- > > > From: Alan Johnston [mailto:alan.johnston@mci.com] > > > Sent: Tuesday, December 02, 2003 10:52 AM > > > To: hisham.khartabil@nokia.com; Brian.Rosen@marconi.com; > > > rohan@cisco.com; pkyzivat@cisco.com > > > Cc: georg.mayer@nokia.com; oritl@microsoft.com; xcon@ietf.org > > > Subject: RE: [XCON] Chicken and Egg - Can CPCP create a = conference > > >=20 > > >=20 > > > At 05:26 PM 12/2/2003 +0200, hisham.khartabil@nokia.com wrote: > > >=20 > > >=20 > > > > > -----Original Message----- > > > > > From: ext Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > > > > Sent: 02.December.2003 16:52 > > > > > To: Khartabil Hisham (NMP-MSW/Helsinki); rohan@cisco.com; > > > > > pkyzivat@cisco.com > > > > > Cc: alan.johnston@mci.com; Mayer Georg (NMP-MSW/Helsinki); > > > > > oritl@microsoft.com; xcon@ietf.org > > > > > Subject: RE: [XCON] Chicken and Egg - Can CPCP create a=20 > > conference > > > > > > > > > > > > > > > So, two fundamental differences: > > > > > 1. You think CPCP has some separate namespace=20 > > independent of a URI > > > > > (of which a SIP uri is a good, but not exclusive example). > > > > > I am opposed to that. A conferenceID is a uri. I=20 > can imagine a > > > > > specific instance of a conference service that could=20 > > have multiple > > > > > IDs for the same conference, for example, an H.323 URI=20 > > > and a SIP URI > > > > > that resolves to the same conference. That's fine, and it's > > > > > not subject > > > > > to standardization. However, I think that the ID you=20 > > use with the > > > > > focus is always the ID you use with CPCP for the same=20 > > conference. > > > > > > > >I don't understand why the ID for the conference needs to be=20 > > > the same as=20 > > > >the ID for the conference policy. > > >=20 > > > I agree with Brian here. The conference identifier is the=20 > > > URI. It is the=20 > > > means by which a participant joins the conference and=20 > > depends on the=20 > > > signaling protocol (SIP, H.323, PSTN, etc.). It can't just=20 > > > be some random=20 > > > string. This is a fundamental idea in the framework. > > >=20 > > > >If you look at XCAP list usage for example, you will see=20 > > > that the list-URI=20 > > > >used when sending SIP SUBSCRIBE requests to the list is not=20 > > > the same as=20 > > > >the URI used to manipulate the list using XCAP. They=20 > > > certainly need to be=20 > > > >linked, but not necessarily the same. > > >=20 > > > I don't understand what you are saying. The policy URI and=20 > > > the conference=20 > > > URI can not be the same since they are different protocols, = right? > > >=20 > > >=20 > > > >Depending on the protocol we chose, a SIP URI can or cannot=20 > > > be used to=20 > > > >identify a conference policy. > > >=20 > > > Knowing only the conference URI, it must be possible to=20 > > determine the=20 > > > conference policy URI. > > >=20 > > >=20 > > > > > > > > > > 2. You think ad-hoc conferences don't have policy. I am > > > > > fundamentally > > > > > opposed to that. Ad-hoc conferences should have all of the > > > > > functionality of a pre-established conference and I can't=20 > > > imagine any > > > > > reason why we can't provide that. > > > > > > > >If we replicate everything that a scheduled conference can=20 > > > have to ad-hoc=20 > > > >conferences, then we don't need scheduled conferences at=20 > > > all. Perhaps we=20 > > > >need to define the scope of an ad-hoc conference. To me an=20 > > > ad-hoc is just=20 > > > >that; a conference created instantaneously for discussing an=20 > > > urgent matter=20 > > > >or whatever. You REFER other participants and it terminated=20 > > > as soon as the=20 > > > >last participant leaves. There are no start and stop times,=20 > > > there are no=20 > > > >dial-out and dial-in lists configured, there is no general=20 > > > conference=20 > > > >info, and there are no media policies. > > >=20 > > > I agree 100% with Brian. An ad-hoc conference does have=20 > > > policy, but it is=20 > > > a default (non-unique) policy. The creator of the conference=20 > > > factory URI=20 > > > sets that policy. It is possible for this policy to be=20 > > > manipulated once=20 > > > the conference has begun, but again this is up to the = application. > > >=20 > > > There is no such thing as an "ad-hoc conference" or a "scheduled=20 > > > conference" - however,there are "ad-hoc methods" of joining=20 > > > or being added=20 > > > to a conference, and scheduled means. > > >=20 > > > When joining a pre-established, the conference URI is=20 > > typically sent=20 > > > out-of-band, often in advance, to participants using say=20 > > > email or IM. When=20 > > > a participant is added using ad-hoc means, they often will=20 > > > not know (see)=20 > > > the conference URI - they will just be added in via a REFER or=20 > > > transfer. Trying to come up with a strict definition for one=20 > > > vs. the other=20 > > > is very difficult and probably not all that productive. > > >=20 > > > I would encourage everyone to carefully read the SIPPING=20 > Conference=20 > > > Framework document - it details many of these issues. > > >=20 > > > Thanks, > > > Alan Johnston > > > MCI > > > sip:alan@sipstation.com > > >=20 > > > > > > > > > > We also have a nit, at least I think it's a nit, about=20 > > > Instantiation. > > > > > I'm not sure there is any real difference between a re-usable > > > > > conference ID and an instantiated conference that has no > > > > > participants. > > > > > Since I define instantiated as allocated mixer resources,=20 > > > if I'm not > > > > > using resources I don't have the conference instantiated. > > > > > > > >I agree about the definition of "instantiated". But if=20 > > there are no=20 > > > >current participants in a conference, and a server releases=20 > > > resources and=20 > > > >keeps the conference ID, it needs to guarantee what=20 > > > resources will be=20 > > > >available as soon as a participant enters. This might be not=20 > > > releasing the=20 > > > >resources. Perhaps all this is an implementation issue. > > > > > > > > > If you define instantiation differently, then you could. > > > > > It would be good, I think, to have a common agreement on what > > > > > instantiation means, because we use it in the=20 > documents, but I'm > > > > > not sure we disagree on what can happen. We both=20 > agree you can > > > > > manipulate policy, and we both agree participants can=20 > > come and go. > > > > > I guess I would ask you if you have some notion of a = re-usable > > > > > conference ID that is somehow different from an instantiated > > > > > conference with no participants. > > > > > > > >A conference ID can exist even if a conference is not=20 > > > instantiated. But=20 > > > >what I was trying to say is that a conference can be=20 > > > instantiated without=20 > > > >any participants, unless as I said, the resources can be=20 > > > guaranteed to be=20 > > > >reallocated. > > > > > > > >Regards, > > > >Hisham > > > > > > > > > > Brian > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: hisham.khartabil@nokia.com=20 > > > [mailto:hisham.khartabil@nokia.com] > > > > > > Sent: Tuesday, December 02, 2003 9:26 AM > > > > > > To: Brian.Rosen@marconi.com; rohan@cisco.com;=20 > > pkyzivat@cisco.com > > > > > > Cc: alan.johnston@mci.com; georg.mayer@nokia.com; > > > > > oritl@microsoft.com; > > > > > > xcon@ietf.org > > > > > > Subject: RE: [XCON] Chicken and Egg - Can CPCP create a=20 > > > conference > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: ext Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > > > > > > Sent: 02.December.2003 15:16 > > > > > > > To: Khartabil Hisham (NMP-MSW/Helsinki); rohan@cisco.com; > > > > > > > 'Paul Kyzivat' > > > > > > > Cc: alan.johnston@mci.com; Mayer Georg = (NMP-MSW/Helsinki); > > > > > > > oritl@microsoft.com; xcon@ietf.org > > > > > > > Subject: RE: [XCON] Chicken and Egg - Can CPCP create=20 > > > a conference > > > > > > > > > > > > > > > > > > > > > Well it's clear that my view is different from you-all. > > > > > > > Not an unfamiliar situation :( > > > > > > > Let me keep trying a while, but I'll cave if I'm out here > > > > > > > by myself for too long. > > > > > > > > > > > > > > Several points to make. In my view: > > > > > > > 1. "Instantiating" a conference is a concept that=20 > is getting > > > > > > > confusing. > > > > > > > It's all in what you mean. I think it's when the=20 > > > mixer resources > > > > > > > are actually allocated (as opposed to reserved). =20 > > > That starts when > > > > > > > the first participant creates a dialog with the=20 > > > focus, and ends > > > > > > > when the last dialog terminates. Getting a=20 > > > conference ID doesn't > > > > > > > instantiate a conference, creating a dialog with it does. > > > > > > > > > > > > Some chat type conferences can exist without any > > > > > > participants. Participants come and go as they=20 > please. Why is > > > > > > there a requirement that at least one participant is needed > > > > > > for the conference to ever exist? > > > > > > > > > > > > > > > > > > > > You can have a policy on whether the conference ID=20 > > > expires when > > > > > > > the last dialog terminates. If it does, once the=20 > conference > > > > > > > instantiation terminates, it cannot be re-instantiated. > > > > > > > If it doesn't, then it can be re-instantiated. An=20 > > > example of the > > > > > > > latter is a weekly sales meeting or a "meet-me" number. > > > > > > > An example of the latter could be a 4-way call=20 > > > created by a CONF > > > > > > > button. > > > > > > > > > > > > > > 2. You can manipulate policy before you instantiate a=20 > > > conference. > > > > > > > As soon as a conference ID is created, policy is=20 > > > available to be > > > > > > > manipulated on it. > > > > > > > > > > > > Agreed on the part, but I don't think you need the = conferece > > > > > > ID (that is the SIP URI for the conference) in order to > > > > > > manipulate the policy. CPCP can provide its own conference > > > > > > policy ID that is somehow mapped to a conference ID. This > > > > > > depends on the protocol chosen for CPCP. > > > > > > > > > > > > > > > > > > > > 3. There is almost no difference between a = pre-established > > > > > > > conference and an ad-hoc conference. Try and think=20 > > > of something > > > > > > > that matters: > > > > > > > Time between creation of conference ID and=20 > instantiation? > > > > > > > Nope; you can pre-establish a conference=20 > > and use it > > > > > > > immediately, and there can be an arbitrary > > > > > > > delay between > > > > > > > requesting an ad-hoc conference and the=20 > > first dialog > > > > > > > with it. And even if there was, who cares? > > > > > > > > > > > > You are asking to redefine the whole concept of ah-hoc > > > > > > conferencing using SIP. The INVITE creates a conference, = and > > > > > > creates a dialog. > > > > > > > > > > > > > DialIn/DialOut > > > > > > > Nope - both can do both, or a mixture of either > > > > > > > > > > > > How can you limit the dail-in list in an ad-hoc conference. > > > > > > Let me remind you that an ad-hoc conference does not=20 > > > have a policy. > > > > > > > > > > > > For dial-out list, it is true that you can send REFER > > > > > > requests for the focus, but again, you cannot predefine = that > > > > > > list. Also, you have to send a REFER to the focus for each > > > > > > potential participant, creating x number of dialogs, one = for > > > > > > each REFER request. > > > > > > > > > > > > > > > > > > > "Long running conference/chat" Nope; length of=20 > time of a > > > > > > > conference/chat is not relevant, you=20 > > could start one > > > > > > > ad-hoc and leave it run for years. > > > > > > > > > > > > again, with ad-hoc conferences, there is no policy=20 > to dictate > > > > > > this. I think I will stop commenting now until=20 > someone agrues > > > > > > that I am wrong and an ah-hoc conference also needs a = policy > > > > > > (where my reply would be: why is it called ah-hoc then?). > > > > > > > > > > > > Regards, > > > > > > Hisham > > > > > > > > > > > > > Therefore, I think you can't use CPCP for pre-established > > > > > > > conferences and SIP for ad-hoc conferences. Pick one. > > > > > There is no > > > > > > > justification for two mechanisms to do the same=20 > > > thing. I have a > > > > > > > problem with policy creating a conference, and I think = SIP > > > > > > > signalling is a more appropriate way to create a=20 > > > conference, but > > > > > > > I care more about having one and only one way to do it. > > > > > > > > > > > > > > 4. My view of the conference factory was that you=20 > > didn't get a > > > > > > > conference instantiation from it, you only got a=20 > > > conference ID. > > > > > > > Either end would immediately terminate the conference > > > > > > factory dialog, > > > > > > > either by an actual BYE or a REFER. If you wanted to=20 > > > immediately > > > > > > > instantiate the conference after getting the=20 > > > conferenceID, fine, > > > > > > > but you don't have to; you can just get the=20 > > conference ID and > > > > > > > instantiate later. Later could be milliseconds or,=20 > > if policy > > > > > > > allowed, years. > > > > > > > > > > > > > > 5. I agree that non-SIP signalling mechanisms could be > > > > > standardized > > > > > > > to create conferences (H.323, iCal) if there is a SIP way > > > > > > to do it. > > > > > > > There wouldn't be any interoperability issues with that > > > > > like there > > > > > > > would if both CPCP and SIP can do it. Even a single = device > > > > > > that had, > > > > > > > say, both SIP and iCAL mechanisms would have no=20 > > > interoperability > > > > > > > issues with devices that were, say, SIP-only. On the=20 > > > other hand, > > > > > > > if you standardize on CPCP to do it, then you would=20 > > > not expect to > > > > > > > see any other standardized mechanism. > > > > > > > > > > > > > > Brian > > > > > > > > > > > > > > > > > > > > > > > > > >=20 > >=20 > > _______________________________________________ > > XCON mailing list > > XCON@ietf.org > > https://www1.ietf.org/mailman/listinfo/xcon > >=20 >=20 > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon >=20 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Tue Dec 2 14:12:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02751 for ; Tue, 2 Dec 2003 14:12:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARFwK-0002HR-OV for xcon-archive@odin.ietf.org; Tue, 02 Dec 2003 14:12:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB2JC4Fb008758 for xcon-archive@odin.ietf.org; Tue, 2 Dec 2003 14:12:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARFwK-0002HB-E3 for xcon-web-archive@optimus.ietf.org; Tue, 02 Dec 2003 14:12:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02740 for ; Tue, 2 Dec 2003 14:11:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARFwH-0006RU-00 for xcon-web-archive@ietf.org; Tue, 02 Dec 2003 14:12:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARFwH-0006RQ-00 for xcon-web-archive@ietf.org; Tue, 02 Dec 2003 14:12:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARFwH-0002Gd-A0; Tue, 02 Dec 2003 14:12:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARFvm-0002G7-V7 for xcon@optimus.ietf.org; Tue, 02 Dec 2003 14:11:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02716 for ; Tue, 2 Dec 2003 14:11:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARFvj-0006Qr-00 for xcon@ietf.org; Tue, 02 Dec 2003 14:11:27 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1ARFvj-0006Oq-00 for xcon@ietf.org; Tue, 02 Dec 2003 14:11:27 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 02 Dec 2003 11:13:53 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hB2JAqw5027937; Tue, 2 Dec 2003 11:10:52 -0800 (PST) Received: from cisco.com ([161.44.79.239]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AEJ10995; Tue, 2 Dec 2003 14:10:50 -0500 (EST) Message-ID: <3FCCE3B6.3010208@cisco.com> Date: Tue, 02 Dec 2003 14:10:46 -0500 From: Paul Kyzivat 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: "Rosen, Brian" CC: hisham.khartabil@nokia.com, rohan@cisco.com, alan.johnston@mci.com, georg.mayer@nokia.com, oritl@microsoft.com, xcon@ietf.org Subject: Re: [XCON] Chicken and Egg - Can CPCP create a conference References: <313680C9A886D511A06000204840E1CF070B6154@whq-msgusr-02.pit.comms.marconi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Rosen, Brian wrote: > We need a consistent definition of "instantiation" or we need to not > use the term in the documents. > > I think we are still just having a semantic discussion, and not > arguing over much substance. I think we all agree that once you > have a conference ID, you can do things with it: > You can use it to change policy > You can INVITE yourself to it > You can REFER someone to it > > Depending on the policy in force at the time, an INVITE or REFER > may not be accepted, and that could be because of the time, or who > you are, or what your SDP offer is. All of those are conference > or media policy decisions, and nothing else. Agree. > I can argue your objections to my definition of "instantiate" or > you can propose another definition on instantiation, or > propose that we eliminate the word from our documents. I don't think the term is needed for describing when resources are assigned - it is entirely an implementation issue. It may be useful to have a term for the state when sip operations on the conference ID (focus uri) by suitably authorized parties can be expected to work. But that may not be an all or nothing thing. Paul > Brian > > >>-----Original Message----- >>From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>Sent: Tuesday, December 02, 2003 11:15 AM >>To: hisham.khartabil@nokia.com >>Cc: Brian.Rosen@marconi.com; rohan@cisco.com; alan.johnston@mci.com; >>georg.mayer@nokia.com; oritl@microsoft.com; xcon@ietf.org >>Subject: Re: [XCON] Chicken and Egg - Can CPCP create a conference >> >> >> >> >>hisham.khartabil@nokia.com wrote: >> >>>>Several points to make. In my view: >>>>1. "Instantiating" a conference is a concept that is getting >>>>confusing. >>>>It's all in what you mean. I think it's when the mixer resources >>>>are actually allocated (as opposed to reserved). That starts when >>>>the first participant creates a dialog with the focus, and ends >>>>when the last dialog terminates. Getting a conference ID doesn't >>>>instantiate a conference, creating a dialog with it does. >>> >>>Some chat type conferences can exist without any participants. >> >> > Participants come and go as they please. Why is there a requirement >> > that at least one participant is needed for the conference >>to ever exist? >> >>I agree. Defining the conference by the allocation of mixer resources >>seems wrong to me. That is very implementation specific - I >>might choose >>to allocate mixer resources differently than Brian does. In >>case of chat >>conferences where mixing is trivial, there may not be any explicitly >>allocated mixing resources at all. >> >>IMO a conference is defined by a valid address. So as long as the sip >>address constituting the conference ID, which names a unique >>focus, is >>valid, it *is* a conference. The only real question is what >>state that >>conference is in. If the conference isn't scheduled to start >>yet, then I >>would hope that a request directed to it would yield some meaningful >>error - perhaps 480 Temporarily Unavailable, giving the time until it >>will be available. If a request is directed to it after >>policy says it >>should have expired, then a 404 Not Found error would be appropriate. >> >> >>>You are asking to redefine the whole concept of ah-hoc conferencing >> >> > using SIP. The INVITE creates a conference, and creates a dialog. >>... >> > again, with ad-hoc conferences, there is no policy to dictate this. >> > I think I will stop commenting now until someone agrues that I am >> > wrong and an ah-hoc conference also needs a policy (where my reply >> > would be: why is it called ah-hoc then?). >> >>I have to disagree with you and agree with Brian here. >>I don't think it makes sense to say a conference has no policy. >>It may be that you can neither query nor manipulate the policy, but >>conceptually it still has a policy. Fancier conferencing >>products would >>hopefully provide the ability to query and manipulate policy >>on ad hoc >>conferences. >> >>I think the only real difference is that if you create an ad hoc >>conference by sending an invitation to a conference factory, >>you get a >>conference with some *default* policy determined by the >>factory in its >>infinite wisdom. >> >> Paul >> >> >>_______________________________________________ >>XCON mailing list >>XCON@ietf.org >>https://www1.ietf.org/mailman/listinfo/xcon >> > > _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Tue Dec 2 14:23:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03253 for ; Tue, 2 Dec 2003 14:23:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARG6y-0002rU-JU for xcon-archive@odin.ietf.org; Tue, 02 Dec 2003 14:23:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB2JN4LT010994 for xcon-archive@odin.ietf.org; Tue, 2 Dec 2003 14:23:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARG6y-0002rF-DI for xcon-web-archive@optimus.ietf.org; Tue, 02 Dec 2003 14:23:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03234 for ; Tue, 2 Dec 2003 14:22:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARG6s-0006c2-00 for xcon-web-archive@ietf.org; Tue, 02 Dec 2003 14:22:58 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARG6s-0006bz-00 for xcon-web-archive@ietf.org; Tue, 02 Dec 2003 14:22:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARG6u-0002pl-2T; Tue, 02 Dec 2003 14:23:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARG6t-0002pa-Bw for xcon@optimus.ietf.org; Tue, 02 Dec 2003 14:22:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03227 for ; Tue, 2 Dec 2003 14:22:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARG6q-0006bt-00 for xcon@ietf.org; Tue, 02 Dec 2003 14:22:56 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1ARG6q-0006bd-00 for xcon@ietf.org; Tue, 02 Dec 2003 14:22:56 -0500 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hB2JMIxg018935; Tue, 2 Dec 2003 14:22:18 -0500 (EST) Received: from cisco.com ([161.44.79.239]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AEJ12231; Tue, 2 Dec 2003 14:22:16 -0500 (EST) Message-ID: <3FCCE668.1060601@cisco.com> Date: Tue, 02 Dec 2003 14:22:16 -0500 From: Paul Kyzivat 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: "Rosen, Brian" CC: "'Heil Franca Marcelo'" , "'Alan Johnston'" , hisham.khartabil@nokia.com, rohan@cisco.com, georg.mayer@nokia.com, oritl@microsoft.com, xcon@ietf.org Subject: Re: [XCON] Chicken and Egg - Can CPCP create a conference References: <313680C9A886D511A06000204840E1CF070B6156@whq-msgusr-02.pit.comms.marconi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Rosen, Brian wrote: > Well, now you might see why I think the Conference Factory URI > does not instantiate a conference; it just returns a conference ID. > That way, you could, if you wanted to, change the default policy > before you "started" it. It is my understanding that the Conference Factory URI is used by sending an INVITE to it. So how is it supposed to return a conference ID without also "starting" the conference? Typically the result of the INVITE will be a dialog with the focus, with the address of the focus being returned as the Contact. Or are you assuming that Conference Factory URI will *always* return a 3xx rather than establishing the dialog? I would hate to write an application for creating/configuring a conference that sends and INVITE but depends on it not succeeding - so that if it is surprised by having the INVITE succeed it barfs. I think sending an invite to a Conference Factory URI should only be used when the UAC wants to participate in a new conference that starts *now*. If you want to establish a name and policy for a conference to take place later, then I think you must use other means. Paul _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Tue Dec 2 14:45:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04364 for ; Tue, 2 Dec 2003 14:45:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARGSG-00048B-Bl for xcon-archive@odin.ietf.org; Tue, 02 Dec 2003 14:45:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB2Jj4x8015873 for xcon-archive@odin.ietf.org; Tue, 2 Dec 2003 14:45:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARGSG-00047w-3n for xcon-web-archive@optimus.ietf.org; Tue, 02 Dec 2003 14:45:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04346 for ; Tue, 2 Dec 2003 14:44:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARGSD-0006y1-00 for xcon-web-archive@ietf.org; Tue, 02 Dec 2003 14:45:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARGSC-0006xy-00 for xcon-web-archive@ietf.org; Tue, 02 Dec 2003 14:45:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARGSE-00047D-Q3; Tue, 02 Dec 2003 14:45:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARGS0-00046i-CI for xcon@optimus.ietf.org; Tue, 02 Dec 2003 14:44:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04332 for ; Tue, 2 Dec 2003 14:44:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARGRx-0006xh-00 for xcon@ietf.org; Tue, 02 Dec 2003 14:44:45 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1ARGRx-0006xF-00 for xcon@ietf.org; Tue, 02 Dec 2003 14:44:45 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 02 Dec 2003 11:47:12 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hB2Ji8w7010169; Tue, 2 Dec 2003 11:44:11 -0800 (PST) Received: from cisco.com ([161.44.79.239]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AEJ14590; Tue, 2 Dec 2003 14:44:07 -0500 (EST) Message-ID: <3FCCEB87.3050404@cisco.com> Date: Tue, 02 Dec 2003 14:44:07 -0500 From: Paul Kyzivat 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: "Rosen, Brian" CC: "'hisham.khartabil@nokia.com'" , rohan@cisco.com, alan.johnston@mci.com, georg.mayer@nokia.com, oritl@microsoft.com, xcon@ietf.org Subject: Re: [XCON] Chicken and Egg - Can CPCP create a conference References: <313680C9A886D511A06000204840E1CF070B6151@whq-msgusr-02.pit.comms.marconi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Rosen, Brian wrote: >> >>If you look at XCAP list usage for example, you will see that >>the list-URI used when sending SIP SUBSCRIBE requests to the >>list is not the same as the URI used to manipulate the list >>using XCAP. They certainly need to be linked, but not >>necessarily the same. >> >>Depending on the protocol we chose, a SIP URI can or cannot >>be used to identify a conference policy. > > I think we CAN always have the same ID. > I think there is a lot of value in one ID > I don't think there is any problem in having one ID > > So, I think there should be one. > > If there is a good reason, we can burden the conference policy server > with keeping the relationship, but unless there is a good reason, history > suggests that one namespace is better than two with linkage. [The chicken and the egg are different things. If I want to talk to the egg I need the address of the egg - having the address of the chicken isn't sufficient. Its probably a bad idea to crack the egg in order to ask the chicken for the address of the egg.] Getting away from metaphors, this seems to be coming down to the distinction between URIs and URLs. A sip address is a URL in that it is sufficient for me to locate a corresponding (sip) resource. But it isn't sufficient for me to locate a CPCP resource. If I knew how to contact the appropriate CPCP server, perhaps a sip uri could serve to identify the policy. But that would require me to know the address of the server a-priori. If all I have is the sip conference id, then to derive the URI for the policy from it I must invoke sip operations on it. Paul _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Wed Dec 3 03:04:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05139 for ; Wed, 3 Dec 2003 03:04:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARRzS-0007HM-4f for xcon-archive@odin.ietf.org; Wed, 03 Dec 2003 03:04:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB3846A8027980 for xcon-archive@odin.ietf.org; Wed, 3 Dec 2003 03:04:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARRzR-0007HD-Mw for xcon-web-archive@optimus.ietf.org; Wed, 03 Dec 2003 03:04:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05123 for ; Wed, 3 Dec 2003 03:03:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARRzN-00042Z-00 for xcon-web-archive@ietf.org; Wed, 03 Dec 2003 03:04:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARRzN-00042W-00 for xcon-web-archive@ietf.org; Wed, 03 Dec 2003 03:04:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARRzO-0007GA-7h; Wed, 03 Dec 2003 03:04:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARRye-0007Ck-Ht for xcon@optimus.ietf.org; Wed, 03 Dec 2003 03:03:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04917 for ; Wed, 3 Dec 2003 03:02:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARRya-0003wG-00 for xcon@ietf.org; Wed, 03 Dec 2003 03:03:12 -0500 Received: from thoth.sbs.de ([192.35.17.2]) by ietf-mx with esmtp (Exim 4.12) id 1ARRyZ-0003vz-00 for xcon@ietf.org; Wed, 03 Dec 2003 03:03:11 -0500 Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by thoth.sbs.de (8.11.7/8.11.7) with ESMTP id hB382s220497; Wed, 3 Dec 2003 09:02:54 +0100 (MET) Received: from blues.mchh.siemens.de (blues.mchh.siemens.de [139.21.204.206]) by mail1.siemens.de (8.11.7/8.11.7) with ESMTP id hB382oL16749; Wed, 3 Dec 2003 09:02:50 +0100 (MET) Received: from mchh274e.mchh.siemens.de (mchh274e.mchh.siemens.de [139.21.200.84]) by blues.mchh.siemens.de (8.9.3/8.9.1) with ESMTP id JAA22908; Wed, 3 Dec 2003 09:02:45 +0100 (MET) Received: by mchh274e.mchh.siemens.de with Internet Mail Service (5.5.2656.59) id ; Wed, 3 Dec 2003 09:02:48 +0100 Message-ID: <76592C4D3DA1AC4FB8424084D10D31A8D5CE6B@mchh2c4e.mchh.siemens.de> From: Heil Franca Marcelo To: "'Paul Kyzivat'" , "Rosen, Brian" Cc: Heil Franca Marcelo , "'Alan Johnston'" , hisham.khartabil@nokia.com, rohan@cisco.com, georg.mayer@nokia.com, oritl@microsoft.com, xcon@ietf.org Subject: AW: [XCON] Chicken and Egg - Can CPCP create a conference Date: Wed, 3 Dec 2003 09:02:43 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > -----Urspr=FCngliche Nachricht----- > Von: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > Gesendet: Dienstag, 2. Dezember 2003 20:22 > An: Rosen, Brian > Cc: 'Heil Franca Marcelo'; 'Alan Johnston';=20 > hisham.khartabil@nokia.com; rohan@cisco.com;=20 > georg.mayer@nokia.com; oritl@microsoft.com; xcon@ietf.org > Betreff: Re: [XCON] Chicken and Egg - Can CPCP create a conference >=20 >=20 >=20 >=20 > Rosen, Brian wrote: > > Well, now you might see why I think the Conference Factory URI > > does not instantiate a conference; it just returns a conference ID. > > That way, you could, if you wanted to, change the default policy > > before you "started" it. >=20 > It is my understanding that the Conference Factory URI is used by=20 > sending an INVITE to it. So how is it supposed to return a=20 > conference ID=20 > without also "starting" the conference? Typically the result of the=20 > INVITE will be a dialog with the focus, with the address of the focus = > being returned as the Contact. Or are you assuming that Conference=20 > Factory URI will *always* return a 3xx rather than=20 > establishing the dialog? >=20 > I would hate to write an application for creating/configuring a=20 > conference that sends and INVITE but depends on it not=20 > succeeding - so=20 > that if it is surprised by having the INVITE succeed it barfs. >=20 > I think sending an invite to a Conference Factory URI should only be=20 > used when the UAC wants to participate in a new conference=20 > that starts=20 > *now*. >=20 > If you want to establish a name and policy for a conference to take=20 > place later, then I think you must use other means. >=20 > Paul >=20 Exactly, and the other mean could be to use CPCP. Marcelo _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Wed Dec 3 03:50:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06379 for ; Wed, 3 Dec 2003 03:50:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARShx-0000yE-Uv for xcon-archive@odin.ietf.org; Wed, 03 Dec 2003 03:50:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB38o5H1003722 for xcon-archive@odin.ietf.org; Wed, 3 Dec 2003 03:50:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARShx-0000xw-5C for xcon-web-archive@optimus.ietf.org; Wed, 03 Dec 2003 03:50:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06368 for ; Wed, 3 Dec 2003 03:49:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARShu-0004Yk-00 for xcon-web-archive@ietf.org; Wed, 03 Dec 2003 03:50:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARShu-0004Yh-00 for xcon-web-archive@ietf.org; Wed, 03 Dec 2003 03:50:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARSht-0000xM-DG; Wed, 03 Dec 2003 03:50:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARShI-0000uB-7A for xcon@optimus.ietf.org; Wed, 03 Dec 2003 03:49:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06320 for ; Wed, 3 Dec 2003 03:49:08 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARShF-0004YJ-00 for xcon@ietf.org; Wed, 03 Dec 2003 03:49:21 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1ARShE-0004YG-00 for xcon@ietf.org; Wed, 03 Dec 2003 03:49:21 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hB38nLQ10779 for ; Wed, 3 Dec 2003 10:49:21 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 3 Dec 2003 10:49:20 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 3 Dec 2003 10:49:20 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] Chicken and Egg - Can CPCP create a conference Date: Wed, 3 Dec 2003 10:49:19 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB70118B119@esebe019.ntc.nokia.com> Thread-Topic: [XCON] Chicken and Egg - Can CPCP create a conference Thread-Index: AcO47NUxdz85Luo3TVu25Pvn89G7qAAi965w To: , , , Cc: , , X-OriginalArrivalTime: 03 Dec 2003 08:49:20.0093 (UTC) FILETIME=[5774D8D0:01C3B97A] Content-Transfer-Encoding: quoted-printable Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ext Alan Johnston [mailto:alan.johnston@mci.com] > Sent: 02.December.2003 17:52 > To: Khartabil Hisham (NMP-MSW/Helsinki); Brian.Rosen@marconi.com; > rohan@cisco.com; pkyzivat@cisco.com > Cc: Mayer Georg (NMP-MSW/Helsinki); oritl@microsoft.com; xcon@ietf.org > Subject: RE: [XCON] Chicken and Egg - Can CPCP create a conference >=20 >=20 > > > >I don't understand why the ID for the conference needs to be=20 > the same as=20 > >the ID for the conference policy. >=20 > I agree with Brian here. The conference identifier is the=20 > URI. It is the=20 > means by which a participant joins the conference and depends on the=20 > signaling protocol (SIP, H.323, PSTN, etc.). It can't just=20 > be some random=20 > string. This is a fundamental idea in the framework. >=20 > >If you look at XCAP list usage for example, you will see=20 > that the list-URI=20 > >used when sending SIP SUBSCRIBE requests to the list is not=20 > the same as=20 > >the URI used to manipulate the list using XCAP. They=20 > certainly need to be=20 > >linked, but not necessarily the same. >=20 > I don't understand what you are saying. The policy URI and=20 > the conference=20 > URI can not be the same since they are different protocols, right? That is what I said. First you agree with Brian that a conference and = conference policy need to be identified with the same ID, then you agree = with me here that policy URI and conference URI can be different because = of the differing protocols. >=20 >=20 > >Depending on the protocol we chose, a SIP URI can or cannot=20 > be used to=20 > >identify a conference policy. >=20 > Knowing only the conference URI, it must be possible to determine the=20 > conference policy URI. So, you agree that they can be different? Who needs to make such determination? Quite often with pre-extablished conferences, the user learns the policy = URI before the conference URI. >=20 >=20 > > > > > > 2. You think ad-hoc conferences don't have policy. I am > > > fundamentally > > > opposed to that. Ad-hoc conferences should have all of the > > > functionality of a pre-established conference and I can't=20 > imagine any > > > reason why we can't provide that. > > > >If we replicate everything that a scheduled conference can=20 > have to ad-hoc=20 > >conferences, then we don't need scheduled conferences at=20 > all. Perhaps we=20 > >need to define the scope of an ad-hoc conference. To me an=20 > ad-hoc is just=20 > >that; a conference created instantaneously for discussing an=20 > urgent matter=20 > >or whatever. You REFER other participants and it terminated=20 > as soon as the=20 > >last participant leaves. There are no start and stop times,=20 > there are no=20 > >dial-out and dial-in lists configured, there is no general=20 > conference=20 > >info, and there are no media policies. >=20 > I agree 100% with Brian. An ad-hoc conference does have=20 > policy, but it is=20 > a default (non-unique) policy. The creator of the conference=20 > factory URI=20 > sets that policy. =20 No arguments here. > It is possible for this policy to be=20 > manipulated once=20 > the conference has begun, but again this is up to the application. Are you saying that the user needs to be able to manipulate the policy? Regards, Hisham _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Wed Dec 3 03:59:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06765 for ; Wed, 3 Dec 2003 03:59:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARSqf-0001iw-8A for xcon-archive@odin.ietf.org; Wed, 03 Dec 2003 03:59:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB38x5dh006620 for xcon-archive@odin.ietf.org; Wed, 3 Dec 2003 03:59:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARSqe-0001ih-RE for xcon-web-archive@optimus.ietf.org; Wed, 03 Dec 2003 03:59:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06750 for ; Wed, 3 Dec 2003 03:58:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARSqb-0004iU-00 for xcon-web-archive@ietf.org; Wed, 03 Dec 2003 03:59:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARSqa-0004iR-00 for xcon-web-archive@ietf.org; Wed, 03 Dec 2003 03:59:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARSqc-0001h7-55; Wed, 03 Dec 2003 03:59:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARSqR-0001gN-83 for xcon@optimus.ietf.org; Wed, 03 Dec 2003 03:58:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06735 for ; Wed, 3 Dec 2003 03:58:35 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARSqO-0004i0-00 for xcon@ietf.org; Wed, 03 Dec 2003 03:58:48 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1ARSqO-0004hx-00 for xcon@ietf.org; Wed, 03 Dec 2003 03:58:48 -0500 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hB38wmN18687 for ; Wed, 3 Dec 2003 10:58:48 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 3 Dec 2003 10:58:48 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 3 Dec 2003 10:58:47 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] Chicken and Egg - Can CPCP create a conference Date: Wed, 3 Dec 2003 10:58:46 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB70179747A@esebe019.ntc.nokia.com> Thread-Topic: [XCON] Chicken and Egg - Can CPCP create a conference Thread-Index: AcO472/j1/sYzTzVRTejsIvczm0IvgAi/40Q To: Cc: , , , , , X-OriginalArrivalTime: 03 Dec 2003 08:58:47.0562 (UTC) FILETIME=[A9B1BEA0:01C3B97B] Content-Transfer-Encoding: quoted-printable Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: 02.December.2003 18:15 > To: Khartabil Hisham (NMP-MSW/Helsinki) > Cc: Brian.Rosen@marconi.com; rohan@cisco.com; alan.johnston@mci.com; > Mayer Georg (NMP-MSW/Helsinki); oritl@microsoft.com; xcon@ietf.org > Subject: Re: [XCON] Chicken and Egg - Can CPCP create a conference >=20 >=20 >=20 >=20 > hisham.khartabil@nokia.com wrote: > >=20 > >>Several points to make. In my view: > >>1. "Instantiating" a conference is a concept that is getting=20 > >>confusing. > >>It's all in what you mean. I think it's when the mixer resources > >>are actually allocated (as opposed to reserved). That starts when > >>the first participant creates a dialog with the focus, and ends > >>when the last dialog terminates. Getting a conference ID doesn't > >>instantiate a conference, creating a dialog with it does. > >=20 > > Some chat type conferences can exist without any participants. > > Participants come and go as they please. Why is there a requirement > > that at least one participant is needed for the conference=20 > to ever exist? >=20 > I agree. Defining the conference by the allocation of mixer resources=20 > seems wrong to me. That is very implementation specific - I=20 > might choose=20 > to allocate mixer resources differently than Brian does. In=20 > case of chat=20 > conferences where mixing is trivial, there may not be any explicitly=20 > allocated mixing resources at all. >=20 > IMO a conference is defined by a valid address. So as long as the sip=20 > address constituting the conference ID, which names a unique=20 > focus, is=20 > valid, it *is* a conference. The only real question is what=20 > state that=20 > conference is in. If the conference isn't scheduled to start=20 > yet, then I=20 > would hope that a request directed to it would yield some meaningful=20 > error - perhaps 480 Temporarily Unavailable, giving the time until it=20 > will be available. If a request is directed to it after=20 > policy says it=20 > should have expired, then a 404 Not Found error would be appropriate. >=20 > > You are asking to redefine the whole concept of ah-hoc conferencing > > using SIP. The INVITE creates a conference, and creates a dialog. > ... > > again, with ad-hoc conferences, there is no policy to dictate this. > > I think I will stop commenting now until someone agrues that I am > > wrong and an ah-hoc conference also needs a policy (where my reply > > would be: why is it called ah-hoc then?). >=20 > I have to disagree with you and agree with Brian here. > I don't think it makes sense to say a conference has no policy. > It may be that you can neither query nor manipulate the policy, but=20 > conceptually it still has a policy. Fancier conferencing=20 > products would=20 > hopefully provide the ability to query and manipulate policy=20 > on ad hoc=20 > conferences. >=20 > I think the only real difference is that if you create an ad hoc=20 > conference by sending an invitation to a conference factory,=20 > you get a=20 > conference with some *default* policy determined by the=20 > factory in its=20 > infinite wisdom. I completely agree here. I was arguing that for an ad-hoc conference, = there is no need to manipulate that policy. If a user wants to have that = much control, then they should use CPCP to create a conference, not = using ah-hoc means. /Hisham >=20 > Paul >=20 >=20 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Wed Dec 3 04:06:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06883 for ; Wed, 3 Dec 2003 04:06:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARSxU-00021W-8D for xcon-archive@odin.ietf.org; Wed, 03 Dec 2003 04:06:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB3968Hx007779 for xcon-archive@odin.ietf.org; Wed, 3 Dec 2003 04:06:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARSxT-00021O-Ht for xcon-web-archive@optimus.ietf.org; Wed, 03 Dec 2003 04:06:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06880 for ; Wed, 3 Dec 2003 04:05:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARSxQ-0004mQ-00 for xcon-web-archive@ietf.org; Wed, 03 Dec 2003 04:06:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARSxQ-0004mN-00 for xcon-web-archive@ietf.org; Wed, 03 Dec 2003 04:06:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARSxP-000217-U5; Wed, 03 Dec 2003 04:06:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARSwk-00020F-67 for xcon@optimus.ietf.org; Wed, 03 Dec 2003 04:05:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06877 for ; Wed, 3 Dec 2003 04:05:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARSwh-0004mC-00 for xcon@ietf.org; Wed, 03 Dec 2003 04:05:19 -0500 Received: from mail49.messagelabs.com ([193.109.255.19]) by ietf-mx with smtp (Exim 4.12) id 1ARSwg-0004lr-00 for xcon@ietf.org; Wed, 03 Dec 2003 04:05:18 -0500 X-VirusChecked: Checked X-Env-Sender: cboulton@ubiquity.net X-Msg-Ref: server-17.tower-49.messagelabs.com!1070442287!542040 X-StarScan-Version: 5.1.13; banners=ubiquity.net,-,- Received: (qmail 21883 invoked from network); 3 Dec 2003 09:04:47 -0000 Received: from news.ubiquity.net (HELO gbnewp0186s1.eu.ubiquity.net) (194.202.146.92) by server-17.tower-49.messagelabs.com with SMTP; 3 Dec 2003 09:04:47 -0000 Received: from mailhost.eu.ubiquity.net by gbnewp0186s1.eu.ubiquity.net via smtpd (for mail49.messagelabs.com [193.109.255.19]) with SMTP; Wed, 3 Dec 2003 09:07:20 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] Chicken and Egg - Can CPCP create a conference Date: Wed, 3 Dec 2003 09:04:02 -0000 Message-ID: <45730E094814E44488F789C1CDED27AE01E22EF1@gbnewp0758m.eu.ubiquity.net> Thread-Topic: [XCON] Chicken and Egg - Can CPCP create a conference Thread-Index: AcO472/j1/sYzTzVRTejsIvczm0IvgAi/40QAAAiUnA= From: "Chris Boulton" To: , Cc: , , , , , Content-Transfer-Encoding: quoted-printable Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable <> >-----Original=20Message-----=20 >From:=20hisham.khartabil@nokia.com=20[mailto:hisham.khartabil@nokia.com] >Sent:=2003=20December=202003=2008:59 >To:=20pkyzivat@cisco.com >Cc:=20Brian.Rosen@marconi.com;=20rohan@cisco.com;=20alan.johnston@mci.com= ; >georg.mayer@nokia.com;=20oritl@microsoft.com;=20xcon@ietf.org >Subject:=20RE:=20[XCON]=20Chicken=20and=20Egg=20-=20Can=20CPCP=20create=20= a=20conference > > > >>=20-----Original=20Message----- >>=20From:=20ext=20Paul=20Kyzivat=20[mailto:pkyzivat@cisco.com] >>=20Sent:=2002.December.2003=2018:15 >>=20To:=20Khartabil=20Hisham=20(NMP-MSW/Helsinki) >>=20Cc:=20Brian.Rosen@marconi.com;=20rohan@cisco.com;=20alan.johnston@mci= .com; >>=20Mayer=20Georg=20(NMP-MSW/Helsinki);=20oritl@microsoft.com;=20xcon@iet= f.org >>=20Subject:=20Re:=20[XCON]=20Chicken=20and=20Egg=20-=20Can=20CPCP=20crea= te=20a=20conference >> >> >> >> >>=20hisham.khartabil@nokia.com=20wrote: >>=20> >>=20>>Several=20points=20to=20make.=20=20In=20my=20view: >>=20>>1.=20"Instantiating"=20a=20conference=20is=20a=20concept=20that=20i= s=20getting >>=20>>confusing. >>=20>>It's=20all=20in=20what=20you=20mean.=20=20I=20think=20it's=20when=20= the=20mixer=20resources >>=20>>are=20actually=20allocated=20(as=20opposed=20to=20reserved).=20=20T= hat=20starts=20when >>=20>>the=20first=20participant=20creates=20a=20dialog=20with=20the=20foc= us,=20and=20ends >>=20>>when=20the=20last=20dialog=20terminates.=20=20Getting=20a=20confere= nce=20ID=20doesn't >>=20>>instantiate=20a=20conference,=20creating=20a=20dialog=20with=20it=20= does. >>=20> >>=20>=20Some=20chat=20type=20conferences=20can=20exist=20without=20any=20= participants. >>=20=20>=20Participants=20come=20and=20go=20as=20they=20please.=20Why=20i= s=20there=20a requirement >>=20=20>=20that=20at=20least=20one=20participant=20is=20needed=20for=20th= e=20conference >>=20to=20ever=20exist? >> >>=20I=20agree.=20Defining=20the=20conference=20by=20the=20allocation=20of= =20mixer=20resources >>=20seems=20wrong=20to=20me.=20That=20is=20very=20implementation=20specif= ic=20-=20I >>=20might=20choose >>=20to=20allocate=20mixer=20resources=20differently=20than=20Brian=20does= .=20In >>=20case=20of=20chat >>=20conferences=20where=20mixing=20is=20trivial,=20there=20may=20not=20be= =20any=20explicitly >>=20allocated=20mixing=20resources=20at=20all. >> >>=20IMO=20a=20conference=20is=20defined=20by=20a=20valid=20address.=20So=20= as=20long=20as=20the=20sip >>=20address=20constituting=20the=20conference=20ID,=20which=20names=20a=20= unique >>=20focus,=20is >>=20valid,=20it=20*is*=20a=20conference.=20The=20only=20real=20question=20= is=20what >>=20state=20that >>=20conference=20is=20in.=20If=20the=20conference=20isn't=20scheduled=20t= o=20start >>=20yet,=20then=20I >>=20would=20hope=20that=20a=20request=20directed=20to=20it=20would=20yiel= d=20some=20meaningful >>=20error=20-=20perhaps=20480=20Temporarily=20Unavailable,=20giving=20the= =20time=20until=20it >>=20will=20be=20available.=20If=20a=20request=20is=20directed=20to=20it=20= after >>=20policy=20says=20it >>=20should=20have=20expired,=20then=20a=20404=20Not=20Found=20error=20wou= ld=20be=20appropriate. >> >>=20>=20You=20are=20asking=20to=20redefine=20the=20whole=20concept=20of=20= ah-hoc=20conferencing >>=20=20>=20using=20SIP.=20The=20INVITE=20creates=20a=20conference,=20and=20= creates=20a=20dialog. >>=20... >>=20=20>=20again,=20with=20ad-hoc=20conferences,=20there=20is=20no=20poli= cy=20to=20dictate this. >>=20=20>=20I=20think=20I=20will=20stop=20commenting=20now=20until=20someo= ne=20agrues=20that=20I=20am >>=20=20>=20wrong=20and=20an=20ah-hoc=20conference=20also=20needs=20a=20po= licy=20(where=20my=20reply >>=20=20>=20would=20be:=20why=20is=20it=20called=20ah-hoc=20then?). >> >>=20I=20have=20to=20disagree=20with=20you=20and=20agree=20with=20Brian=20= here. >>=20I=20don't=20think=20it=20makes=20sense=20to=20say=20a=20conference=20= has=20no=20policy. >>=20It=20may=20be=20that=20you=20can=20neither=20query=20nor=20manipulate= =20the=20policy,=20but >>=20conceptually=20it=20still=20has=20a=20policy.=20Fancier=20conferencin= g >>=20products=20would >>=20hopefully=20provide=20the=20ability=20to=20query=20and=20manipulate=20= policy >>=20on=20ad=20hoc >>=20conferences. >> >>=20I=20think=20the=20only=20real=20difference=20is=20that=20if=20you=20c= reate=20an=20ad=20hoc >>=20conference=20by=20sending=20an=20invitation=20to=20a=20conference=20f= actory, >>=20you=20get=20a >>=20conference=20with=20some=20*default*=20policy=20determined=20by=20the= >>=20factory=20in=20its >>=20infinite=20wisdom. > >I=20completely=20agree=20here.=20I=20was=20arguing=20that=20for=20an=20ad= -hoc=20conference, there >is=20no=20need=20to=20manipulate=20that=20policy.=20If=20a=20user=20wants= =20to=20have=20that=20much >control,=20then=20they=20should=20use=20CPCP=20to=20create=20a=20conferen= ce,=20not=20using ah-hoc >means. > >/Hisham [Chris=20Boulton]=20Once=20a=20conference=20instance=20has=20started=20-=20= should=20it matter=20HOW=20the=20conference=20was=20started.=20=20We=20have=20a=20conf= erence=20instance, we=20have=20CPCP,=20why=20restrict=20a=20user=20just=20because=20it=20was=20= started=20in=20an ad-hoc=20fashion. Chris. > >> >>=20=09Paul >> >> > >_______________________________________________ >XCON=20mailing=20list >XCON@ietf.org >https://www1.ietf.org/mailman/listinfo/xcon > >_______________________________________________________________________ _ >This=20email=20has=20been=20scanned=20for=20all=20viruses=20by=20the=20Me= ssageLabs=20Email >Security=20System.=20For=20more=20information=20on=20a=20proactive=20emai= l=20security >service=20working=20around=20the=20clock,=20around=20the=20globe,=20visit= >http://www.messagelabs.com >_______________________________________________________________________ _ ________________________________________________________________________ This=20email=20has=20been=20scanned=20for=20all=20viruses=20by=20the=20Mes= sageLabs=20Email Security=20System.=20For=20more=20information=20on=20a=20proactive=20email= =20security service=20working=20around=20the=20clock,=20around=20the=20globe,=20visit http://www.messagelabs.com ________________________________________________________________________ _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Wed Dec 3 05:46:17 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08897 for ; Wed, 3 Dec 2003 05:46:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARUWB-0005do-VY for xcon-archive@odin.ietf.org; Wed, 03 Dec 2003 05:46:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB3Ak3Au021680 for xcon-archive@odin.ietf.org; Wed, 3 Dec 2003 05:46:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARUWB-0005db-Ox for xcon-web-archive@optimus.ietf.org; Wed, 03 Dec 2003 05:46:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08887 for ; Wed, 3 Dec 2003 05:45:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARUW8-0005kN-00 for xcon-web-archive@ietf.org; Wed, 03 Dec 2003 05:46:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARUW7-0005kK-00 for xcon-web-archive@ietf.org; Wed, 03 Dec 2003 05:45:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARUWA-0005d9-3G; Wed, 03 Dec 2003 05:46:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARUW8-0005cw-29 for xcon@optimus.ietf.org; Wed, 03 Dec 2003 05:46:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08884 for ; Wed, 3 Dec 2003 05:45:43 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARUW4-0005kH-00 for xcon@ietf.org; Wed, 03 Dec 2003 05:45:56 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1ARUW3-0005kE-00 for xcon@ietf.org; Wed, 03 Dec 2003 05:45:55 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hB3AjuN12606 for ; Wed, 3 Dec 2003 12:45:56 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 3 Dec 2003 11:05:32 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 3 Dec 2003 11:05:27 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] Chicken and Egg - Can CPCP create a conference Date: Wed, 3 Dec 2003 11:05:27 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB70179747B@esebe019.ntc.nokia.com> Thread-Topic: [XCON] Chicken and Egg - Can CPCP create a conference Thread-Index: AcO5CZ5eKwJmBjoQTuen0g+IujPF5gAcuk0w To: , Cc: , , , , , X-OriginalArrivalTime: 03 Dec 2003 09:05:27.0744 (UTC) FILETIME=[9838AC00:01C3B97C] Content-Transfer-Encoding: quoted-printable Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: 02.December.2003 21:22 > To: Rosen, Brian > Cc: 'Heil Franca Marcelo'; 'Alan Johnston'; Khartabil Hisham > (NMP-MSW/Helsinki); rohan@cisco.com; Mayer Georg (NMP-MSW/Helsinki); > oritl@microsoft.com; xcon@ietf.org > Subject: Re: [XCON] Chicken and Egg - Can CPCP create a conference >=20 >=20 >=20 >=20 > Rosen, Brian wrote: > > Well, now you might see why I think the Conference Factory URI > > does not instantiate a conference; it just returns a conference ID. > > That way, you could, if you wanted to, change the default policy > > before you "started" it. >=20 > It is my understanding that the Conference Factory URI is used by=20 > sending an INVITE to it. So how is it supposed to return a=20 > conference ID=20 > without also "starting" the conference? Typically the result of the=20 > INVITE will be a dialog with the focus, with the address of the focus=20 > being returned as the Contact. Or are you assuming that Conference=20 > Factory URI will *always* return a 3xx rather than=20 > establishing the dialog? >=20 > I would hate to write an application for creating/configuring a=20 > conference that sends and INVITE but depends on it not=20 > succeeding - so=20 > that if it is surprised by having the INVITE succeed it barfs. >=20 > I think sending an invite to a Conference Factory URI should only be=20 > used when the UAC wants to participate in a new conference=20 > that starts=20 > *now*. >=20 > If you want to establish a name and policy for a conference to take=20 > place later, then I think you must use other means. Yes, this has been my point all along. /Hisham >=20 > Paul >=20 >=20 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Wed Dec 3 07:59:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13382 for ; Wed, 3 Dec 2003 07:59:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARWat-0003gf-Gq for xcon-archive@odin.ietf.org; Wed, 03 Dec 2003 07:59:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB3Cx3Bu014167 for xcon-archive@odin.ietf.org; Wed, 3 Dec 2003 07:59:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARWat-0003gQ-9u for xcon-web-archive@optimus.ietf.org; Wed, 03 Dec 2003 07:59:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13358 for ; Wed, 3 Dec 2003 07:58:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARWas-00002I-00 for xcon-web-archive@ietf.org; Wed, 03 Dec 2003 07:59:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARWas-00002F-00 for xcon-web-archive@ietf.org; Wed, 03 Dec 2003 07:59:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARWar-0003g9-9r; Wed, 03 Dec 2003 07:59:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARWaD-0003fB-8h for xcon@optimus.ietf.org; Wed, 03 Dec 2003 07:58:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13320 for ; Wed, 3 Dec 2003 07:58:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARWaC-00001N-00 for xcon@ietf.org; Wed, 03 Dec 2003 07:58:20 -0500 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 1ARWaB-00000U-00 for xcon@ietf.org; Wed, 03 Dec 2003 07:58:19 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id HAA06215; Wed, 3 Dec 2003 07:57:41 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id HAA07550; Wed, 3 Dec 2003 07:57:41 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Dec 2003 07:57:40 -0500 Message-ID: <313680C9A886D511A06000204840E1CF070B615F@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Paul Kyzivat'" Cc: "'hisham.khartabil@nokia.com'" , rohan@cisco.com, alan.johnston@mci.com, georg.mayer@nokia.com, oritl@microsoft.com, xcon@ietf.org Subject: RE: [XCON] Chicken and Egg - Can CPCP create a conference Date: Wed, 3 Dec 2003 07:57:31 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , Ah, I wondered when we would get to this. This is one of the bigger problems in separating conference policy from sip signalling. Everything would be simpler if the conference policy server was always the focus. So, I want to ask, can we make it be so? What are the advantages of making the conference policy server separate from the focus? Two ideas occur to me: 1. Separation of implementation But this is not possible with the current framework because we don't specify the interface between CPCP and SIP; we assume that it is proprietary 2. Load Balancing But I really, really doubt that works. It would be easier to have a separate CPS with every focus, and replicate the combination So, what if we assume they are the same entity, and use the same ID? We don't need to have the conference policy be a URI, we merely have to locate the address of the server. So, it's the hostname of the conference URI. And a sip uri is a fine conference ID for the purpose of specifying which policy once we know where the server is. Is there some advantage of having the conference policy explicitly be a URI that I'm missing? Brian > -----Original Message----- > From: Paul Kiribati [mailto:pkyzivat@cisco.com] > Sent: Tuesday, December 02, 2003 2:44 PM > To: Rosen, Brian > Cc: 'hisham.khartabil@nokia.com'; rohan@cisco.com; > alan.johnston@mci.com; georg.mayer@nokia.com; oritl@microsoft.com; > xcon@ietf.org > Subject: Re: [XCON] Chicken and Egg - Can CPCP create a conference > > > > > Rosen, Brian wrote: > >> > >>If you look at XCAP list usage for example, you will see that > >>the list-URI used when sending SIP SUBSCRIBE requests to the > >>list is not the same as the URI used to manipulate the list > >>using XCAP. They certainly need to be linked, but not > >>necessarily the same. > >> > >>Depending on the protocol we chose, a SIP URI can or cannot > >>be used to identify a conference policy. > > > > I think we CAN always have the same ID. > > I think there is a lot of value in one ID > > I don't think there is any problem in having one ID > > > > So, I think there should be one. > > > > If there is a good reason, we can burden the conference > policy server > > with keeping the relationship, but unless there is a good > reason, history > > suggests that one namespace is better than two with linkage. > > [The chicken and the egg are different things. If I want to > talk to the > egg I need the address of the egg - having the address of the chicken > isn't sufficient. Its probably a bad idea to crack the egg in > order to > ask the chicken for the address of the egg.] > > Getting away from metaphors, this seems to be coming down to the > distinction between URIs and URLs. > > A sip address is a URL in that it is sufficient for me to locate a > corresponding (sip) resource. > > But it isn't sufficient for me to locate a CPCP resource. If > I knew how > to contact the appropriate CPCP server, perhaps a sip uri > could serve to > identify the policy. But that would require me to know the address of > the server a-priori. > > If all I have is the sip conference id, then to derive the > URI for the > policy from it I must invoke sip operations on it. > > Paul > > > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon > _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Wed Dec 3 08:17:18 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13765 for ; Wed, 3 Dec 2003 08:17:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARWsI-0004TL-Sk for xcon-archive@odin.ietf.org; Wed, 03 Dec 2003 08:17:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB3DH2SS017185 for xcon-archive@odin.ietf.org; Wed, 3 Dec 2003 08:17:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARWsI-0004T6-Ly for xcon-web-archive@optimus.ietf.org; Wed, 03 Dec 2003 08:17:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13741 for ; Wed, 3 Dec 2003 08:16:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARWsH-0000OD-00 for xcon-web-archive@ietf.org; Wed, 03 Dec 2003 08:17:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARWsH-0000OA-00 for xcon-web-archive@ietf.org; Wed, 03 Dec 2003 08:17:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARWsG-0004Sp-Vw; Wed, 03 Dec 2003 08:17:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARWrU-0004Rx-MD for xcon@optimus.ietf.org; Wed, 03 Dec 2003 08:16:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13729 for ; Wed, 3 Dec 2003 08:15:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARWrT-0000Lp-00 for xcon@ietf.org; Wed, 03 Dec 2003 08:16:11 -0500 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 1ARWrS-0000LI-00 for xcon@ietf.org; Wed, 03 Dec 2003 08:16:10 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA06765; Wed, 3 Dec 2003 08:15:36 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA09832; Wed, 3 Dec 2003 08:15:37 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Dec 2003 08:15:36 -0500 Message-ID: <313680C9A886D511A06000204840E1CF070B6160@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Paul Kyzivat'" Cc: "'Heil Franca Marcelo'" , "'Alan Johnston'" , hisham.khartabil@nokia.com, rohan@cisco.com, georg.mayer@nokia.com, oritl@microsoft.com, xcon@ietf.org Subject: RE: [XCON] Chicken and Egg - Can CPCP create a conference Date: Wed, 3 Dec 2003 08:15:35 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , I'm arguing that there is no advantage for two mechanisms to start conferences. I prefer a SIP way, but I'll reluctantly except a CPCP way. First, let's observe that the "creator" of the conference has to be conference aware. A non-conference aware participant can be given a URI he don't understands is a conference URI, INVITE to it, and he's in. Similarly, he can get a REFER to some URI and get in that way. So, one could define the mechanism to always be that you send an INVITE to a conference Factory URI, which always returns a 3xx response with a Contact containing the conference URI. Given the conference URI you could INVITE immediately (ad=hoc) or wait until some time later. You can use the conference URI to modify the policy of the conference before or after the conference starts. Everything works fine. Similarly, you could always use CPCP to get a conference URI, INVITE immediately or later, modify the policy now or later, etc. Everything works fine. What is the difference in the result of these two mechanisms? Nothing What is the advantage of one mechanism over another? A UA which only did ad-hoc has a trivial implementation if you use the conference factory URI as long as the default policy was acceptable I don't see any other difference. This small difference argues for the conference factory uri choice Now, suppose, as has been proposed, the conference factory URI doesn't work the way I think, rather it immediately instantiates the conference. What is the difference? a) you save the second INVITE (2 messages per conference) b) you need another mechanism for a pre-established conference I expect most implementations of conference aware UAs will support both ad-hoc and pre-established. One mechanism is preferred. I don't think you will see a UA implementation that does pre-established only. That argues for the conference factory uri choice. The worst situation is that there are two equivalent mechanisms and there are implementations that only do one. That would create incompatible implementations. Brian > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Tuesday, December 02, 2003 2:22 PM > To: Rosen, Brian > Cc: 'Heil Franca Marcelo'; 'Alan Johnston'; > hisham.khartabil@nokia.com; > rohan@cisco.com; georg.mayer@nokia.com; oritl@microsoft.com; > xcon@ietf.org > Subject: Re: [XCON] Chicken and Egg - Can CPCP create a conference > > > > > Rosen, Brian wrote: > > Well, now you might see why I think the Conference Factory URI > > does not instantiate a conference; it just returns a conference ID. > > That way, you could, if you wanted to, change the default policy > > before you "started" it. > > It is my understanding that the Conference Factory URI is used by > sending an INVITE to it. So how is it supposed to return a > conference ID > without also "starting" the conference? Typically the result of the > INVITE will be a dialog with the focus, with the address of the focus > being returned as the Contact. Or are you assuming that Conference > Factory URI will *always* return a 3xx rather than > establishing the dialog? > > I would hate to write an application for creating/configuring a > conference that sends and INVITE but depends on it not > succeeding - so > that if it is surprised by having the INVITE succeed it barfs. > > I think sending an invite to a Conference Factory URI should only be > used when the UAC wants to participate in a new conference > that starts > *now*. > > If you want to establish a name and policy for a conference to take > place later, then I think you must use other means. > > Paul > > > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon > _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Wed Dec 3 08:28:18 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14048 for ; Wed, 3 Dec 2003 08:28:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARX2w-0004qI-LY for xcon-archive@odin.ietf.org; Wed, 03 Dec 2003 08:28:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB3DS2Jr018608 for xcon-archive@odin.ietf.org; Wed, 3 Dec 2003 08:28:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARX2w-0004q3-ER for xcon-web-archive@optimus.ietf.org; Wed, 03 Dec 2003 08:28:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14011 for ; Wed, 3 Dec 2003 08:27:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARX2v-0000eh-00 for xcon-web-archive@ietf.org; Wed, 03 Dec 2003 08:28:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARX2u-0000ee-00 for xcon-web-archive@ietf.org; Wed, 03 Dec 2003 08:28:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARX2v-0004pm-Gb; Wed, 03 Dec 2003 08:28:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARX1y-0004nM-3h for xcon@optimus.ietf.org; Wed, 03 Dec 2003 08:27:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13995 for ; Wed, 3 Dec 2003 08:26:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARX1w-0000dP-00 for xcon@ietf.org; Wed, 03 Dec 2003 08:27:01 -0500 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 1ARX1w-0000ch-00 for xcon@ietf.org; Wed, 03 Dec 2003 08:27:00 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA07135; Wed, 3 Dec 2003 08:26:26 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA11174; Wed, 3 Dec 2003 08:26:27 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Dec 2003 08:26:26 -0500 Message-ID: <313680C9A886D511A06000204840E1CF070B6161@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'hisham.khartabil@nokia.com'" , alan.johnston@mci.com, rohan@cisco.com, pkyzivat@cisco.com Cc: georg.mayer@nokia.com, oritl@microsoft.com, xcon@ietf.org Subject: RE: [XCON] Chicken and Egg - Can CPCP create a conference Date: Wed, 3 Dec 2003 08:26:23 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , > I see it as you connect to conference policy server, create a > conference policy and a conference ID (or get a conference ID > assigned to you). There is no need for a default policy to > exist for non ad-hoc conferences. > Sure there is. There is no requirement, nor should there be, to specify every element of conference policy. Yet, the implementation will enforce some value anyway. It's highly likely that there will be configuration by local administration. That is default policy. There is no requirement that you specify policy in one transaction. I expect many, many implementations will not do so for various UI reasons. Before you complete the policy, there is default policy for those parts you have not (yet) specified values. _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Wed Dec 3 09:45:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16942 for ; Wed, 3 Dec 2003 09:45:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARYFX-0000Ew-VV for xcon-archive@odin.ietf.org; Wed, 03 Dec 2003 09:45:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB3Ej7Sl000916 for xcon-archive@odin.ietf.org; Wed, 3 Dec 2003 09:45:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARYFX-0000Ec-O1 for xcon-web-archive@optimus.ietf.org; Wed, 03 Dec 2003 09:45:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16922 for ; Wed, 3 Dec 2003 09:44:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARYFR-0002Ii-00 for xcon-web-archive@ietf.org; Wed, 03 Dec 2003 09:45:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARYFQ-0002If-00 for xcon-web-archive@ietf.org; Wed, 03 Dec 2003 09:45:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARYFR-0000D5-Ga; Wed, 03 Dec 2003 09:45:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARYEi-0000C5-4H for xcon@optimus.ietf.org; Wed, 03 Dec 2003 09:44:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16890 for ; Wed, 3 Dec 2003 09:43:59 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARYEg-0002Ht-00 for xcon@ietf.org; Wed, 03 Dec 2003 09:44:14 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1ARYEf-0002Hp-00 for xcon@ietf.org; Wed, 03 Dec 2003 09:44:13 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hB3EiBV18795 for ; Wed, 3 Dec 2003 16:44:11 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 3 Dec 2003 16:44:11 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 3 Dec 2003 16:44:10 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] Chicken and Egg - Can CPCP create a conference Date: Wed, 3 Dec 2003 16:44:09 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB70118B11A@esebe019.ntc.nokia.com> Thread-Topic: [XCON] Chicken and Egg - Can CPCP create a conference Thread-Index: AcO5nSKm3Ol5QCpURtWsg8YXJsQWFwADfYfg To: , Cc: , , , , X-OriginalArrivalTime: 03 Dec 2003 14:44:10.0134 (UTC) FILETIME=[E94F4B60:01C3B9AB] Content-Transfer-Encoding: quoted-printable Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable You are asking to change the definition of a focus. It is created when = the conference is instantiated (using your definition of instantiation) = and destroyed when the conference instance is destroyed. Therefore, = pre-establishing a conference is not possible using CPCP unless a = conference is instantiated. That is not desirable. We have a conference framework in place, lets use it. /Hisham > -----Original Message----- > From: ext Rosen, Brian [mailto:Brian.Rosen@marconi.com] > Sent: 03.December.2003 14:58 > To: 'Paul Kyzivat' > Cc: Khartabil Hisham (NMP-MSW/Helsinki); rohan@cisco.com; > alan.johnston@mci.com; Mayer Georg (NMP-MSW/Helsinki); > oritl@microsoft.com; xcon@ietf.org > Subject: RE: [XCON] Chicken and Egg - Can CPCP create a conference >=20 >=20 > Ah, I wondered when we would get to this. >=20 > This is one of the bigger problems in separating conference policy=20 > from sip signalling. Everything would be simpler if the conference=20 > policy server was always the focus. >=20 > So, I want to ask, can we make it be so? >=20 > What are the advantages of making the conference policy server=20 > separate from the focus? Two ideas occur to me: > 1. Separation of implementation > But this is not possible with the current framework > because we don't specify the interface between=20 > CPCP and SIP; we assume that it is proprietary > 2. Load Balancing > But I really, really doubt that works. It=20 > would be easier > to have a separate CPS with every focus, and replicate > the combination >=20 > So, what if we assume they are the same entity, and use the same ID? > We don't need to have the conference policy be a URI, we merely have > to locate the address of the server. So, it's the hostname of the > conference URI. And a sip uri is a fine conference ID for the > purpose of specifying which policy once we know where the server is. >=20 > Is there some advantage of having the conference policy explicitly > be a URI that I'm missing? >=20 > Brian >=20 > > -----Original Message----- > > From: Paul Kiribati [mailto:pkyzivat@cisco.com] > > Sent: Tuesday, December 02, 2003 2:44 PM > > To: Rosen, Brian > > Cc: 'hisham.khartabil@nokia.com'; rohan@cisco.com; > > alan.johnston@mci.com; georg.mayer@nokia.com; oritl@microsoft.com; > > xcon@ietf.org > > Subject: Re: [XCON] Chicken and Egg - Can CPCP create a conference > >=20 > >=20 > >=20 > >=20 > > Rosen, Brian wrote: > > >> > > >>If you look at XCAP list usage for example, you will see that=20 > > >>the list-URI used when sending SIP SUBSCRIBE requests to the=20 > > >>list is not the same as the URI used to manipulate the list=20 > > >>using XCAP. They certainly need to be linked, but not=20 > > >>necessarily the same. > > >> > > >>Depending on the protocol we chose, a SIP URI can or cannot=20 > > >>be used to identify a conference policy. > > >=20 > > > I think we CAN always have the same ID. > > > I think there is a lot of value in one ID > > > I don't think there is any problem in having one ID > > >=20 > > > So, I think there should be one. > > >=20 > > > If there is a good reason, we can burden the conference=20 > > policy server > > > with keeping the relationship, but unless there is a good=20 > > reason, history > > > suggests that one namespace is better than two with linkage. > >=20 > > [The chicken and the egg are different things. If I want to=20 > > talk to the=20 > > egg I need the address of the egg - having the address of=20 > the chicken=20 > > isn't sufficient. Its probably a bad idea to crack the egg in=20 > > order to=20 > > ask the chicken for the address of the egg.] > >=20 > > Getting away from metaphors, this seems to be coming down to the=20 > > distinction between URIs and URLs. > >=20 > > A sip address is a URL in that it is sufficient for me to locate a=20 > > corresponding (sip) resource. > >=20 > > But it isn't sufficient for me to locate a CPCP resource. If=20 > > I knew how=20 > > to contact the appropriate CPCP server, perhaps a sip uri=20 > > could serve to=20 > > identify the policy. But that would require me to know the=20 > address of=20 > > the server a-priori. > >=20 > > If all I have is the sip conference id, then to derive the=20 > > URI for the=20 > > policy from it I must invoke sip operations on it. > >=20 > > Paul > >=20 > >=20 > > _______________________________________________ > > XCON mailing list > > XCON@ietf.org > > https://www1.ietf.org/mailman/listinfo/xcon > >=20 >=20 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Wed Dec 3 09:54:17 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17258 for ; Wed, 3 Dec 2003 09:54:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARYOA-0000WK-V4 for xcon-archive@odin.ietf.org; Wed, 03 Dec 2003 09:54:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB3Es2i2001994 for xcon-archive@odin.ietf.org; Wed, 3 Dec 2003 09:54:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARYOA-0000Vm-BU for xcon-web-archive@optimus.ietf.org; Wed, 03 Dec 2003 09:54:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17244 for ; Wed, 3 Dec 2003 09:53:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARYO8-0002Rj-00 for xcon-web-archive@ietf.org; Wed, 03 Dec 2003 09:54:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARYO7-0002Rg-00 for xcon-web-archive@ietf.org; Wed, 03 Dec 2003 09:53:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARYO8-0000Uc-Qe; Wed, 03 Dec 2003 09:54:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARYO5-0000TN-Fo for xcon@optimus.ietf.org; Wed, 03 Dec 2003 09:53:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17241 for ; Wed, 3 Dec 2003 09:53:41 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARYO3-0002Rd-00 for xcon@ietf.org; Wed, 03 Dec 2003 09:53:55 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1ARYO2-0002Ra-00 for xcon@ietf.org; Wed, 03 Dec 2003 09:53:54 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hB3ErrV00090 for ; Wed, 3 Dec 2003 16:53:53 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 3 Dec 2003 16:53:52 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 3 Dec 2003 16:53:53 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] Chicken and Egg - Can CPCP create a conference Date: Wed, 3 Dec 2003 16:53:52 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB70118B11B@esebe019.ntc.nokia.com> Thread-Topic: [XCON] Chicken and Egg - Can CPCP create a conference Thread-Index: AcO5oSVfxhJcrq7TQx+FppKgKU9WEQACvCqQ To: , , , Cc: , , X-OriginalArrivalTime: 03 Dec 2003 14:53:53.0189 (UTC) FILETIME=[44D66D50:01C3B9AD] Content-Transfer-Encoding: quoted-printable Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable This is an unnecessary 2 step process. Get a conference ID, which = creates a default policy for you, then modify the policy. Instead, I = just want to upload a policy and in return get the conference ID. I can = then manipulate the policy as see it. If there are local administration limitations, then either the policy is = rejected or manipulated by the administrator (the machine). Again, my point was that I see it as you connect to conference policy = server, create a conference policy and a conference ID (or get a = conference ID assigned to you) /Hisham > -----Original Message----- > From: ext Rosen, Brian [mailto:Brian.Rosen@marconi.com] > Sent: 03.December.2003 15:26 > To: Khartabil Hisham (NMP-MSW/Helsinki); alan.johnston@mci.com; > rohan@cisco.com; pkyzivat@cisco.com > Cc: Mayer Georg (NMP-MSW/Helsinki); oritl@microsoft.com; xcon@ietf.org > Subject: RE: [XCON] Chicken and Egg - Can CPCP create a conference >=20 >=20 >=20 > > I see it as you connect to conference policy server, create a=20 > > conference policy and a conference ID (or get a conference ID=20 > > assigned to you). There is no need for a default policy to=20 > > exist for non ad-hoc conferences. > >=20 > Sure there is. There is no requirement, nor should there be,=20 > to specify every element of conference policy. Yet, the=20 > implementation will enforce some value anyway. It's highly likely=20 > that there will be configuration by local administration.=20 > That is default policy. >=20 > There is no requirement that you specify policy in one transaction. > I expect many, many implementations will not do so for various UI > reasons. Before you complete the policy, there is default policy > for those parts you have not (yet) specified values.=20 >=20 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Wed Dec 3 10:17:28 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19240 for ; Wed, 3 Dec 2003 10:17:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARYkb-0002Fg-TD for xcon-archive@odin.ietf.org; Wed, 03 Dec 2003 10:17:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB3FHChh008645 for xcon-archive@odin.ietf.org; Wed, 3 Dec 2003 10:17:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARYkY-0002FM-82 for xcon-web-archive@optimus.ietf.org; Wed, 03 Dec 2003 10:17:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19181 for ; Wed, 3 Dec 2003 10:16:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARYkW-0002mR-00 for xcon-web-archive@ietf.org; Wed, 03 Dec 2003 10:17:08 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARYkV-0002mO-00 for xcon-web-archive@ietf.org; Wed, 03 Dec 2003 10:17:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARYkQ-0002Dm-3L; Wed, 03 Dec 2003 10:17:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARYjj-0002CI-Kr for xcon@optimus.ietf.org; Wed, 03 Dec 2003 10:16:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19110 for ; Wed, 3 Dec 2003 10:16:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARYjh-0002km-00 for xcon@ietf.org; Wed, 03 Dec 2003 10:16:17 -0500 Received: from dgesmtp01.wcom.com ([199.249.16.16]) by ietf-mx with esmtp (Exim 4.12) id 1ARYjg-0002kW-00 for xcon@ietf.org; Wed, 03 Dec 2003 10:16:17 -0500 Received: from pmismtp01.wcomnet.com ([166.38.62.36]) by firewall.wcom.com (Iplanet MTA 5.2) with ESMTP id <0HPB0036ZRI4XW@firewall.wcom.com> for xcon@ietf.org; Wed, 03 Dec 2003 15:10:52 +0000 (GMT) Received: from pmismtp01.wcomnet.com by pmismtp01.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0HPB00H01RH5WS@pmismtp01.wcomnet.com>; Wed, 03 Dec 2003 15:10:52 +0000 (GMT) Received: from xs578v3521.mci.com ([166.50.123.184]) by pmismtp01.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0HPB00HAXRHY5B@pmismtp01.wcomnet.com>; Wed, 03 Dec 2003 15:10:49 +0000 (GMT) Date: Wed, 03 Dec 2003 09:10:14 -0600 From: Alan Johnston Subject: RE: [XCON] Chicken and Egg - Can CPCP create a conference X-Sender: Alan.Johnston@pop.mcit.com To: "Rosen, Brian" , "'Paul Kyzivat'" Cc: "'Heil Franca Marcelo'" , hisham.khartabil@nokia.com, rohan@cisco.com, georg.mayer@nokia.com, oritl@microsoft.com, xcon@ietf.org Message-id: <5.2.1.1.0.20031203085924.02b197c0@pop.mcit.com> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Content-type: text/plain; charset=us-ascii; format=flowed Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , At 08:15 AM 12/3/2003 -0500, Rosen, Brian wrote: >I'm arguing that there is no advantage for two mechanisms to start >conferences. >I prefer a SIP way, but I'll reluctantly except a CPCP way. > >First, let's observe that the "creator" of the conference has to be >conference aware. A non-conference aware participant can be given >a URI he don't understands is a conference URI, INVITE to it, and he's in. >Similarly, he can get a REFER to some URI and get in that way. > >So, one could define the mechanism to always be that you send an INVITE >to a conference Factory URI, which always returns a 3xx response with >a Contact containing the conference URI. Given the conference URI you >could INVITE immediately (ad=hoc) or wait until some time later. You >can use the conference URI to modify the policy of the conference before >or after the conference starts. Everything works fine. No, I'm afraid not. Many proxies automatically recurse on 3xx responses. As a result, even if we somehow say that a conference factory MUST redirect, the result would often be the establishment of a session. Now what, the application has to send a BYE to disconnect since the conference is not until next week? Will my conference server see a steady stream of 1 second, single participant conferences? Yuk! Also, I expect that many of the protocols developed here in XCON will be used to applications and automata. These applications will not have a SIP UA. Will we force them to have a SIP UA so they can send an INVITE which will always be followed by a BYE just to get a Conference URI? Besides the CPCP security mechanisms, now this application will need SIP security/authentication/firewall/NAT traversal issues - again, yuk! XCON protocols must stand on their own - having a way to create and get a Conference URI seems like a critical element. >Similarly, you could always use CPCP to get a conference URI, INVITE >immediately or later, modify the policy now or later, etc. Everything works >fine. > >What is the difference in the result of these two mechanisms? > Nothing > >What is the advantage of one mechanism over another? > A UA which only did ad-hoc has a trivial implementation if you use > the conference factory URI as long as the default policy was >acceptable > > I don't see any other difference. > > This small difference argues for the conference factory uri choice > >Now, suppose, as has been proposed, the conference factory URI doesn't >work the way I think, rather it immediately instantiates the conference. >What is the difference? > a) you save the second INVITE (2 messages per conference) > b) you need another mechanism for a pre-established conference > >I expect most implementations of conference aware UAs will support both >ad-hoc and pre-established. One mechanism is preferred. I don't think >you will see a UA implementation that does pre-established only. That >argues for the conference factory uri choice. As I have argued above, many endpoints besides UAs will use our protocols to create conferences - requiring them to implement SIP and send an INVITE that doesn't establish a session is just a bad idea. Thanks, Alan Johnston MCI sip:alan@sipstation.com >The worst situation is that there are two equivalent mechanisms and there >are implementations that only do one. That would create incompatible >implementations. > >Brian > > > -----Original Message----- > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > Sent: Tuesday, December 02, 2003 2:22 PM > > To: Rosen, Brian > > Cc: 'Heil Franca Marcelo'; 'Alan Johnston'; > > hisham.khartabil@nokia.com; > > rohan@cisco.com; georg.mayer@nokia.com; oritl@microsoft.com; > > xcon@ietf.org > > Subject: Re: [XCON] Chicken and Egg - Can CPCP create a conference > > > > > > > > > > Rosen, Brian wrote: > > > Well, now you might see why I think the Conference Factory URI > > > does not instantiate a conference; it just returns a conference ID. > > > That way, you could, if you wanted to, change the default policy > > > before you "started" it. > > > > It is my understanding that the Conference Factory URI is used by > > sending an INVITE to it. So how is it supposed to return a > > conference ID > > without also "starting" the conference? Typically the result of the > > INVITE will be a dialog with the focus, with the address of the focus > > being returned as the Contact. Or are you assuming that Conference > > Factory URI will *always* return a 3xx rather than > > establishing the dialog? > > > > I would hate to write an application for creating/configuring a > > conference that sends and INVITE but depends on it not > > succeeding - so > > that if it is surprised by having the INVITE succeed it barfs. > > > > I think sending an invite to a Conference Factory URI should only be > > used when the UAC wants to participate in a new conference > > that starts > > *now*. > > > > If you want to establish a name and policy for a conference to take > > place later, then I think you must use other means. > > > > Paul > > > > > > _______________________________________________ > > XCON mailing list > > XCON@ietf.org > > https://www1.ietf.org/mailman/listinfo/xcon > > > >_______________________________________________ >XCON mailing list >XCON@ietf.org >https://www1.ietf.org/mailman/listinfo/xcon _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Wed Dec 3 10:18:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19286 for ; Wed, 3 Dec 2003 10:18:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARYlU-0002KC-1e for xcon-archive@odin.ietf.org; Wed, 03 Dec 2003 10:18:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB3FI79x008930 for xcon-archive@odin.ietf.org; Wed, 3 Dec 2003 10:18:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARYlR-0002Jx-Qt for xcon-web-archive@optimus.ietf.org; Wed, 03 Dec 2003 10:18:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19271 for ; Wed, 3 Dec 2003 10:17:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARYlP-0002n8-00 for xcon-web-archive@ietf.org; Wed, 03 Dec 2003 10:18:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARYlP-0002n5-00 for xcon-web-archive@ietf.org; Wed, 03 Dec 2003 10:18:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARYlO-0002Id-Vo; Wed, 03 Dec 2003 10:18:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARYkQ-0002Do-FW for xcon@optimus.ietf.org; Wed, 03 Dec 2003 10:17:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19176 for ; Wed, 3 Dec 2003 10:16:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARYkO-0002mL-00 for xcon@ietf.org; Wed, 03 Dec 2003 10:17:00 -0500 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 1ARYkM-0002kx-00 for xcon@ietf.org; Wed, 03 Dec 2003 10:16:59 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA11701; Wed, 3 Dec 2003 10:10:28 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA28888; Wed, 3 Dec 2003 10:10:25 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Dec 2003 10:10:25 -0500 Message-ID: <313680C9A886D511A06000204840E1CF070B6165@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'hisham.khartabil@nokia.com'" , pkyzivat@cisco.com Cc: rohan@cisco.com, alan.johnston@mci.com, georg.mayer@nokia.com, oritl@microsoft.com, xcon@ietf.org Subject: RE: [XCON] Chicken and Egg - Can CPCP create a conference Date: Wed, 3 Dec 2003 10:10:16 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , I don't understand this. I'm not changing the definition of a focus. I'm observing that the host of the focus is the host of the policy server, at least for now. At some point in the future, we could change this, but now, we can easily make them the same. If we use XCAP for CPCP, this seems very straightforward, and it's even a uri! suppose the conferenceID is: sip:hishams-weekly-status-meeting@confa.example.com Then the XCAP URI for this conference is http:confa.example.com/cpcp/hishams-weekly-status-meeting... at least for now. All I propose is that the root service uri for CPCP be slightly more structured for CPCP than XCAP, which proposes that the root service uri be provisioned. If this offends you that much, you could always say that if you have an XCAP service root, use it, adding cpcp/hishams-weekly-status-meeting to it to access the policy for this conference. If it's not XCAP, we still use the focus host as the CPCP host, and the conference uri userpart as the id, with whatever convention the chosen protocol uses to encode it. > -----Original Message----- > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > Sent: Wednesday, December 03, 2003 9:44 AM > To: Brian.Rosen@marconi.com; pkyzivat@cisco.com > Cc: rohan@cisco.com; alan.johnston@mci.com; georg.mayer@nokia.com; > oritl@microsoft.com; xcon@ietf.org > Subject: RE: [XCON] Chicken and Egg - Can CPCP create a conference > > > You are asking to change the definition of a focus. It is > created when the conference is instantiated (using your > definition of instantiation) and destroyed when the > conference instance is destroyed. Therefore, pre-establishing > a conference is not possible using CPCP unless a conference > is instantiated. That is not desirable. > > We have a conference framework in place, lets use it. > > /Hisham > > > -----Original Message----- > > From: ext Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > Sent: 03.December.2003 14:58 > > To: 'Paul Kyzivat' > > Cc: Khartabil Hisham (NMP-MSW/Helsinki); rohan@cisco.com; > > alan.johnston@mci.com; Mayer Georg (NMP-MSW/Helsinki); > > oritl@microsoft.com; xcon@ietf.org > > Subject: RE: [XCON] Chicken and Egg - Can CPCP create a conference > > > > > > Ah, I wondered when we would get to this. > > > > This is one of the bigger problems in separating conference policy > > from sip signalling. Everything would be simpler if the conference > > policy server was always the focus. > > > > So, I want to ask, can we make it be so? > > > > What are the advantages of making the conference policy server > > separate from the focus? Two ideas occur to me: > > 1. Separation of implementation > > But this is not possible with the current framework > > because we don't specify the interface between > > CPCP and SIP; we assume that it is proprietary > > 2. Load Balancing > > But I really, really doubt that works. It > > would be easier > > to have a separate CPS with every focus, and replicate > > the combination > > > > So, what if we assume they are the same entity, and use the same ID? > > We don't need to have the conference policy be a URI, we merely have > > to locate the address of the server. So, it's the hostname of the > > conference URI. And a sip uri is a fine conference ID for the > > purpose of specifying which policy once we know where the server is. > > > > Is there some advantage of having the conference policy explicitly > > be a URI that I'm missing? > > > > Brian > > > > > -----Original Message----- > > > From: Paul Kiribati [mailto:pkyzivat@cisco.com] > > > Sent: Tuesday, December 02, 2003 2:44 PM > > > To: Rosen, Brian > > > Cc: 'hisham.khartabil@nokia.com'; rohan@cisco.com; > > > alan.johnston@mci.com; georg.mayer@nokia.com; oritl@microsoft.com; > > > xcon@ietf.org > > > Subject: Re: [XCON] Chicken and Egg - Can CPCP create a conference > > > > > > > > > > > > > > > Rosen, Brian wrote: > > > >> > > > >>If you look at XCAP list usage for example, you will see that > > > >>the list-URI used when sending SIP SUBSCRIBE requests to the > > > >>list is not the same as the URI used to manipulate the list > > > >>using XCAP. They certainly need to be linked, but not > > > >>necessarily the same. > > > >> > > > >>Depending on the protocol we chose, a SIP URI can or cannot > > > >>be used to identify a conference policy. > > > > > > > > I think we CAN always have the same ID. > > > > I think there is a lot of value in one ID > > > > I don't think there is any problem in having one ID > > > > > > > > So, I think there should be one. > > > > > > > > If there is a good reason, we can burden the conference > > > policy server > > > > with keeping the relationship, but unless there is a good > > > reason, history > > > > suggests that one namespace is better than two with linkage. > > > > > > [The chicken and the egg are different things. If I want to > > > talk to the > > > egg I need the address of the egg - having the address of > > the chicken > > > isn't sufficient. Its probably a bad idea to crack the egg in > > > order to > > > ask the chicken for the address of the egg.] > > > > > > Getting away from metaphors, this seems to be coming down to the > > > distinction between URIs and URLs. > > > > > > A sip address is a URL in that it is sufficient for me to > locate a > > > corresponding (sip) resource. > > > > > > But it isn't sufficient for me to locate a CPCP resource. If > > > I knew how > > > to contact the appropriate CPCP server, perhaps a sip uri > > > could serve to > > > identify the policy. But that would require me to know the > > address of > > > the server a-priori. > > > > > > If all I have is the sip conference id, then to derive the > > > URI for the > > > policy from it I must invoke sip operations on it. > > > > > > Paul > > > > > > > > > _______________________________________________ > > > XCON mailing list > > > XCON@ietf.org > > > https://www1.ietf.org/mailman/listinfo/xcon > > > > > > > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon > _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Wed Dec 3 10:27:18 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19562 for ; Wed, 3 Dec 2003 10:27:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARYu8-0002Zx-JH for xcon-archive@odin.ietf.org; Wed, 03 Dec 2003 10:27:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB3FR4Np009902 for xcon-archive@odin.ietf.org; Wed, 3 Dec 2003 10:27:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARYu8-0002ZT-1U for xcon-web-archive@optimus.ietf.org; Wed, 03 Dec 2003 10:27:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19525 for ; Wed, 3 Dec 2003 10:26:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARYu5-0002rW-00 for xcon-web-archive@ietf.org; Wed, 03 Dec 2003 10:27:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARYu4-0002rP-00 for xcon-web-archive@ietf.org; Wed, 03 Dec 2003 10:27:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARYu5-0002Xx-Kv; Wed, 03 Dec 2003 10:27:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARYtZ-0002Wu-Fp for xcon@optimus.ietf.org; Wed, 03 Dec 2003 10:26:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19495 for ; Wed, 3 Dec 2003 10:26:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARYtX-0002ql-00 for xcon@ietf.org; Wed, 03 Dec 2003 10:26:27 -0500 Received: from dgesmtp02.wcom.com ([199.249.16.17]) by ietf-mx with esmtp (Exim 4.12) id 1ARYtW-0002pv-00 for xcon@ietf.org; Wed, 03 Dec 2003 10:26:26 -0500 Received: from pmismtp02.wcomnet.com ([166.38.62.37]) by firewall.wcom.com (Iplanet MTA 5.2) with ESMTP id <0HPB00BKHRWJ0Y@firewall.wcom.com> for xcon@ietf.org; Wed, 03 Dec 2003 15:19:56 +0000 (GMT) Received: from pmismtp02.wcomnet.com by pmismtp02.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0HPB00M01RQD3A@pmismtp02.wcomnet.com>; Wed, 03 Dec 2003 15:19:49 +0000 (GMT) Received: from xs578v3521.mci.com ([166.50.123.184]) by pmismtp02.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0HPB00LQARWA9V@pmismtp02.wcomnet.com>; Wed, 03 Dec 2003 15:19:26 +0000 (GMT) Date: Wed, 03 Dec 2003 09:19:23 -0600 From: Alan Johnston Subject: RE: [XCON] Chicken and Egg - Can CPCP create a conference X-Sender: Alan.Johnston@pop.mcit.com To: "Rosen, Brian" , "'Paul Kyzivat'" Cc: "'hisham.khartabil@nokia.com'" , rohan@cisco.com, georg.mayer@nokia.com, oritl@microsoft.com, xcon@ietf.org, eburger@snowshore.com Message-id: <5.2.1.1.0.20031203091140.02b03d90@pop.mcit.com> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Content-type: text/plain; charset=us-ascii; format=flowed Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , At 07:57 AM 12/3/2003 -0500, Rosen, Brian wrote: >Ah, I wondered when we would get to this. > >This is one of the bigger problems in separating conference policy >from sip signalling. Everything would be simpler if the conference >policy server was always the focus. > >So, I want to ask, can we make it be so? > >What are the advantages of making the conference policy server >separate from the focus? Two ideas occur to me: > 1. Separation of implementation > But this is not possible with the current framework > because we don't specify the interface between > CPCP and SIP; we assume that it is proprietary > 2. Load Balancing > But I really, really doubt that works. It would be easier > to have a separate CPS with every focus, and replicate > the combination These are all design issues for the service provider - building in assumptions like these in the protocol design is a bad idea. >So, what if we assume they are the same entity, and use the same ID? >We don't need to have the conference policy be a URI, we merely have >to locate the address of the server. So, it's the hostname of the >conference URI. And a sip uri is a fine conference ID for the >purpose of specifying which policy once we know where the server is. So my media server must also be my conference policy server?? Once you learn the IP address of the mixer, you just start sending CPCP commands to that IP address? Are you serious? >Is there some advantage of having the conference policy explicitly >be a URI that I'm missing? Yes - flexibility, extensibility, generality, DNS, etc - the same reasons we use URIs in SIP and not just IP addresses. Thanks, Alan Johnston MCI sip:alan@sipstation.com >Brian > > > -----Original Message----- > > From: Paul Kiribati [mailto:pkyzivat@cisco.com] > > Sent: Tuesday, December 02, 2003 2:44 PM > > To: Rosen, Brian > > Cc: 'hisham.khartabil@nokia.com'; rohan@cisco.com; > > alan.johnston@mci.com; georg.mayer@nokia.com; oritl@microsoft.com; > > xcon@ietf.org > > Subject: Re: [XCON] Chicken and Egg - Can CPCP create a conference > > > > > > > > > > Rosen, Brian wrote: > > >> > > >>If you look at XCAP list usage for example, you will see that > > >>the list-URI used when sending SIP SUBSCRIBE requests to the > > >>list is not the same as the URI used to manipulate the list > > >>using XCAP. They certainly need to be linked, but not > > >>necessarily the same. > > >> > > >>Depending on the protocol we chose, a SIP URI can or cannot > > >>be used to identify a conference policy. > > > > > > I think we CAN always have the same ID. > > > I think there is a lot of value in one ID > > > I don't think there is any problem in having one ID > > > > > > So, I think there should be one. > > > > > > If there is a good reason, we can burden the conference > > policy server > > > with keeping the relationship, but unless there is a good > > reason, history > > > suggests that one namespace is better than two with linkage. > > > > [The chicken and the egg are different things. If I want to > > talk to the > > egg I need the address of the egg - having the address of the chicken > > isn't sufficient. Its probably a bad idea to crack the egg in > > order to > > ask the chicken for the address of the egg.] > > > > Getting away from metaphors, this seems to be coming down to the > > distinction between URIs and URLs. > > > > A sip address is a URL in that it is sufficient for me to locate a > > corresponding (sip) resource. > > > > But it isn't sufficient for me to locate a CPCP resource. If > > I knew how > > to contact the appropriate CPCP server, perhaps a sip uri > > could serve to > > identify the policy. But that would require me to know the address of > > the server a-priori. > > > > If all I have is the sip conference id, then to derive the > > URI for the > > policy from it I must invoke sip operations on it. > > > > Paul > > > > > > _______________________________________________ > > XCON mailing list > > XCON@ietf.org > > https://www1.ietf.org/mailman/listinfo/xcon > > > >_______________________________________________ >XCON mailing list >XCON@ietf.org >https://www1.ietf.org/mailman/listinfo/xcon _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Wed Dec 3 10:32:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19880 for ; Wed, 3 Dec 2003 10:32:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARYyz-0002tU-Kw for xcon-archive@odin.ietf.org; Wed, 03 Dec 2003 10:32:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB3FW5wZ011117 for xcon-archive@odin.ietf.org; Wed, 3 Dec 2003 10:32:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARYyz-0002tC-DG for xcon-web-archive@optimus.ietf.org; Wed, 03 Dec 2003 10:32:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19865 for ; Wed, 3 Dec 2003 10:31:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARYyx-0002zv-00 for xcon-web-archive@ietf.org; Wed, 03 Dec 2003 10:32:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARYyw-0002zs-00 for xcon-web-archive@ietf.org; Wed, 03 Dec 2003 10:32:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARYyx-0002sm-RO; Wed, 03 Dec 2003 10:32:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARYyT-0002rN-VA for xcon@optimus.ietf.org; Wed, 03 Dec 2003 10:31:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19842 for ; Wed, 3 Dec 2003 10:31:17 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARYyR-0002xn-00 for xcon@ietf.org; Wed, 03 Dec 2003 10:31:31 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1ARYyQ-0002xi-00 for xcon@ietf.org; Wed, 03 Dec 2003 10:31:30 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hB3FVSV14645 for ; Wed, 3 Dec 2003 17:31:28 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 3 Dec 2003 17:31:28 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 3 Dec 2003 17:31:27 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 3 Dec 2003 17:31:26 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] Chicken and Egg - Can CPCP create a conference Date: Wed, 3 Dec 2003 17:31:26 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB70118B11D@esebe019.ntc.nokia.com> Thread-Topic: [XCON] Chicken and Egg - Can CPCP create a conference Thread-Index: AcO5sIeTpQ80paceR4+RR81D9NPFIwAANF9w To: , Cc: , , , , X-OriginalArrivalTime: 03 Dec 2003 15:31:26.0731 (UTC) FILETIME=[840DA5B0:01C3B9B2] Content-Transfer-Encoding: quoted-printable Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Focus host and focus are different things. I earlier assumed you meant = focus and not focus host. I apologise. I agree that the host of the policy server and the focus is one of the = same (the conference server). NO arguments here. More comments inline... > -----Original Message----- > From: ext Rosen, Brian [mailto:Brian.Rosen@marconi.com] > Sent: 03.December.2003 17:10 > To: Khartabil Hisham (NMP-MSW/Helsinki); pkyzivat@cisco.com > Cc: rohan@cisco.com; alan.johnston@mci.com; Mayer Georg > (NMP-MSW/Helsinki); oritl@microsoft.com; xcon@ietf.org > Subject: RE: [XCON] Chicken and Egg - Can CPCP create a conference >=20 >=20 > I don't understand this. I'm not changing the definition of a focus. > I'm observing that the host of the focus is the host of the policy > server, at least for now. At some point in the future, we could > change this, but now, we can easily make them the same. =20 >=20 > If we use XCAP for CPCP, this seems very straightforward, > and it's even a uri! >=20 > suppose the conferenceID is: > sip:hishams-weekly-status-meeting@confa.example.com >=20 > Then the XCAP URI for this conference is > http:confa.example.com/cpcp/hishams-weekly-status-meeting... >=20 > at least for now. All I propose is that the root service uri for > CPCP be slightly more structured for CPCP than XCAP, which proposes > that the root service uri be provisioned. If this offends you > that much, you could always say that if you have an XCAP service > root, use it, adding cpcp/hishams-weekly-status-meeting to it > to access the policy for this conference. Yes, this is what I thought of also when I earlier agreed for ad-hoc = conferences to have a default policy. The UA can then extract the = userinfo part of the URI returned as the focus address and use that to = manipulate the policy. The host of the policy server and the focus needs = to create such policy and therefore needs to either assign conference = URIs or learn then to enable it to create the policy. so: INVITE--> 200<-- with contact: sip:conf123@example.com CPCP (assuming xcap) can be: GET http://example.com/conference/hisham/conf123 should work. /Hisham _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Wed Dec 3 11:09:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21470 for ; Wed, 3 Dec 2003 11:09:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARZYl-0005QE-B9 for xcon-archive@odin.ietf.org; Wed, 03 Dec 2003 11:09:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB3G93um020836 for xcon-archive@odin.ietf.org; Wed, 3 Dec 2003 11:09:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARZYl-0005Pz-05 for xcon-web-archive@optimus.ietf.org; Wed, 03 Dec 2003 11:09:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21447 for ; Wed, 3 Dec 2003 11:08:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARZYi-0003a7-00 for xcon-web-archive@ietf.org; Wed, 03 Dec 2003 11:09:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARZYh-0003a4-00 for xcon-web-archive@ietf.org; Wed, 03 Dec 2003 11:08:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARZYj-0005Pf-Oh; Wed, 03 Dec 2003 11:09:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARZXv-0005Bw-Og for xcon@optimus.ietf.org; Wed, 03 Dec 2003 11:08:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21356 for ; Wed, 3 Dec 2003 11:07:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARZXr-0003ZX-00 for xcon@ietf.org; Wed, 03 Dec 2003 11:08:07 -0500 Received: from pmesmtp02.wcom.com ([199.249.20.2]) by ietf-mx with esmtp (Exim 4.12) id 1ARZXr-0003Yu-00 for xcon@ietf.org; Wed, 03 Dec 2003 11:08:07 -0500 Received: from pmismtp02.wcomnet.com ([166.38.62.37]) by firewall.wcom.com (Iplanet MTA 5.2) with ESMTP id <0HPB00GBXTUE7Y@firewall.wcom.com> for xcon@ietf.org; Wed, 03 Dec 2003 16:01:26 +0000 (GMT) Received: from pmismtp02.wcomnet.com by pmismtp02.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0HPB00501TTEFG@pmismtp02.wcomnet.com>; Wed, 03 Dec 2003 16:01:26 +0000 (GMT) Received: from xs578v3521.mci.com ([166.50.123.184]) by pmismtp02.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0HPB00517TU2FA@pmismtp02.wcomnet.com>; Wed, 03 Dec 2003 16:01:17 +0000 (GMT) Date: Wed, 03 Dec 2003 10:01:12 -0600 From: Alan Johnston Subject: RE: [XCON] Chicken and Egg - Can CPCP create a conference In-reply-to: <2038BCC78B1AD641891A0D1AE133DBB70118B11D@esebe019.ntc.noki a.com> X-Sender: Alan.Johnston@pop.mcit.com To: hisham.khartabil@nokia.com, Brian.Rosen@marconi.com, pkyzivat@cisco.com Cc: rohan@cisco.com, georg.mayer@nokia.com, oritl@microsoft.com, xcon@ietf.org Message-id: <5.2.1.1.0.20031203094805.02b1fb80@pop.mcit.com> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Content-type: text/plain; charset=us-ascii; format=flowed Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , At 05:31 PM 12/3/2003 +0200, hisham.khartabil@nokia.com wrote: >Focus host and focus are different things. I earlier assumed you meant >focus and not focus host. I apologise. > >I agree that the host of the policy server and the focus is one of the >same (the conference server). NO arguments here. > >More comments inline... > > > -----Original Message----- > > From: ext Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > Sent: 03.December.2003 17:10 > > To: Khartabil Hisham (NMP-MSW/Helsinki); pkyzivat@cisco.com > > Cc: rohan@cisco.com; alan.johnston@mci.com; Mayer Georg > > (NMP-MSW/Helsinki); oritl@microsoft.com; xcon@ietf.org > > Subject: RE: [XCON] Chicken and Egg - Can CPCP create a conference > > > > > > I don't understand this. I'm not changing the definition of a focus. > > I'm observing that the host of the focus is the host of the policy > > server, at least for now. At some point in the future, we could > > change this, but now, we can easily make them the same. > > > > If we use XCAP for CPCP, this seems very straightforward, > > and it's even a uri! > > > > suppose the conferenceID is: > > sip:hishams-weekly-status-meeting@confa.example.com > > > > Then the XCAP URI for this conference is > > http:confa.example.com/cpcp/hishams-weekly-status-meeting... > > > > at least for now. All I propose is that the root service uri for > > CPCP be slightly more structured for CPCP than XCAP, which proposes > > that the root service uri be provisioned. If this offends you > > that much, you could always say that if you have an XCAP service > > root, use it, adding cpcp/hishams-weekly-status-meeting to it > > to access the policy for this conference. > >Yes, this is what I thought of also when I earlier agreed for ad-hoc >conferences to have a default policy. The UA can then extract the userinfo >part of the URI returned as the focus address and use that to manipulate >the policy. We must stop talking about "ad-hoc conferences" and "scheduled conferences" - there is no such thing. There are only ad-hoc mechanisms and scheduled mechanisms to create/join a conference. I don't think there has ever been consensus on a requirement that the policy URI be guessable from the Conference URI. > The host of the policy server and the focus needs to create such policy > and therefore needs to either assign conference URIs or learn then to > enable it to create the policy. > >so: > >INVITE--> >200<-- with contact: sip:conf123@example.com > > >CPCP (assuming xcap) can be: > >GET http://example.com/conference/hisham/conf123 > >should work. > >/Hisham > So, if The Example Company already has their public web server home page at example.com where everyone goes to download the latest examples, this web server now needs to become the conference policy server? There are significant disadvantages in limiting ourselves to such conventions - especially when there are other ways of discovering the policy URI. One way that has been discussed is advertising the policy URI in conference package notifications. Is this not sufficient? This approach is flexible and extensible (different protocols for policy manipulation can be defined with a new URI scheme) and has none of the name space limitations of this proposal. Thanks, Alan Johnston MCI sip:alan@sipstation.com >_______________________________________________ >XCON mailing list >XCON@ietf.org >https://www1.ietf.org/mailman/listinfo/xcon _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Wed Dec 3 11:23:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21907 for ; Wed, 3 Dec 2003 11:23:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARZmI-0006LT-7R for xcon-archive@odin.ietf.org; Wed, 03 Dec 2003 11:23:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB3GN2vg024387 for xcon-archive@odin.ietf.org; Wed, 3 Dec 2003 11:23:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARZmI-0006LG-1K for xcon-web-archive@optimus.ietf.org; Wed, 03 Dec 2003 11:23:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21895 for ; Wed, 3 Dec 2003 11:22:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARZmH-0003nt-00 for xcon-web-archive@ietf.org; Wed, 03 Dec 2003 11:23:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARZmG-0003nq-00 for xcon-web-archive@ietf.org; Wed, 03 Dec 2003 11:23:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARZmG-0006Kz-Tf; Wed, 03 Dec 2003 11:23:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARZmB-0006Ko-0V for xcon@optimus.ietf.org; Wed, 03 Dec 2003 11:22:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21892 for ; Wed, 3 Dec 2003 11:22:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARZmA-0003nn-00 for xcon@ietf.org; Wed, 03 Dec 2003 11:22:54 -0500 Received: from mail49.messagelabs.com ([193.109.255.19]) by ietf-mx with smtp (Exim 4.12) id 1ARZm9-0003nS-00 for xcon@ietf.org; Wed, 03 Dec 2003 11:22:53 -0500 X-VirusChecked: Checked X-Env-Sender: cboulton@ubiquity.net X-Msg-Ref: server-2.tower-49.messagelabs.com!1070468536!579076 X-StarScan-Version: 5.1.13; banners=ubiquity.net,-,- Received: (qmail 27043 invoked from network); 3 Dec 2003 16:22:17 -0000 Received: from news.ubiquity.net (HELO gbnewp0186s1.eu.ubiquity.net) (194.202.146.92) by server-2.tower-49.messagelabs.com with SMTP; 3 Dec 2003 16:22:17 -0000 Received: from mailhost.eu.ubiquity.net by gbnewp0186s1.eu.ubiquity.net via smtpd (for mail49.messagelabs.com [193.109.255.19]) with SMTP; Wed, 3 Dec 2003 16:24:50 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] Chicken and Egg - Can CPCP create a conference Date: Wed, 3 Dec 2003 16:21:07 -0000 Message-ID: <45730E094814E44488F789C1CDED27AE0219B13C@gbnewp0758m.eu.ubiquity.net> Thread-Topic: [XCON] Chicken and Egg - Can CPCP create a conference Thread-Index: AcO5t6FNYctki9lITtmEoWSugqcfbgAAL22Q From: "Chris Boulton" To: "Alan Johnston" , , , Cc: , , , Content-Transfer-Encoding: quoted-printable Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable >-----Original=20Message----- >From:=20Alan=20Johnston=20[mailto:alan.johnston@mci.com] >Sent:=2003=20December=202003=2016:01 >To:=20hisham.khartabil@nokia.com;=20Brian.Rosen@marconi.com; pkyzivat@cisco.com >Cc:=20rohan@cisco.com;=20georg.mayer@nokia.com;=20oritl@microsoft.com; >xcon@ietf.org >Subject:=20RE:=20[XCON]=20Chicken=20and=20Egg=20-=20Can=20CPCP=20create=20= a=20conference > >At=2005:31=20PM=2012/3/2003=20+0200,=20hisham.khartabil@nokia.com=20wrote= : >>Focus=20host=20and=20focus=20are=20different=20things.=20I=20earlier=20a= ssumed=20you=20meant >>focus=20and=20not=20focus=20host.=20I=20apologise. >> >>I=20agree=20that=20the=20host=20of=20the=20policy=20server=20and=20the=20= focus=20is=20one=20of=20the >>same=20(the=20conference=20server).=20NO=20arguments=20here. >> >>More=20comments=20inline... >> >>=20>=20-----Original=20Message----- >>=20>=20From:=20ext=20Rosen,=20Brian=20[mailto:Brian.Rosen@marconi.com] >>=20>=20Sent:=2003.December.2003=2017:10 >>=20>=20To:=20Khartabil=20Hisham=20(NMP-MSW/Helsinki);=20pkyzivat@cisco.c= om >>=20>=20Cc:=20rohan@cisco.com;=20alan.johnston@mci.com;=20Mayer=20Georg >>=20>=20(NMP-MSW/Helsinki);=20oritl@microsoft.com;=20xcon@ietf.org >>=20>=20Subject:=20RE:=20[XCON]=20Chicken=20and=20Egg=20-=20Can=20CPCP=20= create=20a=20conference >>=20> >>=20> >>=20>=20I=20don't=20understand=20this.=20=20I'm=20not=20changing=20the=20= definition=20of=20a focus. >>=20>=20I'm=20observing=20that=20the=20host=20of=20the=20focus=20is=20the= =20host=20of=20the=20policy >>=20>=20server,=20at=20least=20for=20now.=20=20At=20some=20point=20in=20t= he=20future,=20we=20could >>=20>=20change=20this,=20but=20now,=20we=20can=20easily=20make=20them=20t= he=20same. >>=20> >>=20>=20If=20we=20use=20XCAP=20for=20CPCP,=20this=20seems=20very=20straig= htforward, >>=20>=20and=20it's=20even=20a=20uri! >>=20> >>=20>=20suppose=20the=20conferenceID=20is: >>=20>=20=20=20sip:hishams-weekly-status-meeting@confa.example.com >>=20> >>=20>=20Then=20the=20XCAP=20URI=20for=20this=20conference=20is >>=20>=20=20=20http:confa.example.com/cpcp/hishams-weekly-status-meeting..= . >>=20> >>=20>=20at=20least=20for=20now.=20=20All=20I=20propose=20is=20that=20the=20= root=20service=20uri=20for >>=20>=20CPCP=20be=20slightly=20more=20structured=20for=20CPCP=20than=20XC= AP,=20which=20proposes >>=20>=20that=20the=20root=20service=20uri=20be=20provisioned.=20=20If=20t= his=20offends=20you >>=20>=20that=20much,=20you=20could=20always=20say=20that=20if=20you=20hav= e=20an=20XCAP=20service >>=20>=20root,=20use=20it,=20adding=20cpcp/hishams-weekly-status-meeting=20= to=20it >>=20>=20to=20access=20the=20policy=20for=20this=20conference. >> >>Yes,=20this=20is=20what=20I=20thought=20of=20also=20when=20I=20earlier=20= agreed=20for=20ad-hoc >>conferences=20to=20have=20a=20default=20policy.=20The=20UA=20can=20then=20= extract=20the userinfo >>part=20of=20the=20URI=20returned=20as=20the=20focus=20address=20and=20us= e=20that=20to manipulate >>the=20policy. > >We=20must=20stop=20talking=20about=20"ad-hoc=20conferences"=20and=20"sche= duled conferences" >-=20there=20is=20no=20such=20thing.=20=20There=20are=20only=20ad-hoc=20me= chanisms=20and scheduled >mechanisms=20to=20create/join=20a=20conference. [Chris=20Boulton]=20I=20totally=20agree.=20=20Whether=20'ad-hoc'=20or=20's= cheduled'=20means are=20used=20to=20create=20a=20conference=20should=20have=20no=20effect=20= -=20a=20conference should=20be=20created=20and=20a=20default=20policy=20applied.=20=20Then,=20= if=20it=20is=20an 'ad-hoc'=20conference,=20a=20participant=20is=20free=20to=20join=20and=20i= f=20it=20is=20a scheduled,=20the=20creator=20may=20manipulate=20the=20conference=20policy.= =20=20 > >I=20don't=20think=20there=20has=20ever=20been=20consensus=20on=20a=20requ= irement=20that=20the >policy=20URI=20be=20guessable=20from=20the=20Conference=20URI. > >>=20=20The=20host=20of=20the=20policy=20server=20and=20the=20focus=20need= s=20to=20create=20such policy >>=20and=20therefore=20needs=20to=20either=20assign=20conference=20URIs=20= or=20learn=20then=20to >>=20enable=20it=20to=20create=20the=20policy. >> >>so: >> >>INVITE--> >>200<--=20with=20contact:=20sip:conf123@example.com >> >> >>CPCP=20(assuming=20xcap)=20can=20be: >> >>GET=20http://example.com/conference/hisham/conf123 >> >>should=20work. >> >>/Hisham >> > >So,=20if=20The=20Example=20Company=20already=20has=20their=20public=20web= =20server=20home page=20at >example.com=20where=20everyone=20goes=20to=20download=20the=20latest=20ex= amples,=20this web >server=20now=20needs=20to=20become=20the=20conference=20policy=20server? > >There=20are=20significant=20disadvantages=20in=20limiting=20ourselves=20t= o=20such >conventions=20-=20especially=20when=20there=20are=20other=20ways=20of=20d= iscovering=20the >policy=20URI.=20=20One=20way=20that=20has=20been=20discussed=20is=20adver= tising=20the=20policy URI >in=20conference=20package=20notifications.=20=20Is=20this=20not=20suffici= ent?=20=20This >approach=20is=20flexible=20and=20extensible=20(different=20protocols=20fo= r=20policy >manipulation=20can=20be=20defined=20with=20a=20new=20URI=20scheme)=20and=20= has=20none=20of=20the name >space=20limitations=20of=20this=20proposal. [Chris=20Boulton]=20This=20approach=20does=20seem=20to=20'shoe-horn'=20the= =20HTTP=20usage and=20IMHO=20is=20quite=20an=20ugly=20solution.=20=20As=20Alan=20points=20= out,=20policy=20URI contained=20in=20conference=20packages=20is=20a=20far=20more=20elegant=20s= olution. > >Thanks, >Alan=20Johnston >MCI >sip:alan@sipstation.com > > > > >>_______________________________________________ >>XCON=20mailing=20list >>XCON@ietf.org >>https://www1.ietf.org/mailman/listinfo/xcon > > >_______________________________________________ >XCON=20mailing=20list >XCON@ietf.org >https://www1.ietf.org/mailman/listinfo/xcon > >_______________________________________________________________________ _ >This=20email=20has=20been=20scanned=20for=20all=20viruses=20by=20the=20Me= ssageLabs=20Email >Security=20System.=20For=20more=20information=20on=20a=20proactive=20emai= l=20security >service=20working=20around=20the=20clock,=20around=20the=20globe,=20visit= >http://www.messagelabs.com >_______________________________________________________________________ _ ________________________________________________________________________ This=20email=20has=20been=20scanned=20for=20all=20viruses=20by=20the=20Mes= sageLabs=20Email Security=20System.=20For=20more=20information=20on=20a=20proactive=20email= =20security service=20working=20around=20the=20clock,=20around=20the=20globe,=20visit http://www.messagelabs.com ________________________________________________________________________ _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Wed Dec 3 13:53:04 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29058 for ; Wed, 3 Dec 2003 13:53:04 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARc7E-0006dH-EV for xcon-archive@odin.ietf.org; Wed, 03 Dec 2003 13:52:49 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB3Iqm6g025489 for xcon-archive@odin.ietf.org; Wed, 3 Dec 2003 13:52:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARc7E-0006d2-5Q for xcon-web-archive@optimus.ietf.org; Wed, 03 Dec 2003 13:52:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29032 for ; Wed, 3 Dec 2003 13:52:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARc7B-0006Va-00 for xcon-web-archive@ietf.org; Wed, 03 Dec 2003 13:52:45 -0500 Received: from manatick.foretec.com ([4.17.168.5] helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1ARc7B-0006Un-00 for xcon-web-archive@ietf.org; Wed, 03 Dec 2003 13:52:45 -0500 Received: from [132.151.6.22] (helo=optimus.ietf.org) by manatick with esmtp (Exim 4.24) id 1ARc1g-0002dk-6K for xcon-web-archive@ietf.org; Wed, 03 Dec 2003 13:47:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARc1c-0006EX-Cf; Wed, 03 Dec 2003 13:47:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARc1O-0006CH-F6 for xcon@optimus.ietf.org; Wed, 03 Dec 2003 13:46:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28772 for ; Wed, 3 Dec 2003 13:46:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARc1M-0006QJ-00 for xcon@ietf.org; Wed, 03 Dec 2003 13:46:44 -0500 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 1ARc1L-0006Oh-00 for xcon@ietf.org; Wed, 03 Dec 2003 13:46:43 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA20677; Wed, 3 Dec 2003 13:46:07 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA07415; Wed, 3 Dec 2003 13:46:05 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Dec 2003 13:46:04 -0500 Message-ID: <313680C9A886D511A06000204840E1CF070B6169@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Chris Boulton'" , Alan Johnston , hisham.khartabil@nokia.com, pkyzivat@cisco.com Cc: rohan@cisco.com, georg.mayer@nokia.com, oritl@microsoft.com, xcon@ietf.org Subject: RE: [XCON] Chicken and Egg - Can CPCP create a conference Date: Wed, 3 Dec 2003 13:46:02 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , > >We must stop talking about "ad-hoc conferences" and "scheduled > conferences" > >- there is no such thing. There are only ad-hoc mechanisms and > scheduled > >mechanisms to create/join a conference. Which, I think, is completely useless. And, to be specific: There is no difference in how you join a conference You always send an INVITE, or get a REFER, or receive an INVITE. You can't join with CPCP. There is no reason to have a difference to create one > > [Chris Boulton] I totally agree. Whether 'ad-hoc' or > 'scheduled' means > are used to create a conference should have no effect - a conference > should be created and a default policy applied. Then, if it is an > 'ad-hoc' conference, a participant is free to join and if it is a > scheduled, the creator may manipulate the conference policy. Why is it different with ad-hoc that a participant is free to join? Why is it different with scheduled that the creator may manipulate the conference policy? I think there is no difference at all. No matter how you create it, participants are free to join any time the policy says they pay. No matter how you create it, the creator may manipulate the conference policy (and participants may manipulate it also, subject to permissions). > >So, if The Example Company already has their public web server home > page at > >example.com where everyone goes to download the latest examples, this > web > >server now needs to become the conference policy server? No, unless the example.com is also the focus host. If it is, then the web server is there too. That is just not a limitation worth worrying about. > > > >There are significant disadvantages in limiting ourselves to such > >conventions - especially when there are other ways of discovering the > >policy URI. One way that has been discussed is advertising > the policy > URI > >in conference package notifications. Is this not sufficient? This > >approach is flexible and extensible (different protocols for policy > >manipulation can be defined with a new URI scheme) and has > none of the > name > >space limitations of this proposal. > > [Chris Boulton] This approach does seem to 'shoe-horn' the HTTP usage > and IMHO is quite an ugly solution. As Alan points out, policy URI > contained in conference packages is a far more elegant solution. > My problem is that we seem to be heading to a solution where there is no subset of capabilities. To do anything, you need to implement: cc conference AND cpcp AND mpcp AND the conference package There are no simple implementations other than conference unaware. Is that really what we want to do? Intertwine all the pieces so that there is no clean functional separation that allows implementation flexibility without creating incompatibility? In this specific case, why do you have to implement the conference package in order to discover the conference policy uri? A message or two ago, Alan talked about automata manipulating conference policy, and you were aghast that I proposed using SIP means to create a conference ID. You now want the automata to use SIP means to find a conference policy URI given a conference URI; they even have to join the conference to do so, unless the automata created the conference in the first place, where it may get the conference policy uri returned to it). Can't we give up a slight amount of flexibility to get the possibility of more widespread use of this facility by limiting implementation complexity? Maybe we need some use case stuff to see how subsets might be useful. _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Wed Dec 3 14:18:26 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29833 for ; Wed, 3 Dec 2003 14:18:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARcVi-0007Vu-OI for xcon-archive@odin.ietf.org; Wed, 03 Dec 2003 14:18:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB3JI63c028883 for xcon-archive@odin.ietf.org; Wed, 3 Dec 2003 14:18:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARcVi-0007Vm-IC for xcon-web-archive@optimus.ietf.org; Wed, 03 Dec 2003 14:18:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29806 for ; Wed, 3 Dec 2003 14:17:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARcVg-0006p9-00 for xcon-web-archive@ietf.org; Wed, 03 Dec 2003 14:18:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARcVf-0006p5-00 for xcon-web-archive@ietf.org; Wed, 03 Dec 2003 14:18:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARcVc-0007VB-DK; Wed, 03 Dec 2003 14:18:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARcVO-0007TP-H2 for xcon@optimus.ietf.org; Wed, 03 Dec 2003 14:17:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29798 for ; Wed, 3 Dec 2003 14:17:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARcVL-0006ou-00 for xcon@ietf.org; Wed, 03 Dec 2003 14:17:43 -0500 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 1ARcVK-0006oj-00 for xcon@ietf.org; Wed, 03 Dec 2003 14:17:43 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA22007; Wed, 3 Dec 2003 14:17:07 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA12703; Wed, 3 Dec 2003 14:17:08 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Dec 2003 14:17:07 -0500 Message-ID: <313680C9A886D511A06000204840E1CF070B616B@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Alan Johnston'" , "'Paul Kyzivat'" Cc: "'Heil Franca Marcelo'" , hisham.khartabil@nokia.com, rohan@cisco.com, georg.mayer@nokia.com, oritl@microsoft.com, xcon@ietf.org Subject: RE: [XCON] Chicken and Egg - Can CPCP create a conference Date: Wed, 3 Dec 2003 14:17:02 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , I delayed sending an answer to this to get another reply out. I dealt with a couple of issues here already. I don't want to beat a dead horse on the conference factory URI. If proxies are automatically forwarding calls when they shouldn't be (3261 says that the CLIENT should retry), we can't use that. We could, of course, define a new 3xx response for this purpose. I don't want to establish a dialog, for sure. If it doesn't work, it doesn't work, and I think we are better off just making CPCP the only way to create a conference. My only hesitation is the "subset" argument I just made. A relatively dumb phone with a "Conference" button could do what they do now with only SIP means if the conference factory uri was implemented. It could not manipulate policy, but it's still a useful subset of functionality. Having to implement CPCP just to create the conference is doing what I don't want to do. If we do allow both, then we need to require that a conference service must implement both if it implements any SIP functionality. I can just see some conference server implementer deciding that since he isn't going to implement any policy mechanisms he will only implement the SIP conference factory mechanism, and then hit a phone that decided it was always going to use CPCP to create every conference. Brian > -----Original Message----- > From: Alan Johnston [mailto:alan.johnston@mci.com] > Sent: Wednesday, December 03, 2003 10:10 AM > To: Rosen, Brian; 'Paul Kyzivat' > Cc: 'Heil Franca Marcelo'; hisham.khartabil@nokia.com; > rohan@cisco.com; > georg.mayer@nokia.com; oritl@microsoft.com; xcon@ietf.org > Subject: RE: [XCON] Chicken and Egg - Can CPCP create a conference > > > At 08:15 AM 12/3/2003 -0500, Rosen, Brian wrote: > >I'm arguing that there is no advantage for two mechanisms to start > >conferences. > >I prefer a SIP way, but I'll reluctantly except a CPCP way. > > > >First, let's observe that the "creator" of the conference has to be > >conference aware. A non-conference aware participant can be given > >a URI he don't understands is a conference URI, INVITE to > it, and he's in. > >Similarly, he can get a REFER to some URI and get in that way. > > > >So, one could define the mechanism to always be that you > send an INVITE > >to a conference Factory URI, which always returns a 3xx response with > >a Contact containing the conference URI. Given the > conference URI you > >could INVITE immediately (ad=hoc) or wait until some time later. You > >can use the conference URI to modify the policy of the > conference before > >or after the conference starts. Everything works fine. > > No, I'm afraid not. Many proxies automatically recurse on 3xx > responses. As a result, even if we somehow say that a > conference factory > MUST redirect, the result would often be the establishment of a > session. Now what, the application has to send a BYE to > disconnect since > the conference is not until next week? Will my conference > server see a > steady stream of 1 second, single participant conferences? Yuk! > > Also, I expect that many of the protocols developed here in > XCON will be > used to applications and automata. These applications will > not have a SIP > UA. Will we force them to have a SIP UA so they can send an > INVITE which > will always be followed by a BYE just to get a Conference > URI? Besides the > CPCP security mechanisms, now this application will need SIP > security/authentication/firewall/NAT traversal issues - again, yuk! > > XCON protocols must stand on their own - having a way to > create and get a > Conference URI seems like a critical element. > > > >Similarly, you could always use CPCP to get a conference URI, INVITE > >immediately or later, modify the policy now or later, etc. > Everything works > >fine. > > > >What is the difference in the result of these two mechanisms? > > Nothing > > > >What is the advantage of one mechanism over another? > > A UA which only did ad-hoc has a trivial > implementation if you use > > the conference factory URI as long as the default policy was > >acceptable > > > > I don't see any other difference. > > > > This small difference argues for the conference > factory uri choice > > > >Now, suppose, as has been proposed, the conference factory > URI doesn't > >work the way I think, rather it immediately instantiates the > conference. > >What is the difference? > > a) you save the second INVITE (2 messages per conference) > > b) you need another mechanism for a pre-established > conference > > > >I expect most implementations of conference aware UAs will > support both > >ad-hoc and pre-established. One mechanism is preferred. I > don't think > >you will see a UA implementation that does pre-established > only. That > >argues for the conference factory uri choice. > > As I have argued above, many endpoints besides UAs will use > our protocols > to create conferences - requiring them to implement SIP and > send an INVITE > that doesn't establish a session is just a bad idea. > > Thanks, > Alan Johnston > MCI > sip:alan@sipstation.com > > > >The worst situation is that there are two equivalent > mechanisms and there > >are implementations that only do one. That would create incompatible > >implementations. > > > >Brian > > > > > -----Original Message----- > > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > > Sent: Tuesday, December 02, 2003 2:22 PM > > > To: Rosen, Brian > > > Cc: 'Heil Franca Marcelo'; 'Alan Johnston'; > > > hisham.khartabil@nokia.com; > > > rohan@cisco.com; georg.mayer@nokia.com; oritl@microsoft.com; > > > xcon@ietf.org > > > Subject: Re: [XCON] Chicken and Egg - Can CPCP create a conference > > > > > > > > > > > > > > > Rosen, Brian wrote: > > > > Well, now you might see why I think the Conference Factory URI > > > > does not instantiate a conference; it just returns a > conference ID. > > > > That way, you could, if you wanted to, change the default policy > > > > before you "started" it. > > > > > > It is my understanding that the Conference Factory URI is used by > > > sending an INVITE to it. So how is it supposed to return a > > > conference ID > > > without also "starting" the conference? Typically the > result of the > > > INVITE will be a dialog with the focus, with the address > of the focus > > > being returned as the Contact. Or are you assuming that Conference > > > Factory URI will *always* return a 3xx rather than > > > establishing the dialog? > > > > > > I would hate to write an application for creating/configuring a > > > conference that sends and INVITE but depends on it not > > > succeeding - so > > > that if it is surprised by having the INVITE succeed it barfs. > > > > > > I think sending an invite to a Conference Factory URI > should only be > > > used when the UAC wants to participate in a new conference > > > that starts > > > *now*. > > > > > > If you want to establish a name and policy for a > conference to take > > > place later, then I think you must use other means. > > > > > > Paul > > > > > > > > > _______________________________________________ > > > XCON mailing list > > > XCON@ietf.org > > > https://www1.ietf.org/mailman/listinfo/xcon > > > > > > >_______________________________________________ > >XCON mailing list > >XCON@ietf.org > >https://www1.ietf.org/mailman/listinfo/xcon > _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Wed Dec 3 14:32:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00318 for ; Wed, 3 Dec 2003 14:32:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARcjD-0007pc-Ay for xcon-archive@odin.ietf.org; Wed, 03 Dec 2003 14:32:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB3JW3ex030098 for xcon-archive@odin.ietf.org; Wed, 3 Dec 2003 14:32:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARcjD-0007pN-5W for xcon-web-archive@optimus.ietf.org; Wed, 03 Dec 2003 14:32:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00282 for ; Wed, 3 Dec 2003 14:31:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARcjA-0006zv-00 for xcon-web-archive@ietf.org; Wed, 03 Dec 2003 14:32:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARcjA-0006zs-00 for xcon-web-archive@ietf.org; Wed, 03 Dec 2003 14:32:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARcjB-0007oP-Fh; Wed, 03 Dec 2003 14:32:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARciF-0007nS-Go for xcon@optimus.ietf.org; Wed, 03 Dec 2003 14:31:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00221 for ; Wed, 3 Dec 2003 14:30:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARciC-0006xa-00 for xcon@ietf.org; Wed, 03 Dec 2003 14:31:00 -0500 Received: from dgesmtp02.wcom.com ([199.249.16.17]) by ietf-mx with esmtp (Exim 4.12) id 1ARciB-0006xI-00 for xcon@ietf.org; Wed, 03 Dec 2003 14:30:59 -0500 Received: from pmismtp01.wcomnet.com ([166.38.62.36]) by firewall.wcom.com (Iplanet MTA 5.2) with ESMTP id <0HPC00AC4383KI@firewall.wcom.com> for xcon@ietf.org; Wed, 03 Dec 2003 19:24:03 +0000 (GMT) Received: from pmismtp01.wcomnet.com by pmismtp01.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0HPC00D0133F43@pmismtp01.wcomnet.com>; Wed, 03 Dec 2003 19:24:03 +0000 (GMT) Received: from xs578v3521.mci.com ([166.50.104.75]) by pmismtp01.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0HPC00CCK36CMV@pmismtp01.wcomnet.com>; Wed, 03 Dec 2003 19:23:02 +0000 (GMT) Date: Wed, 03 Dec 2003 13:22:59 -0600 From: Alan Johnston Subject: RE: [XCON] Chicken and Egg - Can CPCP create a conference X-Sender: Alan.Johnston@pop.mcit.com To: "Rosen, Brian" Cc: xcon@ietf.org Message-id: <5.2.1.1.0.20031203130317.02a2da18@pop.mcit.com> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Content-type: text/plain; charset=us-ascii; format=flowed Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , (trimmed cc list since we're all on the XCON list) At 01:46 PM 12/3/2003 -0500, Rosen, Brian wrote: > > >We must stop talking about "ad-hoc conferences" and "scheduled > > conferences" > > >- there is no such thing. There are only ad-hoc mechanisms and > > scheduled > > >mechanisms to create/join a conference. >Which, I think, is completely useless. >And, to be specific: > There is no difference in how you join a conference > You always send an INVITE, or get a REFER, > or receive an INVITE. You can't join with > CPCP. > There is no reason to have a difference to create one > The reason is exactly the point you make below - to have a subset of capabilities. Many UAs can just support cc-conferencing, and have the ability to create a conference, invite participants, eject participants, etc. If they want to be able to know who is on the conference, they need to support the conference package. If they want to be able to manipulate the policy, they need to support CPCP. Note that CPCP *does not* contain information about the state of the conference - that's what the conference package is for. A participant can not use CPCP to add participants, eject participants, etc if it doesn't know the state of the conference (ie who is in the conference). This separation of state and policy is a critical one - if you disagree then we'd better discuss it now. > > > > [Chris Boulton] I totally agree. Whether 'ad-hoc' or > > 'scheduled' means > > are used to create a conference should have no effect - a conference > > should be created and a default policy applied. Then, if it is an > > 'ad-hoc' conference, a participant is free to join and if it is a > > scheduled, the creator may manipulate the conference policy. >Why is it different with ad-hoc that a participant is free to join? >Why is it different with scheduled that the creator may manipulate >the conference policy? > >I think there is no difference at all. No matter how you create it, >participants are free to join any time the policy says they pay. >No matter how you create it, the creator may manipulate the conference >policy (and participants may manipulate it also, subject to permissions). > > > > >So, if The Example Company already has their public web server home > > page at > > >example.com where everyone goes to download the latest examples, this > > web > > >server now needs to become the conference policy server? >No, unless the example.com is also the focus host. If it is, then the >web server is there too. That is just not a limitation worth worrying >about. Look at Hisham's example - they are the same. One can get around it by having an application server that does 3pcc, or some sort of HTTP proxy, but why require all this complexity? Why must my media server be my policy server as well? As another example, I have the domain sipstation.com which I use for my own SIP network with a proxy at my house. However, my web page is hosted by a provider. If I setup a conference service, would I be forced to host my own web server just so I can assign Conference URIs with the domain sipstation.com? Or do I have to get my web hosting company to run my policy server? This is a serious, serious URI naming limitation. > > > > > >There are significant disadvantages in limiting ourselves to such > > >conventions - especially when there are other ways of discovering the > > >policy URI. One way that has been discussed is advertising > > the policy > > URI > > >in conference package notifications. Is this not sufficient? This > > >approach is flexible and extensible (different protocols for policy > > >manipulation can be defined with a new URI scheme) and has > > none of the > > name > > >space limitations of this proposal. > > > > [Chris Boulton] This approach does seem to 'shoe-horn' the HTTP usage > > and IMHO is quite an ugly solution. As Alan points out, policy URI > > contained in conference packages is a far more elegant solution. > > >My problem is that we seem to be heading to a solution where there >is no subset of capabilities. To do anything, you need to implement: > cc conference >AND > cpcp >AND > mpcp >AND > the conference package > >There are no simple implementations other than conference unaware. >Is that really what we want to do? Intertwine all the pieces so that >there is no clean functional separation that allows implementation >flexibility without creating incompatibility? In this specific >case, why do you have to implement the conference package in order >to discover the conference policy uri? > >A message or two ago, Alan talked about automata manipulating conference >policy, and you were aghast that I proposed using SIP means to >create a conference ID. You now want the automata to use SIP means >to find a conference policy URI given a conference URI; they even have >to join the conference to do so, unless the automata created the >conference in the first place, where it may get the conference policy >uri returned to it). No. If CPCP allows a conference to be created, there must be a URI for it (similar to the Conference Factory URI) which must be provisioned. The automata would use this URI to create the conference, receive the Conference URI. Now, the automata's interest in the conference is over - it has created it and set it up. It can send out notifications, etc. do whatever it wants. However, if the automata wants to use CPCP during the conference do do real-time things, then it needs to know the current state of the conference - the policy does not have this information in it. As a result, it should subscribe to the conference package. >Can't we give up a slight amount of flexibility to get the possibility >of more widespread use of this facility by limiting implementation >complexity? Maybe we need some use case stuff to see how subsets might >be useful. > I understand your concern about having two ways to do certain things. However, there will be two users of CPCP - actual conference participants, and applications that never ever will be participants. Forcing only one way will seriously affect one of these two users - I'm not prepared to do this. Thanks, Alan Johnston MCI sip:alan@sipstation.com _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Wed Dec 3 14:38:27 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00592 for ; Wed, 3 Dec 2003 14:38:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARcp7-0008QE-74 for xcon-archive@odin.ietf.org; Wed, 03 Dec 2003 14:38:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB3Jc9Nd032368 for xcon-archive@odin.ietf.org; Wed, 3 Dec 2003 14:38:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARcp6-0008Pz-O1 for xcon-web-archive@optimus.ietf.org; Wed, 03 Dec 2003 14:38:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00575 for ; Wed, 3 Dec 2003 14:37:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARcp4-00074s-00 for xcon-web-archive@ietf.org; Wed, 03 Dec 2003 14:38:06 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARcp3-00074k-00 for xcon-web-archive@ietf.org; Wed, 03 Dec 2003 14:38:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARcp0-0008NB-GR; Wed, 03 Dec 2003 14:38:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARcol-0008Jx-Uk for xcon@optimus.ietf.org; Wed, 03 Dec 2003 14:37:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00562 for ; Wed, 3 Dec 2003 14:37:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARcoh-00074J-00 for xcon@ietf.org; Wed, 03 Dec 2003 14:37:43 -0500 Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx with esmtp (Exim 4.12) id 1ARcog-000742-00 for xcon@ietf.org; Wed, 03 Dec 2003 14:37:43 -0500 Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1041); Wed, 3 Dec 2003 11:37:29 -0800 Received: from 157.54.5.25 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 03 Dec 2003 11:37:10 -0800 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by inet-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 3 Dec 2003 11:37:00 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] Chicken and Egg - Can CPCP create a conference Date: Wed, 3 Dec 2003 11:36:16 -0800 Message-ID: Thread-Topic: [XCON] Chicken and Egg - Can CPCP create a conference Thread-Index: AcO50g0ENNm/Nb4rQwi17YYtv4hWPQAAb1Ug From: "Orit Levin" To: "Rosen, Brian" , "Alan Johnston" , "Paul Kyzivat" Cc: "Heil Franca Marcelo" , , , , X-OriginalArrivalTime: 03 Dec 2003 19:37:00.0952 (UTC) FILETIME=[D2555980:01C3B9D4] Content-Transfer-Encoding: quoted-printable Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable ***I vote for this conclusion***=20 with a slight rewording: An XCON-compliant conference server MUST implement conference creation using XCON. (We, XCON, can not prescribe general conferencing behavior for every possible server.) Orit. -----Original Message----- From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org] On Behalf Of Rosen, Brian Sent: Wednesday, December 03, 2003 11:17 AM To: 'Alan Johnston'; 'Paul Kyzivat' Cc: 'Heil Franca Marcelo'; hisham.khartabil@nokia.com; rohan@cisco.com; georg.mayer@nokia.com; Orit Levin; xcon@ietf.org Subject: RE: [XCON] Chicken and Egg - Can CPCP create a conference -- skip If we do allow both, then we need to require that a conference service must implement both if it implements any SIP functionality. I can just see some conference server implementer deciding that since he isn't going to implement any policy mechanisms he will only implement the SIP conference factory mechanism, and then hit a phone that decided it was always going to use CPCP to create every conference. Brian > -----Original Message----- > From: Alan Johnston [mailto:alan.johnston@mci.com] > Sent: Wednesday, December 03, 2003 10:10 AM > To: Rosen, Brian; 'Paul Kyzivat' > Cc: 'Heil Franca Marcelo'; hisham.khartabil@nokia.com;=20 > rohan@cisco.com; georg.mayer@nokia.com; oritl@microsoft.com;=20 > xcon@ietf.org > Subject: RE: [XCON] Chicken and Egg - Can CPCP create a conference >=20 >=20 > At 08:15 AM 12/3/2003 -0500, Rosen, Brian wrote: > >I'm arguing that there is no advantage for two mechanisms to start=20 > >conferences. > >I prefer a SIP way, but I'll reluctantly except a CPCP way. > > > >First, let's observe that the "creator" of the conference has to be=20 > >conference aware. A non-conference aware participant can be given a=20 > >URI he don't understands is a conference URI, INVITE to > it, and he's in. > >Similarly, he can get a REFER to some URI and get in that way. > > > >So, one could define the mechanism to always be that you > send an INVITE > >to a conference Factory URI, which always returns a 3xx response with > >a Contact containing the conference URI. Given the > conference URI you > >could INVITE immediately (ad=3Dhoc) or wait until some time later. = You > >can use the conference URI to modify the policy of the > conference before > >or after the conference starts. Everything works fine. >=20 > No, I'm afraid not. Many proxies automatically recurse on 3xx=20 > responses. As a result, even if we somehow say that a conference=20 > factory MUST redirect, the result would often be the establishment of=20 > a session. Now what, the application has to send a BYE to disconnect=20 > since the conference is not until next week? Will my conference=20 > server see a steady stream of 1 second, single participant=20 > conferences? Yuk! >=20 > Also, I expect that many of the protocols developed here in XCON will=20 > be used to applications and automata. These applications will not=20 > have a SIP UA. Will we force them to have a SIP UA so they can send=20 > an INVITE which will always be followed by a BYE just to get a=20 > Conference URI? Besides the CPCP security mechanisms, now this=20 > application will need SIP security/authentication/firewall/NAT=20 > traversal issues - again, yuk! >=20 > XCON protocols must stand on their own - having a way to create and=20 > get a Conference URI seems like a critical element. >=20 >=20 > >Similarly, you could always use CPCP to get a conference URI, INVITE > >immediately or later, modify the policy now or later, etc. =20 > Everything works > >fine. > > > >What is the difference in the result of these two mechanisms? > > Nothing > > > >What is the advantage of one mechanism over another? > > A UA which only did ad-hoc has a trivial=20 > implementation if you use > > the conference factory URI as long as the default policy was > >acceptable > > > > I don't see any other difference. > > > > This small difference argues for the conference=20 > factory uri choice > > > >Now, suppose, as has been proposed, the conference factory=20 > URI doesn't > >work the way I think, rather it immediately instantiates the=20 > conference. > >What is the difference? > > a) you save the second INVITE (2 messages per conference) > > b) you need another mechanism for a pre-established=20 > conference > > > >I expect most implementations of conference aware UAs will=20 > support both > >ad-hoc and pre-established. One mechanism is preferred. I=20 > don't think > >you will see a UA implementation that does pre-established=20 > only. That > >argues for the conference factory uri choice. >=20 > As I have argued above, many endpoints besides UAs will use=20 > our protocols=20 > to create conferences - requiring them to implement SIP and=20 > send an INVITE=20 > that doesn't establish a session is just a bad idea. >=20 > Thanks, > Alan Johnston > MCI > sip:alan@sipstation.com >=20 >=20 > >The worst situation is that there are two equivalent=20 > mechanisms and there > >are implementations that only do one. That would create incompatible > >implementations. > > > >Brian > > > > > -----Original Message----- > > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > > Sent: Tuesday, December 02, 2003 2:22 PM > > > To: Rosen, Brian > > > Cc: 'Heil Franca Marcelo'; 'Alan Johnston'; > > > hisham.khartabil@nokia.com; > > > rohan@cisco.com; georg.mayer@nokia.com; oritl@microsoft.com; > > > xcon@ietf.org > > > Subject: Re: [XCON] Chicken and Egg - Can CPCP create a conference > > > > > > > > > > > > > > > Rosen, Brian wrote: > > > > Well, now you might see why I think the Conference Factory URI > > > > does not instantiate a conference; it just returns a=20 > conference ID. > > > > That way, you could, if you wanted to, change the default policy > > > > before you "started" it. > > > > > > It is my understanding that the Conference Factory URI is used by > > > sending an INVITE to it. So how is it supposed to return a > > > conference ID > > > without also "starting" the conference? Typically the=20 > result of the > > > INVITE will be a dialog with the focus, with the address=20 > of the focus > > > being returned as the Contact. Or are you assuming that Conference > > > Factory URI will *always* return a 3xx rather than > > > establishing the dialog? > > > > > > I would hate to write an application for creating/configuring a > > > conference that sends and INVITE but depends on it not > > > succeeding - so > > > that if it is surprised by having the INVITE succeed it barfs. > > > > > > I think sending an invite to a Conference Factory URI=20 > should only be > > > used when the UAC wants to participate in a new conference > > > that starts > > > *now*. > > > > > > If you want to establish a name and policy for a=20 > conference to take > > > place later, then I think you must use other means. > > > > > > Paul > > > > > > > > > _______________________________________________ > > > XCON mailing list > > > XCON@ietf.org > > > https://www1.ietf.org/mailman/listinfo/xcon > > > > > > >_______________________________________________ > >XCON mailing list > >XCON@ietf.org > >https://www1.ietf.org/mailman/listinfo/xcon >=20 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Wed Dec 3 14:47:16 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01069 for ; Wed, 3 Dec 2003 14:47:16 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARcxi-0000I8-F2 for xcon-archive@odin.ietf.org; Wed, 03 Dec 2003 14:47:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB3Jl2L6001114 for xcon-archive@odin.ietf.org; Wed, 3 Dec 2003 14:47:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARcxi-0000Ht-5l for xcon-web-archive@optimus.ietf.org; Wed, 03 Dec 2003 14:47:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01066 for ; Wed, 3 Dec 2003 14:46:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARcxe-0007GJ-00 for xcon-web-archive@ietf.org; Wed, 03 Dec 2003 14:46:58 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARcxe-0007GG-00 for xcon-web-archive@ietf.org; Wed, 03 Dec 2003 14:46:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARcxg-0000Hg-HO; Wed, 03 Dec 2003 14:47:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARcxd-0000HV-4p for xcon@optimus.ietf.org; Wed, 03 Dec 2003 14:46:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01063 for ; Wed, 3 Dec 2003 14:46:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARcxa-0007GD-00 for xcon@ietf.org; Wed, 03 Dec 2003 14:46:54 -0500 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 1ARcxZ-0007Et-00 for xcon@ietf.org; Wed, 03 Dec 2003 14:46:53 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA23271; Wed, 3 Dec 2003 14:46:11 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA18048; Wed, 3 Dec 2003 14:46:12 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Dec 2003 14:46:11 -0500 Message-ID: <313680C9A886D511A06000204840E1CF070B616D@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Orit Levin'" , Alan Johnston , Paul Kyzivat Cc: Heil Franca Marcelo , hisham.khartabil@nokia.com, rohan@cisco.com, georg.mayer@nokia.com, xcon@ietf.org Subject: RE: [XCON] Chicken and Egg - Can CPCP create a conference Date: Wed, 3 Dec 2003 14:46:01 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , Orit This is just what I want to avoid. With this definition, you could create a conference service that did not support a conference factory URI, and yet was otherwise SIP-compliant. That means a phone could implement the conference factory uri, and wouldn't be compatible with your service. I explicitly said > must implement both if it implements any SIP functionality. Brian > -----Original Message----- > From: Orit Levin [mailto:oritl@microsoft.com] > Sent: Wednesday, December 03, 2003 2:36 PM > To: Rosen, Brian; Alan Johnston; Paul Kyzivat > Cc: Heil Franca Marcelo; hisham.khartabil@nokia.com; rohan@cisco.com; > georg.mayer@nokia.com; xcon@ietf.org > Subject: RE: [XCON] Chicken and Egg - Can CPCP create a conference > > > ***I vote for this conclusion*** > > with a slight rewording: > An XCON-compliant conference server MUST implement conference creation > using XCON. > (We, XCON, can not prescribe general conferencing behavior for every > possible server.) > > Orit. > > -----Original Message----- > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org] On Behalf Of > Rosen, Brian > Sent: Wednesday, December 03, 2003 11:17 AM > To: 'Alan Johnston'; 'Paul Kyzivat' > Cc: 'Heil Franca Marcelo'; hisham.khartabil@nokia.com; > rohan@cisco.com; > georg.mayer@nokia.com; Orit Levin; xcon@ietf.org > Subject: RE: [XCON] Chicken and Egg - Can CPCP create a conference > > -- skip > > If we do allow both, then we need to require that a conference service > must implement both if it implements any SIP functionality. > I can just see some conference server implementer deciding > that since he > isn't going to implement any policy mechanisms he will only implement > the SIP conference factory mechanism, and then hit a phone > that decided > it was always going to use CPCP to create every conference. > > Brian > > > -----Original Message----- > > From: Alan Johnston [mailto:alan.johnston@mci.com] > > Sent: Wednesday, December 03, 2003 10:10 AM > > To: Rosen, Brian; 'Paul Kyzivat' > > Cc: 'Heil Franca Marcelo'; hisham.khartabil@nokia.com; > > rohan@cisco.com; georg.mayer@nokia.com; oritl@microsoft.com; > > xcon@ietf.org > > Subject: RE: [XCON] Chicken and Egg - Can CPCP create a conference > > > > > > At 08:15 AM 12/3/2003 -0500, Rosen, Brian wrote: > > >I'm arguing that there is no advantage for two mechanisms to start > > >conferences. > > >I prefer a SIP way, but I'll reluctantly except a CPCP way. > > > > > >First, let's observe that the "creator" of the conference > has to be > > >conference aware. A non-conference aware participant can > be given a > > >URI he don't understands is a conference URI, INVITE to > > it, and he's in. > > >Similarly, he can get a REFER to some URI and get in that way. > > > > > >So, one could define the mechanism to always be that you > > send an INVITE > > >to a conference Factory URI, which always returns a 3xx > response with > > > >a Contact containing the conference URI. Given the > > conference URI you > > >could INVITE immediately (ad=hoc) or wait until some time > later. You > > > >can use the conference URI to modify the policy of the > > conference before > > >or after the conference starts. Everything works fine. > > > > No, I'm afraid not. Many proxies automatically recurse on 3xx > > responses. As a result, even if we somehow say that a conference > > factory MUST redirect, the result would often be the > establishment of > > a session. Now what, the application has to send a BYE to > disconnect > > since the conference is not until next week? Will my conference > > server see a steady stream of 1 second, single participant > > conferences? Yuk! > > > > Also, I expect that many of the protocols developed here in > XCON will > > be used to applications and automata. These applications will not > > have a SIP UA. Will we force them to have a SIP UA so they > can send > > an INVITE which will always be followed by a BYE just to get a > > Conference URI? Besides the CPCP security mechanisms, now this > > application will need SIP security/authentication/firewall/NAT > > traversal issues - again, yuk! > > > > XCON protocols must stand on their own - having a way to create and > > get a Conference URI seems like a critical element. > > > > > > >Similarly, you could always use CPCP to get a conference > URI, INVITE > > >immediately or later, modify the policy now or later, etc. > > Everything works > > >fine. > > > > > >What is the difference in the result of these two mechanisms? > > > Nothing > > > > > >What is the advantage of one mechanism over another? > > > A UA which only did ad-hoc has a trivial > > implementation if you use > > > the conference factory URI as long as the default > policy was > > >acceptable > > > > > > I don't see any other difference. > > > > > > This small difference argues for the conference > > factory uri choice > > > > > >Now, suppose, as has been proposed, the conference factory > > URI doesn't > > >work the way I think, rather it immediately instantiates the > > conference. > > >What is the difference? > > > a) you save the second INVITE (2 messages per conference) > > > b) you need another mechanism for a pre-established > > conference > > > > > >I expect most implementations of conference aware UAs will > > support both > > >ad-hoc and pre-established. One mechanism is preferred. I > > don't think > > >you will see a UA implementation that does pre-established > > only. That > > >argues for the conference factory uri choice. > > > > As I have argued above, many endpoints besides UAs will use > > our protocols > > to create conferences - requiring them to implement SIP and > > send an INVITE > > that doesn't establish a session is just a bad idea. > > > > Thanks, > > Alan Johnston > > MCI > > sip:alan@sipstation.com > > > > > > >The worst situation is that there are two equivalent > > mechanisms and there > > >are implementations that only do one. That would create > incompatible > > >implementations. > > > > > >Brian > > > > > > > -----Original Message----- > > > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > > > Sent: Tuesday, December 02, 2003 2:22 PM > > > > To: Rosen, Brian > > > > Cc: 'Heil Franca Marcelo'; 'Alan Johnston'; > > > > hisham.khartabil@nokia.com; > > > > rohan@cisco.com; georg.mayer@nokia.com; oritl@microsoft.com; > > > > xcon@ietf.org > > > > Subject: Re: [XCON] Chicken and Egg - Can CPCP create a > conference > > > > > > > > > > > > > > > > > > > > Rosen, Brian wrote: > > > > > Well, now you might see why I think the Conference Factory URI > > > > > does not instantiate a conference; it just returns a > > conference ID. > > > > > That way, you could, if you wanted to, change the > default policy > > > > > before you "started" it. > > > > > > > > It is my understanding that the Conference Factory URI > is used by > > > > sending an INVITE to it. So how is it supposed to return a > > > > conference ID > > > > without also "starting" the conference? Typically the > > result of the > > > > INVITE will be a dialog with the focus, with the address > > of the focus > > > > being returned as the Contact. Or are you assuming that > Conference > > > > Factory URI will *always* return a 3xx rather than > > > > establishing the dialog? > > > > > > > > I would hate to write an application for creating/configuring a > > > > conference that sends and INVITE but depends on it not > > > > succeeding - so > > > > that if it is surprised by having the INVITE succeed it barfs. > > > > > > > > I think sending an invite to a Conference Factory URI > > should only be > > > > used when the UAC wants to participate in a new conference > > > > that starts > > > > *now*. > > > > > > > > If you want to establish a name and policy for a > > conference to take > > > > place later, then I think you must use other means. > > > > > > > > Paul > > > > > > > > > > > > _______________________________________________ > > > > XCON mailing list > > > > XCON@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/xcon > > > > > > > > > >_______________________________________________ > > >XCON mailing list > > >XCON@ietf.org > > >https://www1.ietf.org/mailman/listinfo/xcon > > > > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon > > > > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon > _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Wed Dec 3 15:23:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03361 for ; Wed, 3 Dec 2003 15:23:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARdWa-0001X2-Ck for xcon-archive@odin.ietf.org; Wed, 03 Dec 2003 15:23:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB3KN4J0005882 for xcon-archive@odin.ietf.org; Wed, 3 Dec 2003 15:23:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARdWa-0001Wn-79 for xcon-web-archive@optimus.ietf.org; Wed, 03 Dec 2003 15:23:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03354 for ; Wed, 3 Dec 2003 15:22:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARdWY-0007a6-00 for xcon-web-archive@ietf.org; Wed, 03 Dec 2003 15:23:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARdWY-0007a3-00 for xcon-web-archive@ietf.org; Wed, 03 Dec 2003 15:23:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARdWX-0001WV-9x; Wed, 03 Dec 2003 15:23:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARdVq-0001WH-Nh for xcon@optimus.ietf.org; Wed, 03 Dec 2003 15:22:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03327 for ; Wed, 3 Dec 2003 15:22:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARdVp-0007Zm-00 for xcon@ietf.org; Wed, 03 Dec 2003 15:22:17 -0500 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 1ARdVo-0007ZL-00 for xcon@ietf.org; Wed, 03 Dec 2003 15:22:16 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA24701; Wed, 3 Dec 2003 15:21:41 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA25026; Wed, 3 Dec 2003 15:21:40 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Dec 2003 15:21:40 -0500 Message-ID: <313680C9A886D511A06000204840E1CF070B616E@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Alan Johnston'" Cc: xcon@ietf.org Subject: RE: [XCON] Chicken and Egg - Can CPCP create a conference Date: Wed, 3 Dec 2003 15:21:39 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , > >No, unless the example.com is also the focus host. If it > is, then the > >web server is there too. That is just not a limitation worth worrying > >about. > > Look at Hisham's example - they are the same. One can get > around it by > having an application server that does 3pcc, or some sort of > HTTP proxy, > but why require all this complexity? Why must my media > server be my policy > server as well? We're assuming XCAP, right? So a "web server" is not just a web server, it's an XCAP server. If it is the CPCP server; you can't separate the http part from the xcap part from the cpcp part; they are the same thing. If your media server is your conference server (focus), then it's not much of a stretch at all to force it to be your conference policy server, at least now. Now, that doesn't mean that you can't, for example, use the media server as a mixer, and have the focus be part of some proxy server, controlling the mixer with, say, Megaco. It seems pretty impractical to separate the conference policy server from the focus, because they are so intertwined. > > As another example, I have the domain sipstation.com which I > use for my own > SIP network with a proxy at my house. However, my web page > is hosted by a > provider. If I setup a conference service, would I be forced > to host my > own web server just so I can assign Conference URIs with the domain > sipstation.com? Or do I have to get my web hosting company to run my > policy server? I see the point. It would be pretty simple to have your conference server be conference.sipstation.com, regardless of which machine it ran on, right? That would solve the problem, would it not? It doesn't change the address of your end stations, or your proxy server. It does limit (very slightly) the form of the uri for a conference you can use. It's a tradeoff. > > This is a serious, serious URI naming limitation. Doesn't seem very serious. > > > > > > > > > > >There are significant disadvantages in limiting ourselves to such > > > >conventions - especially when there are other ways of > discovering the > > > >policy URI. One way that has been discussed is advertising > > > the policy > > > URI > > > >in conference package notifications. Is this not > sufficient? This > > > >approach is flexible and extensible (different protocols > for policy > > > >manipulation can be defined with a new URI scheme) and has > > > none of the > > > name > > > >space limitations of this proposal. > > > > > > [Chris Boulton] This approach does seem to 'shoe-horn' > the HTTP usage > > > and IMHO is quite an ugly solution. As Alan points out, > policy URI > > > contained in conference packages is a far more elegant solution. > > > > >My problem is that we seem to be heading to a solution where there > >is no subset of capabilities. To do anything, you need to implement: > > cc conference > >AND > > cpcp > >AND > > mpcp > >AND > > the conference package > > > >There are no simple implementations other than conference unaware. > >Is that really what we want to do? Intertwine all the pieces so that > >there is no clean functional separation that allows implementation > >flexibility without creating incompatibility? In this specific > >case, why do you have to implement the conference package in order > >to discover the conference policy uri? > > > >A message or two ago, Alan talked about automata > manipulating conference > >policy, and you were aghast that I proposed using SIP means to > >create a conference ID. You now want the automata to use SIP means > >to find a conference policy URI given a conference URI; they > even have > >to join the conference to do so, unless the automata created the > >conference in the first place, where it may get the conference policy > >uri returned to it). > > No. If CPCP allows a conference to be created, there must be > a URI for it > (similar to the Conference Factory URI) which must be > provisioned. The > automata would use this URI to create the conference, receive the > Conference URI. Now, the automata's interest in the > conference is over - > it has created it and set it up. It can send out > notifications, etc. do > whatever it wants. You just made a leap - the only thing an automata does with cpcp is create a conference. That is not true; it can do many other things before the conference starts. > > However, if the automata wants to use CPCP during the > conference do do > real-time things, then it needs to know the current state of > the conference > - the policy does not have this information in it. As a > result, it should > subscribe to the conference package. The word "policy" is a real joke; claiming that removing a participant by manipulating the policy so that he is not welcome, and having the focus send him a BYE as a consequence lets you say "policy", but there is a wink in your eye fella. It's control and policy. Separating state from control is always pretty iffy. Hard to name a successful protocol that separates state from control of state. You can have one without the other, but it's pretty unusual. If we separated those parts of "policy" that really were not state dependent - those that made sense before the conference was instantiated then maybe separating state from policy would make some sense. > > > >Can't we give up a slight amount of flexibility to get the > possibility > >of more widespread use of this facility by limiting implementation > >complexity? Maybe we need some use case stuff to see how > subsets might > >be useful. > > > > I understand your concern about having two ways to do certain > things. However, there will be two users of CPCP - actual conference > participants, and applications that never ever will be > participants. Forcing only one way will seriously affect one > of these two > users - I'm not prepared to do this. > > Thanks, > Alan Johnston > MCI > sip:alan@sipstation.com > _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Wed Dec 3 15:51:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05344 for ; Wed, 3 Dec 2003 15:51:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARdxh-0003Uj-55 for xcon-archive@odin.ietf.org; Wed, 03 Dec 2003 15:51:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB3Kp54m013427 for xcon-archive@odin.ietf.org; Wed, 3 Dec 2003 15:51:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARdxg-0003UU-RP for xcon-web-archive@optimus.ietf.org; Wed, 03 Dec 2003 15:51:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05228 for ; Wed, 3 Dec 2003 15:50:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARdxe-0000Ez-00 for xcon-web-archive@ietf.org; Wed, 03 Dec 2003 15:51:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARdxe-0000Eq-00 for xcon-web-archive@ietf.org; Wed, 03 Dec 2003 15:51:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARdxe-0003To-MM; Wed, 03 Dec 2003 15:51:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARdx8-0003SN-TQ for xcon@optimus.ietf.org; Wed, 03 Dec 2003 15:50:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05165 for ; Wed, 3 Dec 2003 15:50:14 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARdx6-0000Cq-00 for xcon@ietf.org; Wed, 03 Dec 2003 15:50:28 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1ARdx5-0000Cl-00 for xcon@ietf.org; Wed, 03 Dec 2003 15:50:28 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hB3KoPw04328 for ; Wed, 3 Dec 2003 22:50:25 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 3 Dec 2003 17:17:17 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 3 Dec 2003 17:17:16 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] Chicken and Egg - Can CPCP create a conference Date: Wed, 3 Dec 2003 17:17:16 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB70118B11C@esebe019.ntc.nokia.com> Thread-Topic: [XCON] Chicken and Egg - Can CPCP create a conference Thread-Index: AcO5poItQ5DQueqZRm2rlTeG2rZeJwAB4FBw To: , Cc: , , , , , X-OriginalArrivalTime: 03 Dec 2003 15:17:16.0906 (UTC) FILETIME=[8984A4A0:01C3B9B0] Content-Transfer-Encoding: quoted-printable Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable I have to admit I am beginning to warm up to Brain's ideas about = choosing one way to create a conference, but not fully. I can agree that = one protocol is used to create a conference, SIP. I don't like the idea of using INVITE/3xx/INVITE/200 to create a = conference. There needs to be a mechanism to create a conference = immediately (ad hoc), one round trip. This is very important. I think = INVITE should create that type of conference. I agree now that a policy = can be created for this ad-hoc conference that in manipulatable using = CPCP. We can define a new SIP method to schedule a conference. Something like = SCHEDULE. Also, this mechanism does not allow the user to suggest a = conference ID, so we can create a conf-ID URI parameter that can be = place in the request URI: SCHEDULE sip:conferencefactory@example.com;conf-ID=3Dconf12@example.com To: From: ... This also creates that manipulatable default policy using CPCP. Regards, Hisham > -----Original Message----- > From: ext Rosen, Brian [mailto:Brian.Rosen@marconi.com] > Sent: 03.December.2003 15:16 > To: 'Paul Kyzivat' > Cc: 'Heil Franca Marcelo'; 'Alan Johnston'; Khartabil Hisham > (NMP-MSW/Helsinki); rohan@cisco.com; Mayer Georg (NMP-MSW/Helsinki); > oritl@microsoft.com; xcon@ietf.org > Subject: RE: [XCON] Chicken and Egg - Can CPCP create a conference >=20 >=20 > I'm arguing that there is no advantage for two mechanisms to start > conferences. > I prefer a SIP way, but I'll reluctantly except a CPCP way. >=20 > First, let's observe that the "creator" of the conference has to be > conference aware. A non-conference aware participant can be given > a URI he don't understands is a conference URI, INVITE to it,=20 > and he's in. > Similarly, he can get a REFER to some URI and get in that way. =20 >=20 > So, one could define the mechanism to always be that you send=20 > an INVITE > to a conference Factory URI, which always returns a 3xx response with > a Contact containing the conference URI. Given the conference URI you > could INVITE immediately (ad=3Dhoc) or wait until some time later. = You > can use the conference URI to modify the policy of the=20 > conference before > or after the conference starts. Everything works fine. >=20 > Similarly, you could always use CPCP to get a conference URI, INVITE > immediately or later, modify the policy now or later, etc. =20 > Everything works > fine. >=20 > What is the difference in the result of these two mechanisms? > Nothing >=20 > What is the advantage of one mechanism over another? > A UA which only did ad-hoc has a trivial implementation=20 > if you use > the conference factory URI as long as the default policy was > acceptable >=20 > I don't see any other difference. =20 >=20 > This small difference argues for the conference factory=20 > uri choice >=20 > Now, suppose, as has been proposed, the conference factory URI doesn't > work the way I think, rather it immediately instantiates the=20 > conference. > What is the difference? > a) you save the second INVITE (2 messages per conference) > b) you need another mechanism for a pre-established conference >=20 > I expect most implementations of conference aware UAs will=20 > support both=20 > ad-hoc and pre-established. One mechanism is preferred. I don't think > you will see a UA implementation that does pre-established only. That > argues for the conference factory uri choice. >=20 > The worst situation is that there are two equivalent=20 > mechanisms and there > are implementations that only do one. That would create incompatible > implementations. >=20 > Brian >=20 > > -----Original Message----- > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > Sent: Tuesday, December 02, 2003 2:22 PM > > To: Rosen, Brian > > Cc: 'Heil Franca Marcelo'; 'Alan Johnston';=20 > > hisham.khartabil@nokia.com; > > rohan@cisco.com; georg.mayer@nokia.com; oritl@microsoft.com; > > xcon@ietf.org > > Subject: Re: [XCON] Chicken and Egg - Can CPCP create a conference > >=20 > >=20 > >=20 > >=20 > > Rosen, Brian wrote: > > > Well, now you might see why I think the Conference Factory URI > > > does not instantiate a conference; it just returns a=20 > conference ID. > > > That way, you could, if you wanted to, change the default policy > > > before you "started" it. > >=20 > > It is my understanding that the Conference Factory URI is used by=20 > > sending an INVITE to it. So how is it supposed to return a=20 > > conference ID=20 > > without also "starting" the conference? Typically the result of the=20 > > INVITE will be a dialog with the focus, with the address of=20 > the focus=20 > > being returned as the Contact. Or are you assuming that Conference=20 > > Factory URI will *always* return a 3xx rather than=20 > > establishing the dialog? > >=20 > > I would hate to write an application for creating/configuring a=20 > > conference that sends and INVITE but depends on it not=20 > > succeeding - so=20 > > that if it is surprised by having the INVITE succeed it barfs. > >=20 > > I think sending an invite to a Conference Factory URI=20 > should only be=20 > > used when the UAC wants to participate in a new conference=20 > > that starts=20 > > *now*. > >=20 > > If you want to establish a name and policy for a conference to take=20 > > place later, then I think you must use other means. > >=20 > > Paul > >=20 > >=20 > > _______________________________________________ > > XCON mailing list > > XCON@ietf.org > > https://www1.ietf.org/mailman/listinfo/xcon > >=20 >=20 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Wed Dec 3 16:46:17 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10023 for ; Wed, 3 Dec 2003 16:46:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AReot-0005v2-DA for xcon-archive@odin.ietf.org; Wed, 03 Dec 2003 16:46:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB3Lk3KS022746 for xcon-archive@odin.ietf.org; Wed, 3 Dec 2003 16:46:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AReot-0005un-7V for xcon-web-archive@optimus.ietf.org; Wed, 03 Dec 2003 16:46:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09964 for ; Wed, 3 Dec 2003 16:45:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AReoq-00029r-00 for xcon-web-archive@ietf.org; Wed, 03 Dec 2003 16:46:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AReoq-00029o-00 for xcon-web-archive@ietf.org; Wed, 03 Dec 2003 16:46:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AReoq-0005uB-SO; Wed, 03 Dec 2003 16:46:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARenx-0005tg-Jy for xcon@optimus.ietf.org; Wed, 03 Dec 2003 16:45:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09904 for ; Wed, 3 Dec 2003 16:44:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARenv-00028J-00 for xcon@ietf.org; Wed, 03 Dec 2003 16:45:03 -0500 Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx with esmtp (Exim 4.12) id 1ARenu-000276-00 for xcon@ietf.org; Wed, 03 Dec 2003 16:45:02 -0500 Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1041); Wed, 3 Dec 2003 13:43:13 -0800 Received: from 157.54.6.150 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 03 Dec 2003 13:44:30 -0800 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by inet-hub-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 3 Dec 2003 13:44:37 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] Chicken and Egg - Can CPCP create a conference Date: Wed, 3 Dec 2003 13:44:29 -0800 Message-ID: Thread-Topic: [XCON] Chicken and Egg - Can CPCP create a conference Thread-Index: AcO51hvegJjrOI4ITLuy7wyiJuXnDAADzcmw From: "Orit Levin" To: "Rosen, Brian" Cc: X-OriginalArrivalTime: 03 Dec 2003 21:44:37.0390 (UTC) FILETIME=[A5ED12E0:01C3B9E6] Content-Transfer-Encoding: quoted-printable Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable I agree with the other half as well. I am not sure you can enforce it through XCON, though. (I am not opposing to it - if we can.) I am a big fan of cc-conferencing (obviously!) - I think it MUST be followed by any SIP conferencing implementation including the indication of the isfocus parameter with the conference URI in the Contact header. Orit. -----Original Message----- From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org] On Behalf Of Rosen, Brian Sent: Wednesday, December 03, 2003 11:46 AM To: Orit Levin; Alan Johnston; Paul Kyzivat Cc: Heil Franca Marcelo; hisham.khartabil@nokia.com; rohan@cisco.com; georg.mayer@nokia.com; xcon@ietf.org Subject: RE: [XCON] Chicken and Egg - Can CPCP create a conference Orit This is just what I want to avoid. With this definition, you could create a conference service that did not support a conference factory URI, and yet was otherwise SIP-compliant. That means a phone could implement the conference factory uri, and wouldn't be compatible with your service. I explicitly said > must implement both if it implements any SIP functionality. Brian > -----Original Message----- > From: Orit Levin [mailto:oritl@microsoft.com] > Sent: Wednesday, December 03, 2003 2:36 PM > To: Rosen, Brian; Alan Johnston; Paul Kyzivat > Cc: Heil Franca Marcelo; hisham.khartabil@nokia.com; rohan@cisco.com; > georg.mayer@nokia.com; xcon@ietf.org > Subject: RE: [XCON] Chicken and Egg - Can CPCP create a conference >=20 >=20 > ***I vote for this conclusion***=20 >=20 > with a slight rewording: > An XCON-compliant conference server MUST implement conference creation > using XCON. > (We, XCON, can not prescribe general conferencing behavior for every > possible server.) >=20 > Orit. >=20 > -----Original Message----- > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org] On Behalf Of > Rosen, Brian > Sent: Wednesday, December 03, 2003 11:17 AM > To: 'Alan Johnston'; 'Paul Kyzivat' > Cc: 'Heil Franca Marcelo'; hisham.khartabil@nokia.com;=20 > rohan@cisco.com; > georg.mayer@nokia.com; Orit Levin; xcon@ietf.org > Subject: RE: [XCON] Chicken and Egg - Can CPCP create a conference >=20 > -- skip >=20 > If we do allow both, then we need to require that a conference service > must implement both if it implements any SIP functionality. > I can just see some conference server implementer deciding=20 > that since he > isn't going to implement any policy mechanisms he will only implement > the SIP conference factory mechanism, and then hit a phone=20 > that decided > it was always going to use CPCP to create every conference. >=20 > Brian >=20 > > -----Original Message----- > > From: Alan Johnston [mailto:alan.johnston@mci.com] > > Sent: Wednesday, December 03, 2003 10:10 AM > > To: Rosen, Brian; 'Paul Kyzivat' > > Cc: 'Heil Franca Marcelo'; hisham.khartabil@nokia.com;=20 > > rohan@cisco.com; georg.mayer@nokia.com; oritl@microsoft.com;=20 > > xcon@ietf.org > > Subject: RE: [XCON] Chicken and Egg - Can CPCP create a conference > >=20 > >=20 > > At 08:15 AM 12/3/2003 -0500, Rosen, Brian wrote: > > >I'm arguing that there is no advantage for two mechanisms to start=20 > > >conferences. > > >I prefer a SIP way, but I'll reluctantly except a CPCP way. > > > > > >First, let's observe that the "creator" of the conference=20 > has to be=20 > > >conference aware. A non-conference aware participant can=20 > be given a=20 > > >URI he don't understands is a conference URI, INVITE to > > it, and he's in. > > >Similarly, he can get a REFER to some URI and get in that way. > > > > > >So, one could define the mechanism to always be that you > > send an INVITE > > >to a conference Factory URI, which always returns a 3xx=20 > response with >=20 > > >a Contact containing the conference URI. Given the > > conference URI you > > >could INVITE immediately (ad=3Dhoc) or wait until some time=20 > later. You >=20 > > >can use the conference URI to modify the policy of the > > conference before > > >or after the conference starts. Everything works fine. > >=20 > > No, I'm afraid not. Many proxies automatically recurse on 3xx=20 > > responses. As a result, even if we somehow say that a conference=20 > > factory MUST redirect, the result would often be the=20 > establishment of=20 > > a session. Now what, the application has to send a BYE to=20 > disconnect=20 > > since the conference is not until next week? Will my conference=20 > > server see a steady stream of 1 second, single participant=20 > > conferences? Yuk! > >=20 > > Also, I expect that many of the protocols developed here in=20 > XCON will=20 > > be used to applications and automata. These applications will not=20 > > have a SIP UA. Will we force them to have a SIP UA so they=20 > can send=20 > > an INVITE which will always be followed by a BYE just to get a=20 > > Conference URI? Besides the CPCP security mechanisms, now this=20 > > application will need SIP security/authentication/firewall/NAT=20 > > traversal issues - again, yuk! > >=20 > > XCON protocols must stand on their own - having a way to create and=20 > > get a Conference URI seems like a critical element. > >=20 > >=20 > > >Similarly, you could always use CPCP to get a conference=20 > URI, INVITE > > >immediately or later, modify the policy now or later, etc. =20 > > Everything works > > >fine. > > > > > >What is the difference in the result of these two mechanisms? > > > Nothing > > > > > >What is the advantage of one mechanism over another? > > > A UA which only did ad-hoc has a trivial=20 > > implementation if you use > > > the conference factory URI as long as the default=20 > policy was > > >acceptable > > > > > > I don't see any other difference. > > > > > > This small difference argues for the conference=20 > > factory uri choice > > > > > >Now, suppose, as has been proposed, the conference factory=20 > > URI doesn't > > >work the way I think, rather it immediately instantiates the=20 > > conference. > > >What is the difference? > > > a) you save the second INVITE (2 messages per conference) > > > b) you need another mechanism for a pre-established=20 > > conference > > > > > >I expect most implementations of conference aware UAs will=20 > > support both > > >ad-hoc and pre-established. One mechanism is preferred. I=20 > > don't think > > >you will see a UA implementation that does pre-established=20 > > only. That > > >argues for the conference factory uri choice. > >=20 > > As I have argued above, many endpoints besides UAs will use=20 > > our protocols=20 > > to create conferences - requiring them to implement SIP and=20 > > send an INVITE=20 > > that doesn't establish a session is just a bad idea. > >=20 > > Thanks, > > Alan Johnston > > MCI > > sip:alan@sipstation.com > >=20 > >=20 > > >The worst situation is that there are two equivalent=20 > > mechanisms and there > > >are implementations that only do one. That would create=20 > incompatible > > >implementations. > > > > > >Brian > > > > > > > -----Original Message----- > > > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > > > Sent: Tuesday, December 02, 2003 2:22 PM > > > > To: Rosen, Brian > > > > Cc: 'Heil Franca Marcelo'; 'Alan Johnston'; > > > > hisham.khartabil@nokia.com; > > > > rohan@cisco.com; georg.mayer@nokia.com; oritl@microsoft.com; > > > > xcon@ietf.org > > > > Subject: Re: [XCON] Chicken and Egg - Can CPCP create a=20 > conference > > > > > > > > > > > > > > > > > > > > Rosen, Brian wrote: > > > > > Well, now you might see why I think the Conference Factory URI > > > > > does not instantiate a conference; it just returns a=20 > > conference ID. > > > > > That way, you could, if you wanted to, change the=20 > default policy > > > > > before you "started" it. > > > > > > > > It is my understanding that the Conference Factory URI=20 > is used by > > > > sending an INVITE to it. So how is it supposed to return a > > > > conference ID > > > > without also "starting" the conference? Typically the=20 > > result of the > > > > INVITE will be a dialog with the focus, with the address=20 > > of the focus > > > > being returned as the Contact. Or are you assuming that=20 > Conference > > > > Factory URI will *always* return a 3xx rather than > > > > establishing the dialog? > > > > > > > > I would hate to write an application for creating/configuring a > > > > conference that sends and INVITE but depends on it not > > > > succeeding - so > > > > that if it is surprised by having the INVITE succeed it barfs. > > > > > > > > I think sending an invite to a Conference Factory URI=20 > > should only be > > > > used when the UAC wants to participate in a new conference > > > > that starts > > > > *now*. > > > > > > > > If you want to establish a name and policy for a=20 > > conference to take > > > > place later, then I think you must use other means. > > > > > > > > Paul > > > > > > > > > > > > _______________________________________________ > > > > XCON mailing list > > > > XCON@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/xcon > > > > > > > > > >_______________________________________________ > > >XCON mailing list > > >XCON@ietf.org > > >https://www1.ietf.org/mailman/listinfo/xcon > >=20 >=20 > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon >=20 >=20 >=20 > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon >=20 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Wed Dec 3 18:42:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16287 for ; Wed, 3 Dec 2003 18:42:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARgdG-0001nK-84 for xcon-archive@odin.ietf.org; Wed, 03 Dec 2003 18:42:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB3NgAiD006892 for xcon-archive@odin.ietf.org; Wed, 3 Dec 2003 18:42:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARgdG-0001my-12 for xcon-web-archive@optimus.ietf.org; Wed, 03 Dec 2003 18:42:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16275 for ; Wed, 3 Dec 2003 18:41:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARgd9-0004He-00 for xcon-web-archive@ietf.org; Wed, 03 Dec 2003 18:42:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARgd9-0004Hb-00 for xcon-web-archive@ietf.org; Wed, 03 Dec 2003 18:42:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARgd7-0001m1-Q6; Wed, 03 Dec 2003 18:42:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARgcv-0001lX-Gf for xcon@optimus.ietf.org; Wed, 03 Dec 2003 18:41:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16261 for ; Wed, 3 Dec 2003 18:41:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARgcs-0004HF-00 for xcon@ietf.org; Wed, 03 Dec 2003 18:41:46 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1ARgcr-0004H3-00 for xcon@ietf.org; Wed, 03 Dec 2003 18:41:45 -0500 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id hB3NfBjq005239; Wed, 3 Dec 2003 15:41:11 -0800 (PST) Received: from cisco.com ([161.44.79.239]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AEK18057; Wed, 3 Dec 2003 18:41:09 -0500 (EST) Message-ID: <3FCE7495.2020402@cisco.com> Date: Wed, 03 Dec 2003 18:41:09 -0500 From: Paul Kyzivat 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: "Rosen, Brian" CC: "'hisham.khartabil@nokia.com'" , rohan@cisco.com, alan.johnston@mci.com, georg.mayer@nokia.com, oritl@microsoft.com, xcon@ietf.org Subject: Re: [XCON] Chicken and Egg - Can CPCP create a conference References: <313680C9A886D511A06000204840E1CF070B6165@whq-msgusr-02.pit.comms.marconi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I am in agreement with Alan and others that binding the names of the two uris together algorithmically is a terrible idea, at least as part of a standard. (There is nothing to stop a particular implementation from doing this. It just won't be interoperable, and needn't be.) What we have here are not two names for the same thing, but rather two names for different things that happen to be in 1:1 correspondence with one another. We have - a sip uri identifying the focus of a conference - an http uri identifying the policy for a conference If all an application cares about is call control, then all it needs to implement is sip, and the only identifier it needs is the sip uri. If all an application cares about is policy managment, then all it needs to implement is http and xcap, and the only identifier it needs is the http uri. If an application cares about both of these, then it must implement both sets of protocols, and it needs both uris. Each protocol should provide a protocol to obtain the uri for the other object/protocol. Paul Rosen, Brian wrote: > I don't understand this. I'm not changing the definition of a focus. > I'm observing that the host of the focus is the host of the policy > server, at least for now. At some point in the future, we could > change this, but now, we can easily make them the same. > > If we use XCAP for CPCP, this seems very straightforward, > and it's even a uri! > > suppose the conferenceID is: > sip:hishams-weekly-status-meeting@confa.example.com > > Then the XCAP URI for this conference is > http:confa.example.com/cpcp/hishams-weekly-status-meeting... > > at least for now. All I propose is that the root service uri for > CPCP be slightly more structured for CPCP than XCAP, which proposes > that the root service uri be provisioned. If this offends you > that much, you could always say that if you have an XCAP service > root, use it, adding cpcp/hishams-weekly-status-meeting to it > to access the policy for this conference. > > If it's not XCAP, we still use the focus host as the CPCP host, > and the conference uri userpart as the id, with whatever convention > the chosen protocol uses to encode it. > > >>-----Original Message----- >>From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] >>Sent: Wednesday, December 03, 2003 9:44 AM >>To: Brian.Rosen@marconi.com; pkyzivat@cisco.com >>Cc: rohan@cisco.com; alan.johnston@mci.com; georg.mayer@nokia.com; >>oritl@microsoft.com; xcon@ietf.org >>Subject: RE: [XCON] Chicken and Egg - Can CPCP create a conference >> >> >>You are asking to change the definition of a focus. It is >>created when the conference is instantiated (using your >>definition of instantiation) and destroyed when the >>conference instance is destroyed. Therefore, pre-establishing >>a conference is not possible using CPCP unless a conference >>is instantiated. That is not desirable. >> >>We have a conference framework in place, lets use it. >> >>/Hisham >> >> >>>-----Original Message----- >>>From: ext Rosen, Brian [mailto:Brian.Rosen@marconi.com] >>>Sent: 03.December.2003 14:58 >>>To: 'Paul Kyzivat' >>>Cc: Khartabil Hisham (NMP-MSW/Helsinki); rohan@cisco.com; >>>alan.johnston@mci.com; Mayer Georg (NMP-MSW/Helsinki); >>>oritl@microsoft.com; xcon@ietf.org >>>Subject: RE: [XCON] Chicken and Egg - Can CPCP create a conference >>> >>> >>>Ah, I wondered when we would get to this. >>> >>>This is one of the bigger problems in separating conference policy >>>from sip signalling. Everything would be simpler if the conference >>>policy server was always the focus. >>> >>>So, I want to ask, can we make it be so? >>> >>>What are the advantages of making the conference policy server >>>separate from the focus? Two ideas occur to me: >>> 1. Separation of implementation >>> But this is not possible with the current framework >>> because we don't specify the interface between >>> CPCP and SIP; we assume that it is proprietary >>> 2. Load Balancing >>> But I really, really doubt that works. It >>>would be easier >>> to have a separate CPS with every focus, and replicate >>> the combination >>> >>>So, what if we assume they are the same entity, and use the same ID? >>>We don't need to have the conference policy be a URI, we merely have >>>to locate the address of the server. So, it's the hostname of the >>>conference URI. And a sip uri is a fine conference ID for the >>>purpose of specifying which policy once we know where the server is. >>> >>>Is there some advantage of having the conference policy explicitly >>>be a URI that I'm missing? >>> >>>Brian >>> >>> >>>>-----Original Message----- >>>>From: Paul Kiribati [mailto:pkyzivat@cisco.com] >>>>Sent: Tuesday, December 02, 2003 2:44 PM >>>>To: Rosen, Brian >>>>Cc: 'hisham.khartabil@nokia.com'; rohan@cisco.com; >>>>alan.johnston@mci.com; georg.mayer@nokia.com; oritl@microsoft.com; >>>>xcon@ietf.org >>>>Subject: Re: [XCON] Chicken and Egg - Can CPCP create a conference >>>> >>>> >>>> >>>> >>>>Rosen, Brian wrote: >>>> >>>>>>If you look at XCAP list usage for example, you will see that >>>>>>the list-URI used when sending SIP SUBSCRIBE requests to the >>>>>>list is not the same as the URI used to manipulate the list >>>>>>using XCAP. They certainly need to be linked, but not >>>>>>necessarily the same. >>>>>> >>>>>>Depending on the protocol we chose, a SIP URI can or cannot >>>>>>be used to identify a conference policy. >>>>> >>>>>I think we CAN always have the same ID. >>>>>I think there is a lot of value in one ID >>>>>I don't think there is any problem in having one ID >>>>> >>>>>So, I think there should be one. >>>>> >>>>>If there is a good reason, we can burden the conference >>>> >>>>policy server >>>> >>>>>with keeping the relationship, but unless there is a good >>>> >>>>reason, history >>>> >>>>>suggests that one namespace is better than two with linkage. >>>> >>>>[The chicken and the egg are different things. If I want to >>>>talk to the >>>>egg I need the address of the egg - having the address of >>> >>>the chicken >>> >>>>isn't sufficient. Its probably a bad idea to crack the egg in >>>>order to >>>>ask the chicken for the address of the egg.] >>>> >>>>Getting away from metaphors, this seems to be coming down to the >>>>distinction between URIs and URLs. >>>> >>>>A sip address is a URL in that it is sufficient for me to >>> >>locate a >> >>>>corresponding (sip) resource. >>>> >>>>But it isn't sufficient for me to locate a CPCP resource. If >>>>I knew how >>>>to contact the appropriate CPCP server, perhaps a sip uri >>>>could serve to >>>>identify the policy. But that would require me to know the >>> >>>address of >>> >>>>the server a-priori. >>>> >>>>If all I have is the sip conference id, then to derive the >>>>URI for the >>>>policy from it I must invoke sip operations on it. >>>> >>>> Paul >>>> >>>> >>>>_______________________________________________ >>>>XCON mailing list >>>>XCON@ietf.org >>>>https://www1.ietf.org/mailman/listinfo/xcon >>>> >>> >>_______________________________________________ >>XCON mailing list >>XCON@ietf.org >>https://www1.ietf.org/mailman/listinfo/xcon >> > > _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Wed Dec 3 22:55:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25784 for ; Wed, 3 Dec 2003 22:55:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARka2-0004Cm-Hx for xcon-archive@odin.ietf.org; Wed, 03 Dec 2003 22:55:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB43t6kd016158 for xcon-archive@odin.ietf.org; Wed, 3 Dec 2003 22:55:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARka2-0004CX-6t for xcon-web-archive@optimus.ietf.org; Wed, 03 Dec 2003 22:55:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25697 for ; Wed, 3 Dec 2003 22:54:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARkZy-0000po-00 for xcon-web-archive@ietf.org; Wed, 03 Dec 2003 22:55:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARkZx-0000pj-00 for xcon-web-archive@ietf.org; Wed, 03 Dec 2003 22:55:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARkZx-0004A2-K9; Wed, 03 Dec 2003 22:55:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARkZF-00048y-JR for xcon@optimus.ietf.org; Wed, 03 Dec 2003 22:54:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25642 for ; Wed, 3 Dec 2003 22:53:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARkZB-0000oJ-00 for xcon@ietf.org; Wed, 03 Dec 2003 22:54:13 -0500 Received: from goalie.snowshore.com ([216.57.133.4] helo=webshield.office.snowshore.com) by ietf-mx with smtp (Exim 4.12) id 1ARkZA-0000ns-00 for xcon@ietf.org; Wed, 03 Dec 2003 22:54:12 -0500 Received: from zoe.office.snowshore.com(192.168.1.172) by webshield.office.snowshore.com via csmap id 16938; Wed, 03 Dec 2003 22:59:13 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] CPCP requirements to support IMS Date: Wed, 3 Dec 2003 22:53:43 -0500 Message-ID: <4A3384433CE2AB46A63468CB207E209D4F6A6E@zoe.office.snowshore.com> Thread-Topic: CPCP requirements to support IMS Thread-Index: AcOvS82U0oSgB/XHQj2tUdIe1CxMVwAKIXqwAqaPCQA= From: "Eric Burger" To: , , Content-Transfer-Encoding: quoted-printable Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Said differently, SIP just works! > -----Original Message----- > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > Sent: Thu, November 20, 2003 9:55 AM > To: georg.mayer@nokia.com; xcon@ietf.org > Subject: RE: [XCON] CPCP requirements to support IMS > > -----Original Message----- > > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On=20 > Behalf Of ext > > georg.mayer@nokia.com > > Sent: 20.November.2003 11:51 > > To: xcon@ietf.org > > Subject: [XCON] CPCP requirements to support IMS [snip] > > - indication that user is automatically unsubscribed from=20 > > conference event subscription when user is leaving >=20 > You would like that to be conference instance specific using=20 > CPCP? or is this an implementation issue for conference=20 > server implementers? What I mean is that do you see a use=20 > case for having to signal such thing in CPCP? or will the IMS=20 > just behave as you describe below every time? If it is the=20 > latter, then there is no need to standardise such thing. [snip] _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Wed Dec 3 23:44:52 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25785 for ; Wed, 3 Dec 2003 22:55:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARka2-0004DI-UW for xcon-archive@odin.ietf.org; Wed, 03 Dec 2003 22:55:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB43t6e2016180 for xcon-archive@odin.ietf.org; Wed, 3 Dec 2003 22:55:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARka2-0004Co-N6 for xcon-web-archive@optimus.ietf.org; Wed, 03 Dec 2003 22:55:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25702 for ; Wed, 3 Dec 2003 22:54:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARkZy-0000pv-00 for xcon-web-archive@ietf.org; Wed, 03 Dec 2003 22:55:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARkZy-0000pm-00 for xcon-web-archive@ietf.org; Wed, 03 Dec 2003 22:55:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARkZx-0004AA-TN; Wed, 03 Dec 2003 22:55:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARkZF-000493-Qh for xcon@optimus.ietf.org; Wed, 03 Dec 2003 22:54:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25645 for ; Wed, 3 Dec 2003 22:53:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARkZB-0000oO-00 for xcon@ietf.org; Wed, 03 Dec 2003 22:54:13 -0500 Received: from goalie.snowshore.com ([216.57.133.4] helo=webshield.office.snowshore.com) by ietf-mx with smtp (Exim 4.12) id 1ARkZB-0000ns-00 for xcon@ietf.org; Wed, 03 Dec 2003 22:54:13 -0500 Received: from zoe.office.snowshore.com(192.168.1.172) by webshield.office.snowshore.com via csmap id 16938; Wed, 03 Dec 2003 22:59:13 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] CPCP requirements to support IMS Date: Wed, 3 Dec 2003 22:53:43 -0500 Message-ID: <4A3384433CE2AB46A63468CB207E209D4F6A6F@zoe.office.snowshore.com> Thread-Topic: [XCON] CPCP requirements to support IMS Thread-Index: AcOwUDhNMp5RYvgaSRe92ZA4+sRkRwCOgnFQAeEcpuA= From: "Eric Burger" To: , Content-Transfer-Encoding: quoted-printable Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Can you give ANY justification for the statement that one protocol that = does everything is better than focused protocols that get the job done? I would offer, especially for devices of limited capability (like = wireless), that a small set of focused protocols would result in less = code and less memory usage than a kitchen sink protocol that does = everything. If "one protocol" is a goal, I would suggest H.323v99 :-) > -----Original Message----- > From: georg.mayer@nokia.com [mailto:georg.mayer@nokia.com] > Sent: Mon, November 24, 2003 8:14 AM > To: drage@lucent.com; hisham.khartabil@nokia.com; > peter.leis@siemens.com; xcon@ietf.org > Subject: RE: [XCON] CPCP requirements to support IMS >=20 >=20 > Hello Keith et al, >=20 > > At this moment in time it is premature to make any decisions=20 > > about protocol, but I would certainly believe that we retain=20 > > the flexibility to choose a different protocol for each of=20 > > the above, based on different underlying requirements. If we=20 > > choose the same protocol for membership policy as for=20 > > resource list management in presence, then it will be because=20 > > the requirements are similar. >=20 > well, I would say that one of the requirements from a=20 > wireless SIP device (regardless whether it makes use of IMS=20 > or not) is for sure to have a small set of protocols that it=20 > needs to faciliate to be able to make use of SIP services. [snip] _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Wed Dec 3 23:44:52 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25786 for ; Wed, 3 Dec 2003 22:55:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARka2-0004DH-UF for xcon-archive@odin.ietf.org; Wed, 03 Dec 2003 22:55:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB43t6c1016175 for xcon-archive@odin.ietf.org; Wed, 3 Dec 2003 22:55:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARka2-0004Cn-L9 for xcon-web-archive@optimus.ietf.org; Wed, 03 Dec 2003 22:55:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25700 for ; Wed, 3 Dec 2003 22:54:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARkZy-0000pr-00 for xcon-web-archive@ietf.org; Wed, 03 Dec 2003 22:55:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARkZx-0000pk-00 for xcon-web-archive@ietf.org; Wed, 03 Dec 2003 22:55:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARkZz-0004B6-Dl; Wed, 03 Dec 2003 22:55:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARkZg-00049d-Ct for xcon@optimus.ietf.org; Wed, 03 Dec 2003 22:54:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25676 for ; Wed, 3 Dec 2003 22:54:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARkZc-0000pE-00 for xcon@ietf.org; Wed, 03 Dec 2003 22:54:40 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1ARkZb-0000oD-00 for xcon@ietf.org; Wed, 03 Dec 2003 22:54:39 -0500 Received: from SCOTTF-W2K5.cisco.com (dhcp-128-107-141-144.cisco.com [128.107.141.144]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id hB43s8iO025973; Wed, 3 Dec 2003 19:54:08 -0800 (PST) Message-Id: <4.3.1.2.20031203192002.01bd0978@VTG-UM-E2K1> X-Sender: nismail@VTG-UM-E2K1 X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Wed, 03 Dec 2003 19:56:16 -0800 To: "Rosen, Brian" From: Nermeen Ismail Subject: RE: [XCON] Chicken and Egg - Can CPCP create a conference Cc: xcon@ietf.org In-Reply-To: <313680C9A886D511A06000204840E1CF070B6169@whq-msgusr-02.pit .comms.marconi.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , I have just seen this thread so I might be repeating what is laredy been said. I agree that from the protocols point of view a conference is a conference. It does not matter if it is ad hoc or scheduled. It has a unique URI, its policy can be manipulated and authorized users can join/leave them either by dial-in or dial-out. My understanding for why there are two ways to create a conference is to support : 1- Creating a conference and joining it without having to implement anything other than SIP (cc-conferencing). In this case sending an INVITE to the URI factory is sufficient. Off course if the endpoint needs to do something more like modifying the conference policy then it needs to also implement CPCP/MPCP in which case it might have just used that to create the conference. However the point is still that an application can create, join a conference and get the roster without needing anything other than a SIP stack. 2- Creating a conference and never joining it. This is like the case of a scheduling automata that at the time of conference scheduling it creates a conference and a focus. In this case and as the application will never send or receive media to the conference it was deemed inappropriate to demand the application to have a SIP stack and send a no-media INVITE to create the conference. Hence some non-SIP method will be used to create the conference. A non-sip method will be used to create the conference (enters CPCP) and this create-conference will be sent to the top-level policy server URI which in return will send the conference URI and the policy server URI for that conference. The only benefot that this method has over number 1 is that the application does not have to support SIP. So a conference server needs to have a SIP stack, CPCP/MPCP and the conference package but a client might only have a SIP stack, a CPCP/MPCP implementation or both. On a separate topic, it was mentioned before that when a conference is created a future start time can be specified. I see lots of complications with that to do with time zones etc. Already the client that created the conference has to deal with that and I do not see any benefit in extending that to the conference server as well. So I see benefits in specifying a conference duration but no benefit in specifying conference start time. If the client creating the conference wishes the conference to start accepting users in 5 minutes time then it needs to delay sending the create conference 5 minutes. nermeen > > >We must stop talking about "ad-hoc conferences" and "scheduled > > conferences" > > >- there is no such thing. There are only ad-hoc mechanisms and > > scheduled > > >mechanisms to create/join a conference. >Which, I think, is completely useless. >And, to be specific: > There is no difference in how you join a conference > You always send an INVITE, or get a REFER, > or receive an INVITE. You can't join with > CPCP. > There is no reason to have a difference to create one > > > > > [Chris Boulton] I totally agree. Whether 'ad-hoc' or > > 'scheduled' means > > are used to create a conference should have no effect - a conference > > should be created and a default policy applied. Then, if it is an > > 'ad-hoc' conference, a participant is free to join and if it is a > > scheduled, the creator may manipulate the conference policy. >Why is it different with ad-hoc that a participant is free to join? >Why is it different with scheduled that the creator may manipulate >the conference policy? > >I think there is no difference at all. No matter how you create it, >participants are free to join any time the policy says they pay. >No matter how you create it, the creator may manipulate the conference >policy (and participants may manipulate it also, subject to permissions). > > > > >So, if The Example Company already has their public web server home > > page at > > >example.com where everyone goes to download the latest examples, this > > web > > >server now needs to become the conference policy server? >No, unless the example.com is also the focus host. If it is, then the >web server is there too. That is just not a limitation worth worrying >about. > > > > > > > >There are significant disadvantages in limiting ourselves to such > > >conventions - especially when there are other ways of discovering the > > >policy URI. One way that has been discussed is advertising > > the policy > > URI > > >in conference package notifications. Is this not sufficient? This > > >approach is flexible and extensible (different protocols for policy > > >manipulation can be defined with a new URI scheme) and has > > none of the > > name > > >space limitations of this proposal. > > > > [Chris Boulton] This approach does seem to 'shoe-horn' the HTTP usage > > and IMHO is quite an ugly solution. As Alan points out, policy URI > > contained in conference packages is a far more elegant solution. > > >My problem is that we seem to be heading to a solution where there >is no subset of capabilities. To do anything, you need to implement: > cc conference >AND > cpcp >AND > mpcp >AND > the conference package > >There are no simple implementations other than conference unaware. >Is that really what we want to do? Intertwine all the pieces so that >there is no clean functional separation that allows implementation >flexibility without creating incompatibility? In this specific >case, why do you have to implement the conference package in order >to discover the conference policy uri? > >A message or two ago, Alan talked about automata manipulating conference >policy, and you were aghast that I proposed using SIP means to >create a conference ID. You now want the automata to use SIP means >to find a conference policy URI given a conference URI; they even have >to join the conference to do so, unless the automata created the >conference in the first place, where it may get the conference policy >uri returned to it). > >Can't we give up a slight amount of flexibility to get the possibility >of more widespread use of this facility by limiting implementation >complexity? Maybe we need some use case stuff to see how subsets might >be useful. > > >_______________________________________________ >XCON mailing list >XCON@ietf.org >https://www1.ietf.org/mailman/listinfo/xcon _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Thu Dec 4 04:06:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16744 for ; Thu, 4 Dec 2003 04:06:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARpR0-0000qF-L0 for xcon-archive@odin.ietf.org; Thu, 04 Dec 2003 04:06:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB496600003236 for xcon-archive@odin.ietf.org; Thu, 4 Dec 2003 04:06:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARpR0-0000q6-Bp for xcon-web-archive@optimus.ietf.org; Thu, 04 Dec 2003 04:06:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16724 for ; Thu, 4 Dec 2003 04:05:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARpQx-0004mX-00 for xcon-web-archive@ietf.org; Thu, 04 Dec 2003 04:06:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARpQw-0004mU-00 for xcon-web-archive@ietf.org; Thu, 04 Dec 2003 04:06:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARpQw-0000pX-Hf; Thu, 04 Dec 2003 04:06:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARpQj-0000pK-Hl for xcon@optimus.ietf.org; Thu, 04 Dec 2003 04:05:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16713 for ; Thu, 4 Dec 2003 04:05:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARpQf-0004mG-00 for xcon@ietf.org; Thu, 04 Dec 2003 04:05:45 -0500 Received: from mail49.messagelabs.com ([193.109.255.19]) by ietf-mx with smtp (Exim 4.12) id 1ARpQe-0004m6-00 for xcon@ietf.org; Thu, 04 Dec 2003 04:05:44 -0500 X-VirusChecked: Checked X-Env-Sender: cboulton@ubiquity.net X-Msg-Ref: server-12.tower-49.messagelabs.com!1070528698!591742 X-StarScan-Version: 5.1.13; banners=ubiquity.net,-,- Received: (qmail 14011 invoked from network); 4 Dec 2003 09:04:59 -0000 Received: from news.ubiquity.net (HELO gbnewp0186s1.eu.ubiquity.net) (194.202.146.92) by server-12.tower-49.messagelabs.com with SMTP; 4 Dec 2003 09:04:59 -0000 Received: from mailhost.eu.ubiquity.net by gbnewp0186s1.eu.ubiquity.net via smtpd (for mail49.messagelabs.com [193.109.255.19]) with SMTP; Thu, 4 Dec 2003 09:07:32 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] Chicken and Egg - Can CPCP create a conference Date: Thu, 4 Dec 2003 09:03:23 -0000 Message-ID: <45730E094814E44488F789C1CDED27AE0219B13D@gbnewp0758m.eu.ubiquity.net> Thread-Topic: [XCON] Chicken and Egg - Can CPCP create a conference Thread-Index: AcO6Gj0jjFVhTSHoR6OGtzl/PbDsuQAKlnJw From: "Chris Boulton" To: "Nermeen Ismail" , "Rosen, Brian" Cc: Content-Transfer-Encoding: quoted-printable Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable >-----Original=20Message----- >From:=20Nermeen=20Ismail=20[mailto:nismail@cisco.com] >Sent:=2004=20December=202003=2003:56 >To:=20Rosen,=20Brian >Cc:=20xcon@ietf.org >Subject:=20RE:=20[XCON]=20Chicken=20and=20Egg=20-=20Can=20CPCP=20create=20= a=20conference > >I=20have=20just=20seen=20this=20thread=20so=20I=20might=20be=20repeating=20= what=20is=20laredy been >said. > >I=20agree=20that=20from=20the=20protocols=20point=20of=20view=20a=20confe= rence=20is=20a conference. >It=20does=20not=20matter=20if=20it=20is=20ad=20hoc=20or=20scheduled.=20It= =20has=20a=20unique=20URI, its >policy=20can=20be=20manipulated=20and=20authorized=20users=20can=20join/l= eave=20them either >by=20dial-in=20or=20dial-out. > >My=20understanding=20for=20why=20there=20are=20two=20ways=20to=20create=20= a=20conference=20is to >support=20: >1-=20Creating=20a=20conference=20and=20joining=20it=20without=20having=20= to=20implement >anything=20other=20than=20SIP=20(cc-conferencing).=20In=20this=20case=20s= ending=20an >INVITE=20to=20the=20URI=20factory=20is=20sufficient.=20Off=20course=20if=20= the=20endpoint needs >to=20do=20something=20more=20like=20modifying=20the=20conference=20policy= =20then >it=20needs=20to=20also=20implement=20CPCP/MPCP=20in=20which=20case=20it=20= might=20have=20just used >that=20to=20create=20the=20conference.=20However=20the=20point=20is=20sti= ll=20that=20an >application=20can=20create,=20join=20a=20conference=20and=20get=20the=20r= oster=20without >needing=20anything=20other=20than=20a=20SIP=20stack. > >2-=20Creating=20a=20conference=20and=20never=20joining=20it.=20This=20is=20= like=20the=20case=20of a >scheduling=20automata=20that=20at=20the=20time=20of=20conference=20schedu= ling=20it creates=20a >conference=20and=20a=20focus.=20In=20this=20case=20and=20as=20the=20appli= cation=20will=20never send >or=20receive=20media=20to=20the=20conference=20it=20was=20deemed=20inappr= opriate=20to demand >the=20application=20to=20have=20a=20SIP=20stack=20and=20send=20a=20no-med= ia=20INVITE=20to create >the=20conference.=20Hence=20some=20non-SIP=20method=20will=20be=20used=20= to=20create=20the >conference.=20A=20non-sip=20method=20will=20be=20used=20to=20create=20the= =20conference (enters >CPCP)=20and=20this=20create-conference=20will=20be=20sent=20to=20the=20to= p-level=20policy >server=20URI=20which=20in=20return=20will=20send=20the=20conference=20URI= =20and=20the=20policy >server=20URI=20for=20that=20conference.=20The=20only=20benefot=20that=20t= his=20method=20has >over=20number=201=20is=20that=20the=20application=20does=20not=20have=20t= o=20support=20SIP. > >So=20a=20conference=20server=20needs=20to=20have=20a=20SIP=20stack,=20CPC= P/MPCP=20and=20the >conference=20package=20but=20a=20client=20might=20only=20have=20a=20SIP=20= stack,=20a CPCP/MPCP >implementation=20or=20both. > >On=20a=20separate=20topic,=20it=20was=20mentioned=20before=20that=20when=20= a=20conference=20is >created=20a=20future=20start=20time=20can=20be=20specified.=20I=20see=20l= ots=20of complications >with=20that=20to=20do=20with=20time=20zones=20etc.=20Already=20the=20clie= nt=20that=20created the >conference=20has=20to=20deal=20with=20that=20and=20I=20do=20not=20see=20a= ny=20benefit=20in extending >that=20to=20the=20conference=20server=20as=20well.=20So=20I=20see=20benef= its=20in=20specifying a >conference=20duration=20but=20no=20benefit=20in=20specifying=20conference= =20start=20time. >If=20the=20client=20creating=20the=20conference=20wishes=20the=20conferen= ce=20to=20start >accepting=20users=20in=205=20minutes=20time=20then=20it=20needs=20to=20de= lay=20sending=20the create >conference=205=20minutes. [Chris=20Boulton]=20I'm=20not=20disagreeing=20with=20this=20point=20just=20= thinking=20about it=20a=20bit=20more.=20=20I=20guess=20the=20main=20concern=20I=20have=20is= =20related=20to=20the scheduling=20of=20resources.=20=20Are=20you=20saying=20that=20resources=20= would=20not=20be scheduled=20(not=20reserved)=20for=20this=20conference=20until=20the=20mom= ent=20it=20starts. So=20if=20I=20schedule=20a=20conference=20for=20a=20weeks=20time=20-=20the= n=20on=20the=20day=20of=20the conference,=20one=20of=20my=20colleagues=20schedules=20+=20starts=20a=20co= nference=2010 minutes=20before=20mine=20and=20uses=20up=20all=20of=20my=20companies=20po= rt=20allocation=20- that=20means=20it's=20tough=20for=20me????=20=20(And=20the=20answer=20isn'= t=20to=20buy=20more ports=20before=20anyone=20suggests=20it=20;-) > > >nermeen > > > > > >>=20>=20>We=20must=20stop=20talking=20about=20"ad-hoc=20conferences"=20an= d=20"scheduled >>=20>=20conferences" >>=20>=20>-=20there=20is=20no=20such=20thing.=20=20There=20are=20only=20ad= -hoc=20mechanisms=20and >>=20>=20scheduled >>=20>=20>mechanisms=20to=20create/join=20a=20conference. >>Which,=20I=20think,=20is=20completely=20useless. >>And,=20to=20be=20specific: >>=20=20=20=20=20=20=20=20=20There=20is=20no=20difference=20in=20how=20you= =20join=20a=20conference >>=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20You=20always=20send=20= an=20INVITE,=20or=20get=20a=20REFER, >>=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20or=20receive=20an=20INVITE.=20=20You=20can't=20join=20with >>=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20CPCP. >>=20=20=20=20=20=20=20=20=20There=20is=20no=20reason=20to=20have=20a=20di= fference=20to=20create=20one >> >>=20> >>=20>=20[Chris=20Boulton]=20I=20totally=20agree.=20=20Whether=20'ad-hoc'=20= or >>=20>=20'scheduled'=20means >>=20>=20are=20used=20to=20create=20a=20conference=20should=20have=20no=20= effect=20-=20a conference >>=20>=20should=20be=20created=20and=20a=20default=20policy=20applied.=20=20= Then,=20if=20it=20is=20an >>=20>=20'ad-hoc'=20conference,=20a=20participant=20is=20free=20to=20join=20= and=20if=20it=20is=20a >>=20>=20scheduled,=20the=20creator=20may=20manipulate=20the=20conference=20= policy. >>Why=20is=20it=20different=20with=20ad-hoc=20that=20a=20participant=20is=20= free=20to=20join? >>Why=20is=20it=20different=20with=20scheduled=20that=20the=20creator=20ma= y=20manipulate >>the=20conference=20policy? >> >>I=20think=20there=20is=20no=20difference=20at=20all.=20=20No=20matter=20= how=20you=20create=20it, >>participants=20are=20free=20to=20join=20any=20time=20the=20policy=20says= =20they=20pay. >>No=20matter=20how=20you=20create=20it,=20the=20creator=20may=20manipulat= e=20the=20conference >>policy=20(and=20participants=20may=20manipulate=20it=20also,=20subject=20= to permissions). >> >> >>=20>=20>So,=20if=20The=20Example=20Company=20already=20has=20their=20pub= lic=20web=20server home >>=20>=20page=20at >>=20>=20>example.com=20where=20everyone=20goes=20to=20download=20the=20la= test=20examples, this >>=20>=20web >>=20>=20>server=20now=20needs=20to=20become=20the=20conference=20policy=20= server? >>No,=20unless=20the=20example.com=20is=20also=20the=20focus=20host.=20=20= If=20it=20is,=20then=20the >>web=20server=20is=20there=20too.=20That=20is=20just=20not=20a=20limitati= on=20worth=20worrying >>about. >> >> >>=20>=20> >>=20>=20>There=20are=20significant=20disadvantages=20in=20limiting=20ours= elves=20to=20such >>=20>=20>conventions=20-=20especially=20when=20there=20are=20other=20ways= =20of=20discovering the >>=20>=20>policy=20URI.=20=20One=20way=20that=20has=20been=20discussed=20i= s=20advertising >>=20>=20the=20policy >>=20>=20URI >>=20>=20>in=20conference=20package=20notifications.=20=20Is=20this=20not=20= sufficient? This >>=20>=20>approach=20is=20flexible=20and=20extensible=20(different=20proto= cols=20for policy >>=20>=20>manipulation=20can=20be=20defined=20with=20a=20new=20URI=20schem= e)=20and=20has >>=20>=20none=20of=20the >>=20>=20name >>=20>=20>space=20limitations=20of=20this=20proposal. >>=20> >>=20>=20[Chris=20Boulton]=20This=20approach=20does=20seem=20to=20'shoe-ho= rn'=20the=20HTTP usage >>=20>=20and=20IMHO=20is=20quite=20an=20ugly=20solution.=20=20As=20Alan=20= points=20out,=20policy=20URI >>=20>=20contained=20in=20conference=20packages=20is=20a=20far=20more=20el= egant=20solution. >>=20> >>My=20problem=20is=20that=20we=20seem=20to=20be=20heading=20to=20a=20solu= tion=20where=20there >>is=20no=20subset=20of=20capabilities.=20=20To=20do=20anything,=20you=20n= eed=20to=20implement: >>=20=20=20=20=20=20=20=20=20cc=20conference >>AND >>=20=20=20=20=20=20=20=20=20cpcp >>AND >>=20=20=20=20=20=20=20=20=20mpcp >>AND >>=20=20=20=20=20=20=20=20=20the=20conference=20package >> >>There=20are=20no=20simple=20implementations=20other=20than=20conference=20= unaware. >>Is=20that=20really=20what=20we=20want=20to=20do?=20=20Intertwine=20all=20= the=20pieces=20so=20that >>there=20is=20no=20clean=20functional=20separation=20that=20allows=20impl= ementation >>flexibility=20without=20creating=20incompatibility?=20=20In=20this=20spe= cific >>case,=20why=20do=20you=20have=20to=20implement=20the=20conference=20pack= age=20in=20order >>to=20discover=20the=20conference=20policy=20uri? >> >>A=20message=20or=20two=20ago,=20Alan=20talked=20about=20automata=20manip= ulating conference >>policy,=20and=20you=20were=20aghast=20that=20I=20proposed=20using=20SIP=20= means=20to >>create=20a=20conference=20ID.=20=20You=20now=20want=20the=20automata=20t= o=20use=20SIP=20means >>to=20find=20a=20conference=20policy=20URI=20given=20a=20conference=20URI= ;=20they=20even=20have >>to=20join=20the=20conference=20to=20do=20so,=20unless=20the=20automata=20= created=20the >>conference=20in=20the=20first=20place,=20where=20it=20may=20get=20the=20= conference=20policy >>uri=20returned=20to=20it). >> >>Can't=20we=20give=20up=20a=20slight=20amount=20of=20flexibility=20to=20g= et=20the=20possibility >>of=20more=20widespread=20use=20of=20this=20facility=20by=20limiting=20im= plementation >>complexity?=20=20Maybe=20we=20need=20some=20use=20case=20stuff=20to=20se= e=20how=20subsets might >>be=20useful. >> >> >>_______________________________________________ >>XCON=20mailing=20list >>XCON@ietf.org >>https://www1.ietf.org/mailman/listinfo/xcon > > >_______________________________________________ >XCON=20mailing=20list >XCON@ietf.org >https://www1.ietf.org/mailman/listinfo/xcon > >_______________________________________________________________________ _ >This=20email=20has=20been=20scanned=20for=20all=20viruses=20by=20the=20Me= ssageLabs=20Email >Security=20System.=20For=20more=20information=20on=20a=20proactive=20emai= l=20security >service=20working=20around=20the=20clock,=20around=20the=20globe,=20visit= >http://www.messagelabs.com >_______________________________________________________________________ _ ________________________________________________________________________ This=20email=20has=20been=20scanned=20for=20all=20viruses=20by=20the=20Mes= sageLabs=20Email Security=20System.=20For=20more=20information=20on=20a=20proactive=20email= =20security service=20working=20around=20the=20clock,=20around=20the=20globe,=20visit http://www.messagelabs.com ________________________________________________________________________ _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Thu Dec 4 04:54:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18034 for ; Thu, 4 Dec 2003 04:54:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARqBQ-0002c5-M4 for xcon-archive@odin.ietf.org; Thu, 04 Dec 2003 04:54:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB49s4pD010044 for xcon-archive@odin.ietf.org; Thu, 4 Dec 2003 04:54:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARqBQ-0002bv-8s for xcon-web-archive@optimus.ietf.org; Thu, 04 Dec 2003 04:54:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18031 for ; Thu, 4 Dec 2003 04:53:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARqBN-0005SN-00 for xcon-web-archive@ietf.org; Thu, 04 Dec 2003 04:54:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARqBM-0005SK-00 for xcon-web-archive@ietf.org; Thu, 04 Dec 2003 04:54:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARqBN-0002bZ-7s; Thu, 04 Dec 2003 04:54:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARqBC-0002bK-2m for xcon@optimus.ietf.org; Thu, 04 Dec 2003 04:53:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18025 for ; Thu, 4 Dec 2003 04:53:33 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARqB8-0005SB-00 for xcon@ietf.org; Thu, 04 Dec 2003 04:53:46 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1ARqB7-0005S8-00 for xcon@ietf.org; Thu, 04 Dec 2003 04:53:46 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hB49rkV11361 for ; Thu, 4 Dec 2003 11:53:46 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 4 Dec 2003 11:53:37 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 4 Dec 2003 11:53:36 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] Chicken and Egg - Can CPCP create a conference Date: Thu, 4 Dec 2003 11:53:34 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797492@esebe019.ntc.nokia.com> Thread-Topic: [XCON] Chicken and Egg - Can CPCP create a conference Thread-Index: AcO6Gm09Hmyno4b6Rxu4qEbcoUBwwwAMdniw To: , Cc: X-OriginalArrivalTime: 04 Dec 2003 09:53:36.0127 (UTC) FILETIME=[7C3EB0F0:01C3BA4C] Content-Transfer-Encoding: quoted-printable Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable I can't believe people still think time zones are a problem. There are = many time zone standards that can be used. The only requirement is that = the client and the server need to implement the same one. That is hardly = a show stopper. /Hisham > -----Original Message----- > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On Behalf Of ext > Nermeen Ismail > Sent: 04.December.2003 05:56 > To: Rosen, Brian > Cc: xcon@ietf.org > Subject: RE: [XCON] Chicken and Egg - Can CPCP create a conference >=20 >=20 > I have just seen this thread so I might be repeating what is=20 > laredy been said. >=20 > I agree that from the protocols point of view a conference is=20 > a conference.=20 > It does not matter if it is ad hoc or scheduled. It has a=20 > unique URI, its=20 > policy can be manipulated and authorized users can join/leave=20 > them either=20 > by dial-in or dial-out. >=20 > My understanding for why there are two ways to create a=20 > conference is to=20 > support : > 1- Creating a conference and joining it without having to implement=20 > anything other than SIP (cc-conferencing). In this case sending an > INVITE to the URI factory is sufficient. Off course if the=20 > endpoint needs=20 > to do something more like modifying the conference policy then > it needs to also implement CPCP/MPCP in which case it might=20 > have just used=20 > that to create the conference. However the point is still that an=20 > application can create, join a conference and get the roster without=20 > needing anything other than a SIP stack. >=20 > 2- Creating a conference and never joining it. This is like=20 > the case of a=20 > scheduling automata that at the time of conference scheduling=20 > it creates a > conference and a focus. In this case and as the application=20 > will never send=20 > or receive media to the conference it was deemed=20 > inappropriate to demand=20 > the application to have a SIP stack and send a no-media=20 > INVITE to create=20 > the conference. Hence some non-SIP method will be used to create the=20 > conference. A non-sip method will be used to create the=20 > conference (enters=20 > CPCP) and this create-conference will be sent to the top-level policy=20 > server URI which in return will send the conference URI and=20 > the policy=20 > server URI for that conference. The only benefot that this method has > over number 1 is that the application does not have to support SIP. >=20 > So a conference server needs to have a SIP stack, CPCP/MPCP and the=20 > conference package but a client might only have a SIP stack,=20 > a CPCP/MPCP=20 > implementation or both. >=20 > On a separate topic, it was mentioned before that when a=20 > conference is=20 > created a future start time can be specified. I see lots of=20 > complications=20 > with that to do with time zones etc. Already the client that=20 > created the=20 > conference has to deal with that and I do not see any benefit=20 > in extending > that to the conference server as well. So I see benefits in=20 > specifying a=20 > conference duration but no benefit in specifying conference=20 > start time. > If the client creating the conference wishes the conference to start=20 > accepting users in 5 minutes time then it needs to delay=20 > sending the create=20 > conference 5 minutes. >=20 >=20 > nermeen >=20 >=20 >=20 >=20 >=20 > > > >We must stop talking about "ad-hoc conferences" and "scheduled > > > conferences" > > > >- there is no such thing. There are only ad-hoc mechanisms and > > > scheduled > > > >mechanisms to create/join a conference. > >Which, I think, is completely useless. > >And, to be specific: > > There is no difference in how you join a conference > > You always send an INVITE, or get a REFER, > > or receive an INVITE. You can't join with > > CPCP. > > There is no reason to have a difference to create one > > > > > > > > [Chris Boulton] I totally agree. Whether 'ad-hoc' or > > > 'scheduled' means > > > are used to create a conference should have no effect - a=20 > conference > > > should be created and a default policy applied. Then, if it is an > > > 'ad-hoc' conference, a participant is free to join and if it is a > > > scheduled, the creator may manipulate the conference policy. > >Why is it different with ad-hoc that a participant is free to join? > >Why is it different with scheduled that the creator may manipulate > >the conference policy? > > > >I think there is no difference at all. No matter how you create it, > >participants are free to join any time the policy says they pay. > >No matter how you create it, the creator may manipulate the=20 > conference > >policy (and participants may manipulate it also, subject to=20 > permissions). > > > > > > > >So, if The Example Company already has their public web=20 > server home > > > page at > > > >example.com where everyone goes to download the latest=20 > examples, this > > > web > > > >server now needs to become the conference policy server? > >No, unless the example.com is also the focus host. If it=20 > is, then the > >web server is there too. That is just not a limitation worth worrying > >about. > > > > > > > > > > > >There are significant disadvantages in limiting ourselves to such > > > >conventions - especially when there are other ways of=20 > discovering the > > > >policy URI. One way that has been discussed is advertising > > > the policy > > > URI > > > >in conference package notifications. Is this not=20 > sufficient? This > > > >approach is flexible and extensible (different protocols=20 > for policy > > > >manipulation can be defined with a new URI scheme) and has > > > none of the > > > name > > > >space limitations of this proposal. > > > > > > [Chris Boulton] This approach does seem to 'shoe-horn'=20 > the HTTP usage > > > and IMHO is quite an ugly solution. As Alan points out,=20 > policy URI > > > contained in conference packages is a far more elegant solution. > > > > >My problem is that we seem to be heading to a solution where there > >is no subset of capabilities. To do anything, you need to implement: > > cc conference > >AND > > cpcp > >AND > > mpcp > >AND > > the conference package > > > >There are no simple implementations other than conference unaware. > >Is that really what we want to do? Intertwine all the pieces so that > >there is no clean functional separation that allows implementation > >flexibility without creating incompatibility? In this specific > >case, why do you have to implement the conference package in order > >to discover the conference policy uri? > > > >A message or two ago, Alan talked about automata=20 > manipulating conference > >policy, and you were aghast that I proposed using SIP means to > >create a conference ID. You now want the automata to use SIP means > >to find a conference policy URI given a conference URI; they=20 > even have > >to join the conference to do so, unless the automata created the > >conference in the first place, where it may get the conference policy > >uri returned to it). > > > >Can't we give up a slight amount of flexibility to get the=20 > possibility > >of more widespread use of this facility by limiting implementation > >complexity? Maybe we need some use case stuff to see how=20 > subsets might > >be useful. > > > > > >_______________________________________________ > >XCON mailing list > >XCON@ietf.org > >https://www1.ietf.org/mailman/listinfo/xcon >=20 >=20 > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon >=20 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Thu Dec 4 04:57:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18081 for ; Thu, 4 Dec 2003 04:57:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARqEK-0002hk-MT for xcon-archive@odin.ietf.org; Thu, 04 Dec 2003 04:57:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB49v4Ki010395 for xcon-archive@odin.ietf.org; Thu, 4 Dec 2003 04:57:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARqEJ-0002hB-5Y for xcon-web-archive@optimus.ietf.org; Thu, 04 Dec 2003 04:57:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18066 for ; Thu, 4 Dec 2003 04:56:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARqEF-0005T5-00 for xcon-web-archive@ietf.org; Thu, 04 Dec 2003 04:56:59 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARqEE-0005T2-00 for xcon-web-archive@ietf.org; Thu, 04 Dec 2003 04:56:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARqEH-0002gc-3Q; Thu, 04 Dec 2003 04:57:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARqDo-0002g5-Ks for xcon@optimus.ietf.org; Thu, 04 Dec 2003 04:56:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18058 for ; Thu, 4 Dec 2003 04:56:11 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARqDg-0005St-00 for xcon@ietf.org; Thu, 04 Dec 2003 04:56:24 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1ARqDf-0005Sq-00 for xcon@ietf.org; Thu, 04 Dec 2003 04:56:23 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hB49uNw12748 for ; Thu, 4 Dec 2003 11:56:23 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 4 Dec 2003 11:56:21 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 4 Dec 2003 11:56:20 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] Chicken and Egg - Can CPCP create a conference Date: Thu, 4 Dec 2003 11:56:19 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797493@esebe019.ntc.nokia.com> Thread-Topic: [XCON] Chicken and Egg - Can CPCP create a conference Thread-Index: AcO6Gj0jjFVhTSHoR6OGtzl/PbDsuQAKlnJwAAH+xnA= To: , , Cc: X-OriginalArrivalTime: 04 Dec 2003 09:56:20.0857 (UTC) FILETIME=[DE6E7E90:01C3BA4C] Content-Transfer-Encoding: quoted-printable Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable This is up to your conference server's intelligence. The server should = have rejected the second conference creation request if it has a first = come first serve logic. Or it can prioritise according to some method = (or you can buy more ports :) I don't think this is a show stopper = either. /Hisham > -----Original Message----- > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On Behalf Of ext > Chris Boulton > Sent: 04.December.2003 11:03 > To: Nermeen Ismail; Rosen, Brian > Cc: xcon@ietf.org > Subject: RE: [XCON] Chicken and Egg - Can CPCP create a conference >=20 >=20 >=20 >=20 > >-----Original Message----- > >From: Nermeen Ismail [mailto:nismail@cisco.com] > >Sent: 04 December 2003 03:56 > >To: Rosen, Brian > >Cc: xcon@ietf.org > >Subject: RE: [XCON] Chicken and Egg - Can CPCP create a conference > > > >I have just seen this thread so I might be repeating what is laredy > been > >said. > > > >I agree that from the protocols point of view a conference is a > conference. > >It does not matter if it is ad hoc or scheduled. It has a unique URI, > its > >policy can be manipulated and authorized users can join/leave them > either > >by dial-in or dial-out. > > > >My understanding for why there are two ways to create a conference is > to > >support : > >1- Creating a conference and joining it without having to implement > >anything other than SIP (cc-conferencing). In this case sending an > >INVITE to the URI factory is sufficient. Off course if the endpoint > needs > >to do something more like modifying the conference policy then > >it needs to also implement CPCP/MPCP in which case it might have just > used > >that to create the conference. However the point is still that an > >application can create, join a conference and get the roster without > >needing anything other than a SIP stack. > > > >2- Creating a conference and never joining it. This is like=20 > the case of > a > >scheduling automata that at the time of conference scheduling it > creates a > >conference and a focus. In this case and as the application=20 > will never > send > >or receive media to the conference it was deemed inappropriate to > demand > >the application to have a SIP stack and send a no-media INVITE to > create > >the conference. Hence some non-SIP method will be used to create the > >conference. A non-sip method will be used to create the conference > (enters > >CPCP) and this create-conference will be sent to the top-level policy > >server URI which in return will send the conference URI and=20 > the policy > >server URI for that conference. The only benefot that this method has > >over number 1 is that the application does not have to support SIP. > > > >So a conference server needs to have a SIP stack, CPCP/MPCP and the > >conference package but a client might only have a SIP stack, a > CPCP/MPCP > >implementation or both. > > > >On a separate topic, it was mentioned before that when a=20 > conference is > >created a future start time can be specified. I see lots of > complications > >with that to do with time zones etc. Already the client that created > the > >conference has to deal with that and I do not see any benefit in > extending > >that to the conference server as well. So I see benefits in=20 > specifying > a > >conference duration but no benefit in specifying conference=20 > start time. > >If the client creating the conference wishes the conference to start > >accepting users in 5 minutes time then it needs to delay sending the > create > >conference 5 minutes. >=20 > [Chris Boulton] I'm not disagreeing with this point just=20 > thinking about > it a bit more. I guess the main concern I have is related to the > scheduling of resources. Are you saying that resources would not be > scheduled (not reserved) for this conference until the moment=20 > it starts. > So if I schedule a conference for a weeks time - then on the=20 > day of the > conference, one of my colleagues schedules + starts a conference 10 > minutes before mine and uses up all of my companies port allocation - > that means it's tough for me???? (And the answer isn't to buy more > ports before anyone suggests it ;-) >=20 > > > > > >nermeen > > > > > > > > > > > >> > >We must stop talking about "ad-hoc conferences" and "scheduled > >> > conferences" > >> > >- there is no such thing. There are only ad-hoc mechanisms and > >> > scheduled > >> > >mechanisms to create/join a conference. > >>Which, I think, is completely useless. > >>And, to be specific: > >> There is no difference in how you join a conference > >> You always send an INVITE, or get a REFER, > >> or receive an INVITE. You can't join with > >> CPCP. > >> There is no reason to have a difference to create one > >> > >> > > >> > [Chris Boulton] I totally agree. Whether 'ad-hoc' or > >> > 'scheduled' means > >> > are used to create a conference should have no effect - a > conference > >> > should be created and a default policy applied. Then,=20 > if it is an > >> > 'ad-hoc' conference, a participant is free to join and if it is a > >> > scheduled, the creator may manipulate the conference policy. > >>Why is it different with ad-hoc that a participant is free to join? > >>Why is it different with scheduled that the creator may manipulate > >>the conference policy? > >> > >>I think there is no difference at all. No matter how you create it, > >>participants are free to join any time the policy says they pay. > >>No matter how you create it, the creator may manipulate the=20 > conference > >>policy (and participants may manipulate it also, subject to > permissions). > >> > >> > >> > >So, if The Example Company already has their public web server > home > >> > page at > >> > >example.com where everyone goes to download the latest examples, > this > >> > web > >> > >server now needs to become the conference policy server? > >>No, unless the example.com is also the focus host. If it=20 > is, then the > >>web server is there too. That is just not a limitation=20 > worth worrying > >>about. > >> > >> > >> > > > >> > >There are significant disadvantages in limiting=20 > ourselves to such > >> > >conventions - especially when there are other ways of=20 > discovering > the > >> > >policy URI. One way that has been discussed is advertising > >> > the policy > >> > URI > >> > >in conference package notifications. Is this not sufficient? > This > >> > >approach is flexible and extensible (different protocols for > policy > >> > >manipulation can be defined with a new URI scheme) and has > >> > none of the > >> > name > >> > >space limitations of this proposal. > >> > > >> > [Chris Boulton] This approach does seem to 'shoe-horn' the HTTP > usage > >> > and IMHO is quite an ugly solution. As Alan points out,=20 > policy URI > >> > contained in conference packages is a far more elegant solution. > >> > > >>My problem is that we seem to be heading to a solution where there > >>is no subset of capabilities. To do anything, you need to=20 > implement: > >> cc conference > >>AND > >> cpcp > >>AND > >> mpcp > >>AND > >> the conference package > >> > >>There are no simple implementations other than conference unaware. > >>Is that really what we want to do? Intertwine all the=20 > pieces so that > >>there is no clean functional separation that allows implementation > >>flexibility without creating incompatibility? In this specific > >>case, why do you have to implement the conference package in order > >>to discover the conference policy uri? > >> > >>A message or two ago, Alan talked about automata manipulating > conference > >>policy, and you were aghast that I proposed using SIP means to > >>create a conference ID. You now want the automata to use SIP means > >>to find a conference policy URI given a conference URI;=20 > they even have > >>to join the conference to do so, unless the automata created the > >>conference in the first place, where it may get the=20 > conference policy > >>uri returned to it). > >> > >>Can't we give up a slight amount of flexibility to get the=20 > possibility > >>of more widespread use of this facility by limiting implementation > >>complexity? Maybe we need some use case stuff to see how subsets > might > >>be useful. > >> > >> > >>_______________________________________________ > >>XCON mailing list > >>XCON@ietf.org > >>https://www1.ietf.org/mailman/listinfo/xcon > > > > > >_______________________________________________ > >XCON mailing list > >XCON@ietf.org > >https://www1.ietf.org/mailman/listinfo/xcon > > > >_____________________________________________________________ > __________ > _ > >This email has been scanned for all viruses by the MessageLabs Email > >Security System. For more information on a proactive email security > >service working around the clock, around the globe, visit > >http://www.messagelabs.com > >_____________________________________________________________ > __________ > _ >=20 > ______________________________________________________________ > __________ > This email has been scanned for all viruses by the MessageLabs Email > Security System. For more information on a proactive email security > service working around the clock, around the globe, visit > http://www.messagelabs.com > ______________________________________________________________ > __________ >=20 > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon >=20 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Thu Dec 4 06:44:18 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20817 for ; Thu, 4 Dec 2003 06:44:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARrtt-0000Cb-OA for xcon-archive@odin.ietf.org; Thu, 04 Dec 2003 06:44:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB4Bi5Mg000771 for xcon-archive@odin.ietf.org; Thu, 4 Dec 2003 06:44:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARrtt-0000CM-Jw for xcon-web-archive@optimus.ietf.org; Thu, 04 Dec 2003 06:44:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20800 for ; Thu, 4 Dec 2003 06:43:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARrtp-0006ga-00 for xcon-web-archive@ietf.org; Thu, 04 Dec 2003 06:44:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARrto-0006gX-00 for xcon-web-archive@ietf.org; Thu, 04 Dec 2003 06:44:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARrtp-0000AS-PP; Thu, 04 Dec 2003 06:44:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARrtL-00007w-Pm for xcon@optimus.ietf.org; Thu, 04 Dec 2003 06:43:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20786 for ; Thu, 4 Dec 2003 06:43:14 -0500 (EST) From: aki.niemi@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARrtH-0006g8-00 for xcon@ietf.org; Thu, 04 Dec 2003 06:43:27 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1ARrtG-0006g1-00 for xcon@ietf.org; Thu, 04 Dec 2003 06:43:27 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hB4BhRV12529 for ; Thu, 4 Dec 2003 13:43:27 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 4 Dec 2003 13:43:27 +0200 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 4 Dec 2003 13:43:27 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] Chicken and Egg - Can CPCP create a conference Date: Thu, 4 Dec 2003 13:43:27 +0200 Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD902D592F0@esebe013.ntc.nokia.com> Thread-Topic: [XCON] Chicken and Egg - Can CPCP create a conference Thread-Index: AcO5209o+fZpgKN/TGqWjYfbPaph6AAfvqKw To: Cc: X-OriginalArrivalTime: 04 Dec 2003 11:43:27.0584 (UTC) FILETIME=[D50F3600:01C3BA5B] Content-Transfer-Encoding: quoted-printable Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi, Inline. > > >No, unless the example.com is also the focus host. If it=20 > > is, then the > > >web server is there too. That is just not a limitation=20 > worth worrying > > >about. > >=20 > > Look at Hisham's example - they are the same. One can get=20 > > around it by=20 > > having an application server that does 3pcc, or some sort of=20 > > HTTP proxy,=20 > > but why require all this complexity? Why must my media=20 > > server be my policy=20 > > server as well? > We're assuming XCAP, right? So a "web server" is not just a web > server, it's an XCAP server. If it is the CPCP server; you can't > separate the http part from the xcap part from the cpcp part; they > are the same thing. >=20 > If your media server is your conference server (focus), then it's > not much of a stretch at all to force it to be your conference > policy server, at least now. Now, that doesn't mean that you can't, > for example, use the media server as a mixer, and have the focus > be part of some proxy server, controlling the mixer with, say, > Megaco. It seems pretty impractical to separate the conference > policy server from the focus, because they are so intertwined. I don't like to couple these elements unnecessarily using any type of = URI naming conventions. An equally possible setup is one where the = policy server is in fact separate XCAP server, and both the conference = participant and the focus are XCAP clients. In any case, aren't we talking about simply passing on some information = about the conference to its participants. So, have the focus return in a = 200 OK to an INVITE: Call-Info: = ;purpose=3Dxcap-cpcp This lets the client know where to go and do XCAP CPCP if it wants to = manipulate the policy. Cheers, Aki _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Thu Dec 4 06:52:15 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21107 for ; Thu, 4 Dec 2003 06:52:15 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARs1a-0000rS-Ek for xcon-archive@odin.ietf.org; Thu, 04 Dec 2003 06:52:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB4Bq22U003304 for xcon-archive@odin.ietf.org; Thu, 4 Dec 2003 06:52:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARs1a-0000rD-A7 for xcon-web-archive@optimus.ietf.org; Thu, 04 Dec 2003 06:52:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21059 for ; Thu, 4 Dec 2003 06:51:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARs1W-0006tJ-00 for xcon-web-archive@ietf.org; Thu, 04 Dec 2003 06:51:58 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARs1V-0006tG-00 for xcon-web-archive@ietf.org; Thu, 04 Dec 2003 06:51:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARs1Z-0000pz-82; Thu, 04 Dec 2003 06:52:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARs0k-0000d8-1T for xcon@optimus.ietf.org; Thu, 04 Dec 2003 06:51:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21023 for ; Thu, 4 Dec 2003 06:50:52 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARs0f-0006rj-00 for xcon@ietf.org; Thu, 04 Dec 2003 06:51:05 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1ARs0e-0006rb-00 for xcon@ietf.org; Thu, 04 Dec 2003 06:51:04 -0500 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hB4Bp5w22380 for ; Thu, 4 Dec 2003 13:51:05 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 4 Dec 2003 13:51:05 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 4 Dec 2003 13:51:05 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] Chicken and Egg - Can CPCP create a conference Date: Thu, 4 Dec 2003 13:51:04 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB70179749D@esebe019.ntc.nokia.com> Thread-Topic: [XCON] Chicken and Egg - Can CPCP create a conference Thread-Index: AcO5209o+fZpgKN/TGqWjYfbPaph6AAfvqKwAACSeyA= To: , Cc: X-OriginalArrivalTime: 04 Dec 2003 11:51:05.0190 (UTC) FILETIME=[E5D05860:01C3BA5C] Content-Transfer-Encoding: quoted-printable Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On Behalf Of ext > aki.niemi@nokia.com > Sent: 04.December.2003 13:43 > To: Brian.Rosen@marconi.com > Cc: xcon@ietf.org > Subject: RE: [XCON] Chicken and Egg - Can CPCP create a conference >=20 >=20 > Hi, >=20 > Inline. >=20 > > > >No, unless the example.com is also the focus host. If it=20 > > > is, then the > > > >web server is there too. That is just not a limitation=20 > > worth worrying > > > >about. > > >=20 > > > Look at Hisham's example - they are the same. One can get=20 > > > around it by=20 > > > having an application server that does 3pcc, or some sort of=20 > > > HTTP proxy,=20 > > > but why require all this complexity? Why must my media=20 > > > server be my policy=20 > > > server as well? > > We're assuming XCAP, right? So a "web server" is not just a web > > server, it's an XCAP server. If it is the CPCP server; you can't > > separate the http part from the xcap part from the cpcp part; they > > are the same thing. > >=20 > > If your media server is your conference server (focus), then it's > > not much of a stretch at all to force it to be your conference > > policy server, at least now. Now, that doesn't mean that=20 > you can't, > > for example, use the media server as a mixer, and have the focus > > be part of some proxy server, controlling the mixer with, say, > > Megaco. It seems pretty impractical to separate the conference > > policy server from the focus, because they are so intertwined. >=20 > I don't like to couple these elements unnecessarily using any=20 > type of URI naming conventions. An equally possible setup is=20 > one where the policy server is in fact separate XCAP server,=20 > and both the conference participant and the focus are XCAP clients. >=20 > In any case, aren't we talking about simply passing on some=20 > information about the conference to its participants. So,=20 > have the focus return in a 200 OK to an INVITE: >=20 > Call-Info:=20 > icy12345.xml>;purpose=3Dxcap-cpcp >=20 > This lets the client know where to go and do XCAP CPCP if it=20 > wants to manipulate the policy. This would work for participants who don't want to subscribe to the = conference event package. Carrying the policy ID in the event package is = also beneficial in that users can manipulate the conference policy = without having to actually join the conference. They learn the policy ID = using SUB/NOT without having to send INVITE. So I guess both methods are needed. Regards, Hisham >=20 > Cheers, > Aki >=20 >=20 >=20 > >=20 > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon >=20 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Thu Dec 4 07:01:17 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21433 for ; Thu, 4 Dec 2003 07:01:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARsAK-00022O-Gc for xcon-archive@odin.ietf.org; Thu, 04 Dec 2003 07:01:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB4C14iO007826 for xcon-archive@odin.ietf.org; Thu, 4 Dec 2003 07:01:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARsAK-000229-CB for xcon-web-archive@optimus.ietf.org; Thu, 04 Dec 2003 07:01:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21415 for ; Thu, 4 Dec 2003 07:00:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARsAF-00073A-00 for xcon-web-archive@ietf.org; Thu, 04 Dec 2003 07:00:59 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARsAF-000737-00 for xcon-web-archive@ietf.org; Thu, 04 Dec 2003 07:00:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARsAJ-000217-4N; Thu, 04 Dec 2003 07:01:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARs9y-00020H-DB for xcon@optimus.ietf.org; Thu, 04 Dec 2003 07:00:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21411 for ; Thu, 4 Dec 2003 07:00:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARs9t-00072p-00 for xcon@ietf.org; Thu, 04 Dec 2003 07:00:37 -0500 Received: from mtagate1.de.ibm.com ([195.212.29.150]) by ietf-mx with esmtp (Exim 4.12) id 1ARs9r-000724-00 for xcon@ietf.org; Thu, 04 Dec 2003 07:00:35 -0500 Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180] (may be forged)) by mtagate1.de.ibm.com (8.12.10/8.12.10) with ESMTP id hB4C03RJ087836 for ; Thu, 4 Dec 2003 12:00:03 GMT Received: from d10ml001.telaviv.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12relay01.megacenter.de.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id hB4C014x275216 for ; Thu, 4 Dec 2003 13:00:02 +0100 In-Reply-To: <3FCE7495.2020402@cisco.com> MIME-Version: 1.0 To: xcon@ietf.org Subject: Re: [XCON] Chicken and Egg - Can CPCP create a conference X-Mailer: Lotus Notes Build V65_07292003 July 29, 2003 Message-ID: From: Avshalom Houri Date: Thu, 4 Dec 2003 13:59:52 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 6.0.2CF2|July 23, 2003) at 04/12/2003 14:00:02, Serialize complete at 04/12/2003 14:00:02 Content-Type: multipart/alternative; boundary="=_alternative 0041E7A4C2256DF2_=" Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , This is a multipart message in MIME format. --=_alternative 0041E7A4C2256DF2_= Content-Type: text/plain; charset="US-ASCII" I agree with Paul, Alan and I think that also Orit. The XCON protocol should be a different protocol from SIP. Other protocols that will want to create conferences should be able to use ti. Reading again the XCON charter it explicitly says that the XCON protocol can be used by other protocols. I think that coupling INVITE with the conference creation does not agree with the charter. <<< Due to the centralized architecture of the WG, XCON's mechanisms will place requirements on the signaling protocol used between the focus and the participants. At a high level, the signaling protocol must be able to establish, tear down, modify, and perform call control operations on multimedia streams, including voice, video, and instant messaging, in both a centralized and distributed mixing architecture. SIP will be the reference session signaling protocol used for examples; however, none of the XCON solutions themselves will be signaling protocols, nor will XCON extend existing signaling protocols. Other signaling protocols than SIP may be used between the focus and participants, including non-IETF protocols, but the requirements and possible extensions needed for other signaling protocols to utilize the full functionality of the XCON architecture is outside the scope of XCON. >>> Avshalom _______________________ Avshalom Houri Architect - Lotus Software, IBM SWG Science Park, Building 18 floor D Rehovot, Israel 76470 Email: avshalom@il.ibm.com Office: +972-8-9409761 Ext. 123 Fax: +972-8-9944697 Cell: +972-54-686021 Paul Kyzivat Sent by: xcon-admin@ietf.org 04/12/2003 01:41 AM To xcon@ietf.org cc Subject Re: [XCON] Chicken and Egg - Can CPCP create a conference I am in agreement with Alan and others that binding the names of the two uris together algorithmically is a terrible idea, at least as part of a standard. (There is nothing to stop a particular implementation from doing this. It just won't be interoperable, and needn't be.) What we have here are not two names for the same thing, but rather two names for different things that happen to be in 1:1 correspondence with one another. We have - a sip uri identifying the focus of a conference - an http uri identifying the policy for a conference If all an application cares about is call control, then all it needs to implement is sip, and the only identifier it needs is the sip uri. If all an application cares about is policy managment, then all it needs to implement is http and xcap, and the only identifier it needs is the http uri. If an application cares about both of these, then it must implement both sets of protocols, and it needs both uris. Each protocol should provide a protocol to obtain the uri for the other object/protocol. Paul Rosen, Brian wrote: > I don't understand this. I'm not changing the definition of a focus. > I'm observing that the host of the focus is the host of the policy > server, at least for now. At some point in the future, we could > change this, but now, we can easily make them the same. > > If we use XCAP for CPCP, this seems very straightforward, > and it's even a uri! > > suppose the conferenceID is: > sip:hishams-weekly-status-meeting@confa.example.com > > Then the XCAP URI for this conference is > http:confa.example.com/cpcp/hishams-weekly-status-meeting... > > at least for now. All I propose is that the root service uri for > CPCP be slightly more structured for CPCP than XCAP, which proposes > that the root service uri be provisioned. If this offends you > that much, you could always say that if you have an XCAP service > root, use it, adding cpcp/hishams-weekly-status-meeting to it > to access the policy for this conference. > > If it's not XCAP, we still use the focus host as the CPCP host, > and the conference uri userpart as the id, with whatever convention > the chosen protocol uses to encode it. > > >>-----Original Message----- >>From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] >>Sent: Wednesday, December 03, 2003 9:44 AM >>To: Brian.Rosen@marconi.com; pkyzivat@cisco.com >>Cc: rohan@cisco.com; alan.johnston@mci.com; georg.mayer@nokia.com; >>oritl@microsoft.com; xcon@ietf.org >>Subject: RE: [XCON] Chicken and Egg - Can CPCP create a conference >> >> >>You are asking to change the definition of a focus. It is >>created when the conference is instantiated (using your >>definition of instantiation) and destroyed when the >>conference instance is destroyed. Therefore, pre-establishing >>a conference is not possible using CPCP unless a conference >>is instantiated. That is not desirable. >> >>We have a conference framework in place, lets use it. >> >>/Hisham >> >> >>>-----Original Message----- >>>From: ext Rosen, Brian [mailto:Brian.Rosen@marconi.com] >>>Sent: 03.December.2003 14:58 >>>To: 'Paul Kyzivat' >>>Cc: Khartabil Hisham (NMP-MSW/Helsinki); rohan@cisco.com; >>>alan.johnston@mci.com; Mayer Georg (NMP-MSW/Helsinki); >>>oritl@microsoft.com; xcon@ietf.org >>>Subject: RE: [XCON] Chicken and Egg - Can CPCP create a conference >>> >>> >>>Ah, I wondered when we would get to this. >>> >>>This is one of the bigger problems in separating conference policy >>>from sip signalling. Everything would be simpler if the conference >>>policy server was always the focus. >>> >>>So, I want to ask, can we make it be so? >>> >>>What are the advantages of making the conference policy server >>>separate from the focus? Two ideas occur to me: >>> 1. Separation of implementation >>> But this is not possible with the current framework >>> because we don't specify the interface between >>> CPCP and SIP; we assume that it is proprietary >>> 2. Load Balancing >>> But I really, really doubt that works. It >>>would be easier >>> to have a separate CPS with every focus, and replicate >>> the combination >>> >>>So, what if we assume they are the same entity, and use the same ID? >>>We don't need to have the conference policy be a URI, we merely have >>>to locate the address of the server. So, it's the hostname of the >>>conference URI. And a sip uri is a fine conference ID for the >>>purpose of specifying which policy once we know where the server is. >>> >>>Is there some advantage of having the conference policy explicitly >>>be a URI that I'm missing? >>> >>>Brian >>> >>> >>>>-----Original Message----- >>>>From: Paul Kiribati [mailto:pkyzivat@cisco.com] >>>>Sent: Tuesday, December 02, 2003 2:44 PM >>>>To: Rosen, Brian >>>>Cc: 'hisham.khartabil@nokia.com'; rohan@cisco.com; >>>>alan.johnston@mci.com; georg.mayer@nokia.com; oritl@microsoft.com; >>>>xcon@ietf.org >>>>Subject: Re: [XCON] Chicken and Egg - Can CPCP create a conference >>>> >>>> >>>> >>>> >>>>Rosen, Brian wrote: >>>> >>>>>>If you look at XCAP list usage for example, you will see that >>>>>>the list-URI used when sending SIP SUBSCRIBE requests to the >>>>>>list is not the same as the URI used to manipulate the list >>>>>>using XCAP. They certainly need to be linked, but not >>>>>>necessarily the same. >>>>>> >>>>>>Depending on the protocol we chose, a SIP URI can or cannot >>>>>>be used to identify a conference policy. >>>>> >>>>>I think we CAN always have the same ID. >>>>>I think there is a lot of value in one ID >>>>>I don't think there is any problem in having one ID >>>>> >>>>>So, I think there should be one. >>>>> >>>>>If there is a good reason, we can burden the conference >>>> >>>>policy server >>>> >>>>>with keeping the relationship, but unless there is a good >>>> >>>>reason, history >>>> >>>>>suggests that one namespace is better than two with linkage. >>>> >>>>[The chicken and the egg are different things. If I want to >>>>talk to the >>>>egg I need the address of the egg - having the address of >>> >>>the chicken >>> >>>>isn't sufficient. Its probably a bad idea to crack the egg in >>>>order to >>>>ask the chicken for the address of the egg.] >>>> >>>>Getting away from metaphors, this seems to be coming down to the >>>>distinction between URIs and URLs. >>>> >>>>A sip address is a URL in that it is sufficient for me to >>> >>locate a >> >>>>corresponding (sip) resource. >>>> >>>>But it isn't sufficient for me to locate a CPCP resource. If >>>>I knew how >>>>to contact the appropriate CPCP server, perhaps a sip uri >>>>could serve to >>>>identify the policy. But that would require me to know the >>> >>>address of >>> >>>>the server a-priori. >>>> >>>>If all I have is the sip conference id, then to derive the >>>>URI for the >>>>policy from it I must invoke sip operations on it. >>>> >>>> Paul >>>> >>>> >>>>_______________________________________________ >>>>XCON mailing list >>>>XCON@ietf.org >>>>https://www1.ietf.org/mailman/listinfo/xcon >>>> >>> >>_______________________________________________ >>XCON mailing list >>XCON@ietf.org >>https://www1.ietf.org/mailman/listinfo/xcon >> > > _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon --=_alternative 0041E7A4C2256DF2_= Content-Type: text/html; charset="US-ASCII"
I agree with Paul, Alan and I think that also Orit. The XCON protocol should be a different protocol from SIP.
Other protocols that will want to create conferences should be able to use ti.

Reading again the XCON charter it explicitly says that the XCON protocol can be used by other protocols.
I think that  coupling INVITE with the conference creation does not agree with the charter.

<<<
Due to the centralized architecture of the WG, XCON's mechanisms will
place requirements on the signaling protocol used between the focus and
the participants. At a high level, the signaling protocol must be able
to establish, tear down, modify, and perform call control operations on
multimedia streams, including voice, video, and instant messaging, in
both a centralized and distributed mixing architecture. SIP will be the
reference session signaling protocol used for examples; however, none of
the XCON solutions themselves will be signaling protocols, nor will XCON
extend existing signaling protocols. Other signaling protocols than SIP
may be used between the focus and participants, including non-IETF
protocols, but the requirements and possible extensions needed for other
signaling protocols to utilize the full functionality of the XCON
architecture is outside the scope of XCON.
>>>

Avshalom
_______________________
Avshalom Houri
Architect - Lotus Software, IBM SWG
Science Park, Building 18 floor D Rehovot, Israel 76470
Email: avshalom@il.ibm.com
Office: +972-8-9409761 Ext. 123 Fax: +972-8-9944697 Cell: +972-54-686021


Paul Kyzivat <pkyzivat@cisco.com>
Sent by: xcon-admin@ietf.org

04/12/2003 01:41 AM

To
 xcon@ietf.org
cc
Subject
Re: [XCON] Chicken and Egg - Can CPCP create a conference





I am in agreement with Alan and others that binding the names of the two
 uris together algorithmically is a terrible idea, at least as part of
a standard. (There is nothing to stop a particular implementation from
doing this. It just won't be interoperable, and needn't be.)

What we have here are not two names for the same thing, but rather two
names for different things that happen to be in 1:1 correspondence with
one another. We have
- a sip uri identifying the focus of a conference
- an http uri identifying the policy for a conference

If all an application cares about is call control, then all it needs to
implement is sip, and the only identifier it needs is the sip uri.

If all an application cares about is policy managment, then all it needs
to implement is http and xcap, and the only identifier it needs is the
http uri.

If an application cares about both of these, then it must implement both
sets of protocols, and it needs both uris. Each protocol should provide
a protocol to obtain the uri for the other object/protocol.

                Paul

Rosen, Brian wrote:
> I don't understand this.  I'm not changing the definition of a focus.
> I'm observing that the host of the focus is the host of the policy
> server, at least for now.  At some point in the future, we could
> change this, but now, we can easily make them the same.  
>
> If we use XCAP for CPCP, this seems very straightforward,
> and it's even a uri!
>
> suppose the conferenceID is:
>   sip:hishams-weekly-status-meeting@confa.example.com
>
> Then the XCAP URI for this conference is
>   http:confa.example.com/cpcp/hishams-weekly-status-meeting...
>
> at least for now.  All I propose is that the root service uri for
> CPCP be slightly more structured for CPCP than XCAP, which proposes
> that the root service uri be provisioned.  If this offends you
> that much, you could always say that if you have an XCAP service
> root, use it, adding cpcp/hishams-weekly-status-meeting to it
> to access the policy for this conference.
>
> If it's not XCAP, we still use the focus host as the CPCP host,
> and the conference uri userpart as the id, with whatever convention
> the chosen protocol uses to encode it.
>
>
>>-----Original Message-----
>>From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com]
>>Sent: Wednesday, December 03, 2003 9:44 AM
>>To: Brian.Rosen@marconi.com; pkyzivat@cisco.com
>>Cc: rohan@cisco.com; alan.johnston@mci.com; georg.mayer@nokia.com;
>>oritl@microsoft.com; xcon@ietf.org
>>Subject: RE: [XCON] Chicken and Egg - Can CPCP create a conference
>>
>>
>>You are asking to change the definition of a focus. It is
>>created when the conference is instantiated (using your
>>definition of instantiation) and destroyed when the
>>conference instance is destroyed. Therefore, pre-establishing
>>a conference is not possible using CPCP unless a conference
>>is instantiated. That is not desirable.
>>
>>We have a conference framework in place, lets use it.
>>
>>/Hisham
>>
>>
>>>-----Original Message-----
>>>From: ext Rosen, Brian [mailto:Brian.Rosen@marconi.com]
>>>Sent: 03.December.2003 14:58
>>>To: 'Paul Kyzivat'
>>>Cc: Khartabil Hisham (NMP-MSW/Helsinki); rohan@cisco.com;
>>>alan.johnston@mci.com; Mayer Georg (NMP-MSW/Helsinki);
>>>oritl@microsoft.com; xcon@ietf.org
>>>Subject: RE: [XCON] Chicken and Egg - Can CPCP create a conference
>>>
>>>
>>>Ah, I wondered when we would get to this.
>>>
>>>This is one of the bigger problems in separating conference policy
>>>from sip signalling.  Everything would be simpler if the conference
>>>policy server was always the focus.
>>>
>>>So, I want to ask, can we make it be so?
>>>
>>>What are the advantages of making the conference policy server
>>>separate from the focus?  Two ideas occur to me:
>>>                 1. Separation of implementation
>>>                                  But this is not possible with the current framework
>>>                                  because we don't specify the interface between
>>>                                  CPCP and SIP; we assume that it is proprietary
>>>                 2. Load Balancing
>>>                                  But I really, really doubt that works.  It
>>>would be easier
>>>                                  to have a separate CPS with every focus, and replicate
>>>                                  the combination
>>>
>>>So, what if we assume they are the same entity, and use the same ID?
>>>We don't need to have the conference policy be a URI, we merely have
>>>to locate the address of the server.  So, it's the hostname of the
>>>conference URI.  And a sip uri is a fine conference ID for the
>>>purpose of specifying which policy once we know where the server is.
>>>
>>>Is there some advantage of having the conference policy explicitly
>>>be a URI that I'm missing?
>>>
>>>Brian
>>>
>>>
>>>>-----Original Message-----
>>>>From: Paul Kiribati [mailto:pkyzivat@cisco.com]
>>>>Sent: Tuesday, December 02, 2003 2:44 PM
>>>>To: Rosen, Brian
>>>>Cc: 'hisham.khartabil@nokia.com'; rohan@cisco.com;
>>>>alan.johnston@mci.com; georg.mayer@nokia.com; oritl@microsoft.com;
>>>>xcon@ietf.org
>>>>Subject: Re: [XCON] Chicken and Egg - Can CPCP create a conference
>>>>
>>>>
>>>>
>>>>
>>>>Rosen, Brian wrote:
>>>>
>>>>>>If you look at XCAP list usage for example, you will see that
>>>>>>the list-URI used when sending SIP SUBSCRIBE requests to the
>>>>>>list is not the same as the URI used to manipulate the list
>>>>>>using XCAP. They certainly need to be linked, but not
>>>>>>necessarily the same.
>>>>>>
>>>>>>Depending on the protocol we chose, a SIP URI can or cannot
>>>>>>be used to identify a conference policy.
>>>>>
>>>>>I think we CAN always have the same ID.
>>>>>I think there is a lot of value in one ID
>>>>>I don't think there is any problem in having one ID
>>>>>
>>>>>So, I think there should be one.
>>>>>
>>>>>If there is a good reason, we can burden the conference
>>>>
>>>>policy server
>>>>
>>>>>with keeping the relationship, but unless there is a good
>>>>
>>>>reason, history
>>>>
>>>>>suggests that one namespace is better than two with linkage.
>>>>
>>>>[The chicken and the egg are different things. If I want to
>>>>talk to the
>>>>egg I need the address of the egg - having the address of
>>>
>>>the chicken
>>>
>>>>isn't sufficient. Its probably a bad idea to crack the egg in
>>>>order to
>>>>ask the chicken for the address of the egg.]
>>>>
>>>>Getting away from metaphors, this seems to be coming down to the
>>>>distinction between URIs and URLs.
>>>>
>>>>A sip address is a URL in that it is sufficient for me to
>>>
>>locate a
>>
>>>>corresponding (sip) resource.
>>>>
>>>>But it isn't sufficient for me to locate a CPCP resource. If
>>>>I knew how
>>>>to contact the appropriate CPCP server, perhaps a sip uri
>>>>could serve to
>>>>identify the policy. But that would require me to know the
>>>
>>>address of
>>>
>>>>the server a-priori.
>>>>
>>>>If all I have is the sip conference id, then to derive the
>>>>URI for the
>>>>policy from it I must invoke sip operations on it.
>>>>
>>>>                 Paul
>>>>
>>>>
>>>>_______________________________________________
>>>>XCON mailing list
>>>>XCON@ietf.org
>>>>https://www1.ietf.org/mailman/listinfo/xcon
>>>>
>>>
>>_______________________________________________
>>XCON mailing list
>>XCON@ietf.org
>>https://www1.ietf.org/mailman/listinfo/xcon
>>
>
>


_______________________________________________
XCON mailing list
XCON@ietf.org
https://www1.ietf.org/mailman/listinfo/xcon
--=_alternative 0041E7A4C2256DF2_=-- _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Thu Dec 4 09:29:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26803 for ; Thu, 4 Dec 2003 09:29:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARuTa-0001yZ-3Z for xcon-archive@odin.ietf.org; Thu, 04 Dec 2003 09:29:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB4ET6jc007594 for xcon-archive@odin.ietf.org; Thu, 4 Dec 2003 09:29:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARuTZ-0001yP-Uu for xcon-web-archive@optimus.ietf.org; Thu, 04 Dec 2003 09:29:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26795 for ; Thu, 4 Dec 2003 09:28:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARuTY-00027i-00 for xcon-web-archive@ietf.org; Thu, 04 Dec 2003 09:29:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARuTX-00027f-00 for xcon-web-archive@ietf.org; Thu, 04 Dec 2003 09:29:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARuTV-0001xr-Bk; Thu, 04 Dec 2003 09:29:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARuT6-0001xS-Ps for xcon@optimus.ietf.org; Thu, 04 Dec 2003 09:28:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26784 for ; Thu, 4 Dec 2003 09:28:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARuT5-00027R-00 for xcon@ietf.org; Thu, 04 Dec 2003 09:28:35 -0500 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 1ARuT4-00027M-00 for xcon@ietf.org; Thu, 04 Dec 2003 09:28:34 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA15212; Thu, 4 Dec 2003 09:26:49 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA16587; Thu, 4 Dec 2003 09:26:45 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Thu, 4 Dec 2003 09:26:45 -0500 Message-ID: <313680C9A886D511A06000204840E1CF070B6177@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'hisham.khartabil@nokia.com'" , nismail@cisco.com Cc: xcon@ietf.org Subject: RE: [XCON] Chicken and Egg - Can CPCP create a conference Date: Thu, 4 Dec 2003 09:26:42 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , Hurray, someone else on the hot seat. I agree with Hisham, and others, that schedule in advance is a clear requirement we must support (existing systems do it), it's not hard, and the resource allocation is local policy at the conference service. The simplest way to get around time zone issues is to simply have the schedule always be in GMT, and leave it to the clients to deal with local conversion for display purposes. Conference system vendors have coped with the scheduling problem for years, and have sensible, albeit not foolproof heuristics to make scheduled conferences work pretty well. The reality these days is that calculating conference resources is already an inexact science, and you don't really know if your DSP will run out of horsepower until it does. Again, vendors often use heuristics and approximations to give you a "port count". Brian > -----Original Message----- > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > Sent: Thursday, December 04, 2003 4:54 AM > To: nismail@cisco.com; Brian.Rosen@marconi.com > Cc: xcon@ietf.org > Subject: RE: [XCON] Chicken and Egg - Can CPCP create a conference > > > I can't believe people still think time zones are a problem. > There are many time zone standards that can be used. The only > requirement is that the client and the server need to > implement the same one. That is hardly a show stopper. > > /Hisham > > > -----Original Message----- > > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On > Behalf Of ext > > Nermeen Ismail > > Sent: 04.December.2003 05:56 > > To: Rosen, Brian > > Cc: xcon@ietf.org > > Subject: RE: [XCON] Chicken and Egg - Can CPCP create a conference > > > > > > I have just seen this thread so I might be repeating what is > > laredy been said. > > > > I agree that from the protocols point of view a conference is > > a conference. > > It does not matter if it is ad hoc or scheduled. It has a > > unique URI, its > > policy can be manipulated and authorized users can join/leave > > them either > > by dial-in or dial-out. > > > > My understanding for why there are two ways to create a > > conference is to > > support : > > 1- Creating a conference and joining it without having to implement > > anything other than SIP (cc-conferencing). In this case sending an > > INVITE to the URI factory is sufficient. Off course if the > > endpoint needs > > to do something more like modifying the conference policy then > > it needs to also implement CPCP/MPCP in which case it might > > have just used > > that to create the conference. However the point is still that an > > application can create, join a conference and get the > roster without > > needing anything other than a SIP stack. > > > > 2- Creating a conference and never joining it. This is like > > the case of a > > scheduling automata that at the time of conference scheduling > > it creates a > > conference and a focus. In this case and as the application > > will never send > > or receive media to the conference it was deemed > > inappropriate to demand > > the application to have a SIP stack and send a no-media > > INVITE to create > > the conference. Hence some non-SIP method will be used to > create the > > conference. A non-sip method will be used to create the > > conference (enters > > CPCP) and this create-conference will be sent to the > top-level policy > > server URI which in return will send the conference URI and > > the policy > > server URI for that conference. The only benefot that this > method has > > over number 1 is that the application does not have to support SIP. > > > > So a conference server needs to have a SIP stack, CPCP/MPCP and the > > conference package but a client might only have a SIP stack, > > a CPCP/MPCP > > implementation or both. > > > > On a separate topic, it was mentioned before that when a > > conference is > > created a future start time can be specified. I see lots of > > complications > > with that to do with time zones etc. Already the client that > > created the > > conference has to deal with that and I do not see any benefit > > in extending > > that to the conference server as well. So I see benefits in > > specifying a > > conference duration but no benefit in specifying conference > > start time. > > If the client creating the conference wishes the conference > to start > > accepting users in 5 minutes time then it needs to delay > > sending the create > > conference 5 minutes. > > > > > > nermeen > > > > > > > > > > > > > > >We must stop talking about "ad-hoc conferences" and "scheduled > > > > conferences" > > > > >- there is no such thing. There are only ad-hoc mechanisms and > > > > scheduled > > > > >mechanisms to create/join a conference. > > >Which, I think, is completely useless. > > >And, to be specific: > > > There is no difference in how you join a conference > > > You always send an INVITE, or get a REFER, > > > or receive an INVITE. You can't join with > > > CPCP. > > > There is no reason to have a difference to create one > > > > > > > > > > > [Chris Boulton] I totally agree. Whether 'ad-hoc' or > > > > 'scheduled' means > > > > are used to create a conference should have no effect - a > > conference > > > > should be created and a default policy applied. Then, > if it is an > > > > 'ad-hoc' conference, a participant is free to join and > if it is a > > > > scheduled, the creator may manipulate the conference policy. > > >Why is it different with ad-hoc that a participant is free to join? > > >Why is it different with scheduled that the creator may manipulate > > >the conference policy? > > > > > >I think there is no difference at all. No matter how you > create it, > > >participants are free to join any time the policy says they pay. > > >No matter how you create it, the creator may manipulate the > > conference > > >policy (and participants may manipulate it also, subject to > > permissions). > > > > > > > > > > >So, if The Example Company already has their public web > > server home > > > > page at > > > > >example.com where everyone goes to download the latest > > examples, this > > > > web > > > > >server now needs to become the conference policy server? > > >No, unless the example.com is also the focus host. If it > > is, then the > > >web server is there too. That is just not a limitation > worth worrying > > >about. > > > > > > > > > > > > > > > >There are significant disadvantages in limiting > ourselves to such > > > > >conventions - especially when there are other ways of > > discovering the > > > > >policy URI. One way that has been discussed is advertising > > > > the policy > > > > URI > > > > >in conference package notifications. Is this not > > sufficient? This > > > > >approach is flexible and extensible (different protocols > > for policy > > > > >manipulation can be defined with a new URI scheme) and has > > > > none of the > > > > name > > > > >space limitations of this proposal. > > > > > > > > [Chris Boulton] This approach does seem to 'shoe-horn' > > the HTTP usage > > > > and IMHO is quite an ugly solution. As Alan points out, > > policy URI > > > > contained in conference packages is a far more elegant solution. > > > > > > >My problem is that we seem to be heading to a solution where there > > >is no subset of capabilities. To do anything, you need to > implement: > > > cc conference > > >AND > > > cpcp > > >AND > > > mpcp > > >AND > > > the conference package > > > > > >There are no simple implementations other than conference unaware. > > >Is that really what we want to do? Intertwine all the > pieces so that > > >there is no clean functional separation that allows implementation > > >flexibility without creating incompatibility? In this specific > > >case, why do you have to implement the conference package in order > > >to discover the conference policy uri? > > > > > >A message or two ago, Alan talked about automata > > manipulating conference > > >policy, and you were aghast that I proposed using SIP means to > > >create a conference ID. You now want the automata to use SIP means > > >to find a conference policy URI given a conference URI; they > > even have > > >to join the conference to do so, unless the automata created the > > >conference in the first place, where it may get the > conference policy > > >uri returned to it). > > > > > >Can't we give up a slight amount of flexibility to get the > > possibility > > >of more widespread use of this facility by limiting implementation > > >complexity? Maybe we need some use case stuff to see how > > subsets might > > >be useful. > > > > > > > > >_______________________________________________ > > >XCON mailing list > > >XCON@ietf.org > > >https://www1.ietf.org/mailman/listinfo/xcon > > > > > > _______________________________________________ > > XCON mailing list > > XCON@ietf.org > > https://www1.ietf.org/mailman/listinfo/xcon > > > _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Thu Dec 4 09:58:17 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28193 for ; Thu, 4 Dec 2003 09:58:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARuvb-0003dT-1u for xcon-archive@odin.ietf.org; Thu, 04 Dec 2003 09:58:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB4Ew3Nw013971 for xcon-archive@odin.ietf.org; Thu, 4 Dec 2003 09:58:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARuva-0003dG-SJ for xcon-web-archive@optimus.ietf.org; Thu, 04 Dec 2003 09:58:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28170 for ; Thu, 4 Dec 2003 09:57:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARuvY-0002ZN-00 for xcon-web-archive@ietf.org; Thu, 04 Dec 2003 09:58:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARuvY-0002ZK-00 for xcon-web-archive@ietf.org; Thu, 04 Dec 2003 09:58:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARuvZ-0003ch-GQ; Thu, 04 Dec 2003 09:58:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARuv8-0003ag-SL for xcon@optimus.ietf.org; Thu, 04 Dec 2003 09:57:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28161 for ; Thu, 4 Dec 2003 09:57:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARuv6-0002ZA-00 for xcon@ietf.org; Thu, 04 Dec 2003 09:57:32 -0500 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 1ARuv5-0002Yw-00 for xcon@ietf.org; Thu, 04 Dec 2003 09:57:32 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA16311; Thu, 4 Dec 2003 09:44:54 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA19992; Thu, 4 Dec 2003 09:41:39 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Thu, 4 Dec 2003 09:41:39 -0500 Message-ID: <313680C9A886D511A06000204840E1CF070B6179@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Avshalom Houri'" , xcon@ietf.org Subject: RE: [XCON] Chicken and Egg - Can CPCP create a conference Date: Thu, 4 Dec 2003 09:41:36 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , Although I've caved on the issue of using conference uri to generate conference policy uri, this message seems to address the issue of one or two mechanisms to create conferences. I think that just because we create SIP mechanisms to create conferences does not prohibit any other signaling protocol (H.323 for example) from creating conferences, which could then use CPCP for conference policy control. They might already have mechanisms to create conferences. Looking at it another way, why should CPCP create SIP (emphasis added) uris? Clearly, it should be independent of the signalling protocol. To make this work, we would have to have a way to specify what kind of uri we wanted to create if CPCP can create conferences. And of course you are entangling the protocols. If CPCP can't create conferences, it can treat the conference ID as opaque, which is what separate protocols should do to elements from the "other" side. Oooh, ooh, another problem occurs to me. I'll start another thread. Brian -----Original Message----- From: Avshalom Houri [mailto:AVSHALOM@il.ibm.com] Sent: Thursday, December 04, 2003 7:00 AM To: xcon@ietf.org Subject: Re: [XCON] Chicken and Egg - Can CPCP create a conference I agree with Paul, Alan and I think that also Orit. The XCON protocol should be a different protocol from SIP. Other protocols that will want to create conferences should be able to use ti. Reading again the XCON charter it explicitly says that the XCON protocol can be used by other protocols. I think that coupling INVITE with the conference creation does not agree with the charter. <<< Due to the centralized architecture of the WG, XCON's mechanisms will place requirements on the signaling protocol used between the focus and the participants. At a high level, the signaling protocol must be able to establish, tear down, modify, and perform call control operations on multimedia streams, including voice, video, and instant messaging, in both a centralized and distributed mixing architecture. SIP will be the reference session signaling protocol used for examples; however, none of the XCON solutions themselves will be signaling protocols, nor will XCON extend existing signaling protocols. Other signaling protocols than SIP may be used between the focus and participants, including non-IETF protocols, but the requirements and possible extensions needed for other signaling protocols to utilize the full functionality of the XCON architecture is outside the scope of XCON. >>> Avshalom _______________________ Avshalom Houri Architect - Lotus Software, IBM SWG Science Park, Building 18 floor D Rehovot, Israel 76470 Email: avshalom@il.ibm.com Office: +972-8-9409761 Ext. 123 Fax: +972-8-9944697 Cell: +972-54-686021 Paul Kyzivat Sent by: xcon-admin@ietf.org 04/12/2003 01:41 AM To xcon@ietf.org cc SubjectRe: [XCON] Chicken and Egg - Can CPCP create a conference I am in agreement with Alan and others that binding the names of the two uris together algorithmically is a terrible idea, at least as part of a standard. (There is nothing to stop a particular implementation from doing this. It just won't be interoperable, and needn't be.) What we have here are not two names for the same thing, but rather two names for different things that happen to be in 1:1 correspondence with one another. We have - a sip uri identifying the focus of a conference - an http uri identifying the policy for a conference If all an application cares about is call control, then all it needs to implement is sip, and the only identifier it needs is the sip uri. If all an application cares about is policy managment, then all it needs to implement is http and xcap, and the only identifier it needs is the http uri. If an application cares about both of these, then it must implement both sets of protocols, and it needs both uris. Each protocol should provide a protocol to obtain the uri for the other object/protocol. Paul Rosen, Brian wrote: > I don't understand this. I'm not changing the definition of a focus. > I'm observing that the host of the focus is the host of the policy > server, at least for now. At some point in the future, we could > change this, but now, we can easily make them the same. > > If we use XCAP for CPCP, this seems very straightforward, > and it's even a uri! > > suppose the conferenceID is: > sip:hishams-weekly-status-meeting@confa.example.com > > Then the XCAP URI for this conference is > http:confa.example.com/cpcp/hishams-weekly-status-meeting... > > at least for now. All I propose is that the root service uri for > CPCP be slightly more structured for CPCP than XCAP, which proposes > that the root service uri be provisioned. If this offends you > that much, you could always say that if you have an XCAP service > root, use it, adding cpcp/hishams-weekly-status-meeting to it > to access the policy for this conference. > > If it's not XCAP, we still use the focus host as the CPCP host, > and the conference uri userpart as the id, with whatever convention > the chosen protocol uses to encode it. > > >>-----Original Message----- >>From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] >>Sent: Wednesday, December 03, 2003 9:44 AM >>To: Brian.Rosen@marconi.com; pkyzivat@cisco.com >>Cc: rohan@cisco.com; alan.johnston@mci.com; georg.mayer@nokia.com; >>oritl@microsoft.com; xcon@ietf.org >>Subject: RE: [XCON] Chicken and Egg - Can CPCP create a conference >> >> >>You are asking to change the definition of a focus. It is >>created when the conference is instantiated (using your >>definition of instantiation) and destroyed when the >>conference instance is destroyed. Therefore, pre-establishing >>a conference is not possible using CPCP unless a conference >>is instantiated. That is not desirable. >> >>We have a conference framework in place, lets use it. >> >>/Hisham >> >> >>>-----Original Message----- >>>From: ext Rosen, Brian [mailto:Brian.Rosen@marconi.com] >>>Sent: 03.December.2003 14:58 >>>To: 'Paul Kyzivat' >>>Cc: Khartabil Hisham (NMP-MSW/Helsinki); rohan@cisco.com; >>>alan.johnston@mci.com; Mayer Georg (NMP-MSW/Helsinki); >>>oritl@microsoft.com; xcon@ietf.org >>>Subject: RE: [XCON] Chicken and Egg - Can CPCP create a conference >>> >>> >>>Ah, I wondered when we would get to this. >>> >>>This is one of the bigger problems in separating conference policy >>>from sip signalling. Everything would be simpler if the conference >>>policy server was always the focus. >>> >>>So, I want to ask, can we make it be so? >>> >>>What are the advantages of making the conference policy server >>>separate from the focus? Two ideas occur to me: >>> 1. Separation of implementation >>> But this is not possible with the current framework >>> because we don't specify the interface between >>> CPCP and SIP; we assume that it is proprietary >>> 2. Load Balancing >>> But I really, really doubt that works. It >>>would be easier >>> to have a separate CPS with every focus, and replicate >>> the combination >>> >>>So, what if we assume they are the same entity, and use the same ID? >>>We don't need to have the conference policy be a URI, we merely have >>>to locate the address of the server. So, it's the hostname of the >>>conference URI. And a sip uri is a fine conference ID for the >>>purpose of specifying which policy once we know where the server is. >>> >>>Is there some advantage of having the conference policy explicitly >>>be a URI that I'm missing? >>> >>>Brian >>> >>> >>>>-----Original Message----- >>>>From: Paul Kiribati [mailto:pkyzivat@cisco.com] >>>>Sent: Tuesday, December 02, 2003 2:44 PM >>>>To: Rosen, Brian >>>>Cc: 'hisham.khartabil@nokia.com'; rohan@cisco.com; >>>>alan.johnston@mci.com; georg.mayer@nokia.com; oritl@microsoft.com; >>>>xcon@ietf.org >>>>Subject: Re: [XCON] Chicken and Egg - Can CPCP create a conference >>>> >>>> >>>> >>>> >>>>Rosen, Brian wrote: >>>> >>>>>>If you look at XCAP list usage for example, you will see that >>>>>>the list-URI used when sending SIP SUBSCRIBE requests to the >>>>>>list is not the same as the URI used to manipulate the list >>>>>>using XCAP. They certainly need to be linked, but not >>>>>>necessarily the same. >>>>>> >>>>>>Depending on the protocol we chose, a SIP URI can or cannot >>>>>>be used to identify a conference policy. >>>>> >>>>>I think we CAN always have the same ID. >>>>>I think there is a lot of value in one ID >>>>>I don't think there is any problem in having one ID >>>>> >>>>>So, I think there should be one. >>>>> >>>>>If there is a good reason, we can burden the conference >>>> >>>>policy server >>>> >>>>>with keeping the relationship, but unless there is a good >>>> >>>>reason, history >>>> >>>>>suggests that one namespace is better than two with linkage. >>>> >>>>[The chicken and the egg are different things. If I want to >>>>talk to the >>>>egg I need the address of the egg - having the address of >>> >>>the chicken >>> >>>>isn't sufficient. Its probably a bad idea to crack the egg in >>>>order to >>>>ask the chicken for the address of the egg.] >>>> >>>>Getting away from metaphors, this seems to be coming down to the >>>>distinction between URIs and URLs. >>>> >>>>A sip address is a URL in that it is sufficient for me to >>> >>locate a >> >>>>corresponding (sip) resource. >>>> >>>>But it isn't sufficient for me to locate a CPCP resource. If >>>>I knew how >>>>to contact the appropriate CPCP server, perhaps a sip uri >>>>could serve to >>>>identify the policy. But that would require me to know the >>> >>>address of >>> >>>>the server a-priori. >>>> >>>>If all I have is the sip conference id, then to derive the >>>>URI for the >>>>policy from it I must invoke sip operations on it. >>>> >>>> Paul >>>> >>>> >>>>_______________________________________________ >>>>XCON mailing list >>>>XCON@ietf.org >>>>https://www1.ietf.org/mailman/listinfo/xcon >>>> >>> >>_______________________________________________ >>XCON mailing list >>XCON@ietf.org >>https://www1.ietf.org/mailman/listinfo/xcon >> > > _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Thu Dec 4 09:59:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28230 for ; Thu, 4 Dec 2003 09:59:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARuwZ-0003gf-Dx for xcon-archive@odin.ietf.org; Thu, 04 Dec 2003 09:59:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB4Ex35B014167 for xcon-archive@odin.ietf.org; Thu, 4 Dec 2003 09:59:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARuwX-0003gQ-RS for xcon-web-archive@optimus.ietf.org; Thu, 04 Dec 2003 09:59:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28220 for ; Thu, 4 Dec 2003 09:58:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARuwV-0002a5-00 for xcon-web-archive@ietf.org; Thu, 04 Dec 2003 09:58:59 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARuwV-0002a2-00 for xcon-web-archive@ietf.org; Thu, 04 Dec 2003 09:58:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARuwW-0003ev-Sf; Thu, 04 Dec 2003 09:59:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARuvv-0003ed-7J for xcon@optimus.ietf.org; Thu, 04 Dec 2003 09:58:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28191 for ; Thu, 4 Dec 2003 09:58:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARuvt-0002Zj-00 for xcon@ietf.org; Thu, 04 Dec 2003 09:58:21 -0500 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 1ARuvs-0002ZJ-00 for xcon@ietf.org; Thu, 04 Dec 2003 09:58:20 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA15652; Thu, 4 Dec 2003 09:36:02 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA17927; Thu, 4 Dec 2003 09:31:08 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Thu, 4 Dec 2003 09:31:07 -0500 Message-ID: <313680C9A886D511A06000204840E1CF070B6178@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Paul Kyzivat'" Cc: "'hisham.khartabil@nokia.com'" , rohan@cisco.com, alan.johnston@mci.com, georg.mayer@nokia.com, oritl@microsoft.com, xcon@ietf.org Subject: RE: [XCON] Chicken and Egg - Can CPCP create a conference Date: Thu, 4 Dec 2003 09:31:03 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , I'm going to cave on this one. I think it will cause problems, as it always does when you have two identifiers in different name spaces that have to be kept in sync, but I can see that there is little, if any support for this one. Brian > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Wednesday, December 03, 2003 6:41 PM > To: Rosen, Brian > Cc: 'hisham.khartabil@nokia.com'; rohan@cisco.com; > alan.johnston@mci.com; georg.mayer@nokia.com; oritl@microsoft.com; > xcon@ietf.org > Subject: Re: [XCON] Chicken and Egg - Can CPCP create a conference > > > I am in agreement with Alan and others that binding the names > of the two > uris together algorithmically is a terrible idea, at least > as part of > a standard. (There is nothing to stop a particular > implementation from > doing this. It just won't be interoperable, and needn't be.) > > What we have here are not two names for the same thing, but > rather two > names for different things that happen to be in 1:1 > correspondence with > one another. We have > - a sip uri identifying the focus of a conference > - an http uri identifying the policy for a conference > > If all an application cares about is call control, then all > it needs to > implement is sip, and the only identifier it needs is the sip uri. > > If all an application cares about is policy managment, then > all it needs > to implement is http and xcap, and the only identifier it > needs is the > http uri. > > If an application cares about both of these, then it must > implement both > sets of protocols, and it needs both uris. Each protocol > should provide > a protocol to obtain the uri for the other object/protocol. > > Paul > > Rosen, Brian wrote: > > I don't understand this. I'm not changing the definition > of a focus. > > I'm observing that the host of the focus is the host of the policy > > server, at least for now. At some point in the future, we could > > change this, but now, we can easily make them the same. > > > > If we use XCAP for CPCP, this seems very straightforward, > > and it's even a uri! > > > > suppose the conferenceID is: > > sip:hishams-weekly-status-meeting@confa.example.com > > > > Then the XCAP URI for this conference is > > http:confa.example.com/cpcp/hishams-weekly-status-meeting... > > > > at least for now. All I propose is that the root service uri for > > CPCP be slightly more structured for CPCP than XCAP, which proposes > > that the root service uri be provisioned. If this offends you > > that much, you could always say that if you have an XCAP service > > root, use it, adding cpcp/hishams-weekly-status-meeting to it > > to access the policy for this conference. > > > > If it's not XCAP, we still use the focus host as the CPCP host, > > and the conference uri userpart as the id, with whatever convention > > the chosen protocol uses to encode it. > > > > > >>-----Original Message----- > >>From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > >>Sent: Wednesday, December 03, 2003 9:44 AM > >>To: Brian.Rosen@marconi.com; pkyzivat@cisco.com > >>Cc: rohan@cisco.com; alan.johnston@mci.com; georg.mayer@nokia.com; > >>oritl@microsoft.com; xcon@ietf.org > >>Subject: RE: [XCON] Chicken and Egg - Can CPCP create a conference > >> > >> > >>You are asking to change the definition of a focus. It is > >>created when the conference is instantiated (using your > >>definition of instantiation) and destroyed when the > >>conference instance is destroyed. Therefore, pre-establishing > >>a conference is not possible using CPCP unless a conference > >>is instantiated. That is not desirable. > >> > >>We have a conference framework in place, lets use it. > >> > >>/Hisham > >> > >> > >>>-----Original Message----- > >>>From: ext Rosen, Brian [mailto:Brian.Rosen@marconi.com] > >>>Sent: 03.December.2003 14:58 > >>>To: 'Paul Kyzivat' > >>>Cc: Khartabil Hisham (NMP-MSW/Helsinki); rohan@cisco.com; > >>>alan.johnston@mci.com; Mayer Georg (NMP-MSW/Helsinki); > >>>oritl@microsoft.com; xcon@ietf.org > >>>Subject: RE: [XCON] Chicken and Egg - Can CPCP create a conference > >>> > >>> > >>>Ah, I wondered when we would get to this. > >>> > >>>This is one of the bigger problems in separating conference policy > >>>from sip signalling. Everything would be simpler if the > conference > >>>policy server was always the focus. > >>> > >>>So, I want to ask, can we make it be so? > >>> > >>>What are the advantages of making the conference policy server > >>>separate from the focus? Two ideas occur to me: > >>> 1. Separation of implementation > >>> But this is not possible with the current framework > >>> because we don't specify the interface between > >>> CPCP and SIP; we assume that it is proprietary > >>> 2. Load Balancing > >>> But I really, really doubt that works. It > >>>would be easier > >>> to have a separate CPS with every focus, and replicate > >>> the combination > >>> > >>>So, what if we assume they are the same entity, and use > the same ID? > >>>We don't need to have the conference policy be a URI, we > merely have > >>>to locate the address of the server. So, it's the hostname of the > >>>conference URI. And a sip uri is a fine conference ID for the > >>>purpose of specifying which policy once we know where the > server is. > >>> > >>>Is there some advantage of having the conference policy explicitly > >>>be a URI that I'm missing? > >>> > >>>Brian > >>> > >>> > >>>>-----Original Message----- > >>>>From: Paul Kiribati [mailto:pkyzivat@cisco.com] > >>>>Sent: Tuesday, December 02, 2003 2:44 PM > >>>>To: Rosen, Brian > >>>>Cc: 'hisham.khartabil@nokia.com'; rohan@cisco.com; > >>>>alan.johnston@mci.com; georg.mayer@nokia.com; oritl@microsoft.com; > >>>>xcon@ietf.org > >>>>Subject: Re: [XCON] Chicken and Egg - Can CPCP create a conference > >>>> > >>>> > >>>> > >>>> > >>>>Rosen, Brian wrote: > >>>> > >>>>>>If you look at XCAP list usage for example, you will see that > >>>>>>the list-URI used when sending SIP SUBSCRIBE requests to the > >>>>>>list is not the same as the URI used to manipulate the list > >>>>>>using XCAP. They certainly need to be linked, but not > >>>>>>necessarily the same. > >>>>>> > >>>>>>Depending on the protocol we chose, a SIP URI can or cannot > >>>>>>be used to identify a conference policy. > >>>>> > >>>>>I think we CAN always have the same ID. > >>>>>I think there is a lot of value in one ID > >>>>>I don't think there is any problem in having one ID > >>>>> > >>>>>So, I think there should be one. > >>>>> > >>>>>If there is a good reason, we can burden the conference > >>>> > >>>>policy server > >>>> > >>>>>with keeping the relationship, but unless there is a good > >>>> > >>>>reason, history > >>>> > >>>>>suggests that one namespace is better than two with linkage. > >>>> > >>>>[The chicken and the egg are different things. If I want to > >>>>talk to the > >>>>egg I need the address of the egg - having the address of > >>> > >>>the chicken > >>> > >>>>isn't sufficient. Its probably a bad idea to crack the egg in > >>>>order to > >>>>ask the chicken for the address of the egg.] > >>>> > >>>>Getting away from metaphors, this seems to be coming down to the > >>>>distinction between URIs and URLs. > >>>> > >>>>A sip address is a URL in that it is sufficient for me to > >>> > >>locate a > >> > >>>>corresponding (sip) resource. > >>>> > >>>>But it isn't sufficient for me to locate a CPCP resource. If > >>>>I knew how > >>>>to contact the appropriate CPCP server, perhaps a sip uri > >>>>could serve to > >>>>identify the policy. But that would require me to know the > >>> > >>>address of > >>> > >>>>the server a-priori. > >>>> > >>>>If all I have is the sip conference id, then to derive the > >>>>URI for the > >>>>policy from it I must invoke sip operations on it. > >>>> > >>>> Paul > >>>> > >>>> > >>>>_______________________________________________ > >>>>XCON mailing list > >>>>XCON@ietf.org > >>>>https://www1.ietf.org/mailman/listinfo/xcon > >>>> > >>> > >>_______________________________________________ > >>XCON mailing list > >>XCON@ietf.org > >>https://www1.ietf.org/mailman/listinfo/xcon > >> > > > > > _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Thu Dec 4 10:17:17 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29992 for ; Thu, 4 Dec 2003 10:17:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARvDy-0005GV-Vr for xcon-archive@odin.ietf.org; Thu, 04 Dec 2003 10:17:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB4FH2I6020233 for xcon-archive@odin.ietf.org; Thu, 4 Dec 2003 10:17:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARvDy-0005GG-Pa for xcon-web-archive@optimus.ietf.org; Thu, 04 Dec 2003 10:17:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29947 for ; Thu, 4 Dec 2003 10:16:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARvDw-0002rY-00 for xcon-web-archive@ietf.org; Thu, 04 Dec 2003 10:17:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARvDw-0002rV-00 for xcon-web-archive@ietf.org; Thu, 04 Dec 2003 10:17:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARvDx-0005FJ-Aj; Thu, 04 Dec 2003 10:17:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARvDu-0005F2-7I for xcon@optimus.ietf.org; Thu, 04 Dec 2003 10:16:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29932 for ; Thu, 4 Dec 2003 10:16:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARvDq-0002r8-00 for xcon@ietf.org; Thu, 04 Dec 2003 10:16:54 -0500 Received: from pmesmtp02.wcom.com ([199.249.20.2]) by ietf-mx with esmtp (Exim 4.12) id 1ARvDp-0002pZ-00 for xcon@ietf.org; Thu, 04 Dec 2003 10:16:53 -0500 Received: from pmismtp02.wcomnet.com ([166.38.62.37]) by firewall.wcom.com (Iplanet MTA 5.2) with ESMTP id <0HPD00A2LM2XNZ@firewall.wcom.com> for xcon@ietf.org; Thu, 04 Dec 2003 15:08:57 +0000 (GMT) Received: from pmismtp02.wcomnet.com by pmismtp02.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0HPD00801M0VFA@pmismtp02.wcomnet.com>; Thu, 04 Dec 2003 15:08:57 +0000 (GMT) Received: from xs578v3521.mci.com ([166.50.105.193]) by pmismtp02.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0HPD00775M2O9B@pmismtp02.wcomnet.com>; Thu, 04 Dec 2003 15:08:50 +0000 (GMT) Date: Thu, 04 Dec 2003 09:08:47 -0600 From: Alan Johnston Subject: RE: [XCON] Chicken and Egg - Can CPCP create a conference X-Sender: Alan.Johnston@pop.mcit.com To: "Rosen, Brian" , "'Avshalom Houri'" , xcon@ietf.org Message-id: <5.2.1.1.0.20031204090448.02bd2608@pop.mcit.com> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Content-type: text/plain; charset=us-ascii; format=flowed Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , At 09:41 AM 12/4/2003 -0500, Rosen, Brian wrote: >Although I've caved on the issue of using conference uri to generate >conference policy uri, this message seems to address the issue of one >or two mechanisms to create conferences. I think that just because we >create SIP mechanisms to create conferences does not prohibit any other >signaling protocol (H.323 for example) from creating conferences, >which could then use CPCP for conference policy control. >They might already have mechanisms to create conferences. > >Looking at it another way, why should CPCP create SIP (emphasis added) >uris? Clearly, it should be independent of the signalling protocol. >To make this work, we would have to have a way to specify what kind >of uri we wanted to create if CPCP can create conferences. This is a very good point. It seems logical that sip, sips, tel, h323, and maybe even im URIs could be requested. We need to give this requirement some more thought. Thanks, Alan Johnston MCI sip:alan@sipstation.com > And of >course you are entangling the protocols. If CPCP can't create >conferences, it can treat the conference ID as opaque, which is what >separate protocols should do to elements from the "other" side. >Oooh, ooh, another problem occurs to me. I'll start another thread. > >Brian >-----Original Message----- >From: Avshalom Houri [mailto:AVSHALOM@il.ibm.com] >Sent: Thursday, December 04, 2003 7:00 AM >To: xcon@ietf.org >Subject: Re: [XCON] Chicken and Egg - Can CPCP create a conference > > > >I agree with Paul, Alan and I think that also Orit. The XCON protocol should >be a different protocol from SIP. >Other protocols that will want to create conferences should be able to use >ti. > >Reading again the XCON charter it explicitly says that the XCON protocol can >be used by other protocols. >I think that coupling INVITE with the conference creation does not agree >with the charter. > ><<< >Due to the centralized architecture of the WG, XCON's mechanisms will >place requirements on the signaling protocol used between the focus and >the participants. At a high level, the signaling protocol must be able >to establish, tear down, modify, and perform call control operations on >multimedia streams, including voice, video, and instant messaging, in >both a centralized and distributed mixing architecture. SIP will be the >reference session signaling protocol used for examples; however, none of >the XCON solutions themselves will be signaling protocols, nor will XCON >extend existing signaling protocols. Other signaling protocols than SIP >may be used between the focus and participants, including non-IETF >protocols, but the requirements and possible extensions needed for other >signaling protocols to utilize the full functionality of the XCON >architecture is outside the scope of XCON. > >>> > > >Avshalom >_______________________ >Avshalom Houri >Architect - Lotus Software, IBM SWG >Science Park, Building 18 floor D Rehovot, Israel 76470 >Email: avshalom@il.ibm.com >Office: +972-8-9409761 Ext. 123 Fax: +972-8-9944697 Cell: +972-54-686021 > > > >Paul Kyzivat >Sent by: xcon-admin@ietf.org >04/12/2003 01:41 AM To xcon@ietf.org >cc >SubjectRe: [XCON] Chicken and Egg - Can CPCP create a conference > > > > > > > >I am in agreement with Alan and others that binding the names of the two > uris together algorithmically is a terrible idea, at least as part of >a standard. (There is nothing to stop a particular implementation from >doing this. It just won't be interoperable, and needn't be.) > >What we have here are not two names for the same thing, but rather two >names for different things that happen to be in 1:1 correspondence with >one another. We have >- a sip uri identifying the focus of a conference >- an http uri identifying the policy for a conference > >If all an application cares about is call control, then all it needs to >implement is sip, and the only identifier it needs is the sip uri. > >If all an application cares about is policy managment, then all it needs >to implement is http and xcap, and the only identifier it needs is the >http uri. > >If an application cares about both of these, then it must implement both >sets of protocols, and it needs both uris. Each protocol should provide >a protocol to obtain the uri for the other object/protocol. > > Paul > >Rosen, Brian wrote: > > I don't understand this. I'm not changing the definition of a focus. > > I'm observing that the host of the focus is the host of the policy > > server, at least for now. At some point in the future, we could > > change this, but now, we can easily make them the same. > > > > If we use XCAP for CPCP, this seems very straightforward, > > and it's even a uri! > > > > suppose the conferenceID is: > > sip:hishams-weekly-status-meeting@confa.example.com > > > > Then the XCAP URI for this conference is > > http:confa.example.com/cpcp/hishams-weekly-status-meeting... > > > > at least for now. All I propose is that the root service uri for > > CPCP be slightly more structured for CPCP than XCAP, which proposes > > that the root service uri be provisioned. If this offends you > > that much, you could always say that if you have an XCAP service > > root, use it, adding cpcp/hishams-weekly-status-meeting to it > > to access the policy for this conference. > > > > If it's not XCAP, we still use the focus host as the CPCP host, > > and the conference uri userpart as the id, with whatever convention > > the chosen protocol uses to encode it. > > > > > >>-----Original Message----- > >>From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > >>Sent: Wednesday, December 03, 2003 9:44 AM > >>To: Brian.Rosen@marconi.com; pkyzivat@cisco.com > >>Cc: rohan@cisco.com; alan.johnston@mci.com; georg.mayer@nokia.com; > >>oritl@microsoft.com; xcon@ietf.org > >>Subject: RE: [XCON] Chicken and Egg - Can CPCP create a conference > >> > >> > >>You are asking to change the definition of a focus. It is > >>created when the conference is instantiated (using your > >>definition of instantiation) and destroyed when the > >>conference instance is destroyed. Therefore, pre-establishing > >>a conference is not possible using CPCP unless a conference > >>is instantiated. That is not desirable. > >> > >>We have a conference framework in place, lets use it. > >> > >>/Hisham > >> > >> > >>>-----Original Message----- > >>>From: ext Rosen, Brian [mailto:Brian.Rosen@marconi.com] > >>>Sent: 03.December.2003 14:58 > >>>To: 'Paul Kyzivat' > >>>Cc: Khartabil Hisham (NMP-MSW/Helsinki); rohan@cisco.com; > >>>alan.johnston@mci.com; Mayer Georg (NMP-MSW/Helsinki); > >>>oritl@microsoft.com; xcon@ietf.org > >>>Subject: RE: [XCON] Chicken and Egg - Can CPCP create a conference > >>> > >>> > >>>Ah, I wondered when we would get to this. > >>> > >>>This is one of the bigger problems in separating conference policy > >>>from sip signalling. Everything would be simpler if the conference > >>>policy server was always the focus. > >>> > >>>So, I want to ask, can we make it be so? > >>> > >>>What are the advantages of making the conference policy server > >>>separate from the focus? Two ideas occur to me: > >>> 1. Separation of implementation > >>> But this is not possible with the >current framework > >>> because we don't specify the interface >between > >>> CPCP and SIP; we assume that it is >proprietary > >>> 2. Load Balancing > >>> But I really, really doubt that works. >It > >>>would be easier > >>> to have a separate CPS with every >focus, and replicate > >>> the combination > >>> > >>>So, what if we assume they are the same entity, and use the same ID? > >>>We don't need to have the conference policy be a URI, we merely have > >>>to locate the address of the server. So, it's the hostname of the > >>>conference URI. And a sip uri is a fine conference ID for the > >>>purpose of specifying which policy once we know where the server is. > >>> > >>>Is there some advantage of having the conference policy explicitly > >>>be a URI that I'm missing? > >>> > >>>Brian > >>> > >>> > >>>>-----Original Message----- > >>>>From: Paul Kiribati [mailto:pkyzivat@cisco.com] > >>>>Sent: Tuesday, December 02, 2003 2:44 PM > >>>>To: Rosen, Brian > >>>>Cc: 'hisham.khartabil@nokia.com'; rohan@cisco.com; > >>>>alan.johnston@mci.com; georg.mayer@nokia.com; oritl@microsoft.com; > >>>>xcon@ietf.org > >>>>Subject: Re: [XCON] Chicken and Egg - Can CPCP create a conference > >>>> > >>>> > >>>> > >>>> > >>>>Rosen, Brian wrote: > >>>> > >>>>>>If you look at XCAP list usage for example, you will see that > >>>>>>the list-URI used when sending SIP SUBSCRIBE requests to the > >>>>>>list is not the same as the URI used to manipulate the list > >>>>>>using XCAP. They certainly need to be linked, but not > >>>>>>necessarily the same. > >>>>>> > >>>>>>Depending on the protocol we chose, a SIP URI can or cannot > >>>>>>be used to identify a conference policy. > >>>>> > >>>>>I think we CAN always have the same ID. > >>>>>I think there is a lot of value in one ID > >>>>>I don't think there is any problem in having one ID > >>>>> > >>>>>So, I think there should be one. > >>>>> > >>>>>If there is a good reason, we can burden the conference > >>>> > >>>>policy server > >>>> > >>>>>with keeping the relationship, but unless there is a good > >>>> > >>>>reason, history > >>>> > >>>>>suggests that one namespace is better than two with linkage. > >>>> > >>>>[The chicken and the egg are different things. If I want to > >>>>talk to the > >>>>egg I need the address of the egg - having the address of > >>> > >>>the chicken > >>> > >>>>isn't sufficient. Its probably a bad idea to crack the egg in > >>>>order to > >>>>ask the chicken for the address of the egg.] > >>>> > >>>>Getting away from metaphors, this seems to be coming down to the > >>>>distinction between URIs and URLs. > >>>> > >>>>A sip address is a URL in that it is sufficient for me to > >>> > >>locate a > >> > >>>>corresponding (sip) resource. > >>>> > >>>>But it isn't sufficient for me to locate a CPCP resource. If > >>>>I knew how > >>>>to contact the appropriate CPCP server, perhaps a sip uri > >>>>could serve to > >>>>identify the policy. But that would require me to know the > >>> > >>>address of > >>> > >>>>the server a-priori. > >>>> > >>>>If all I have is the sip conference id, then to derive the > >>>>URI for the > >>>>policy from it I must invoke sip operations on it. > >>>> > >>>> Paul > >>>> > >>>> > >>>>_______________________________________________ > >>>>XCON mailing list > >>>>XCON@ietf.org > >>>>https://www1.ietf.org/mailman/listinfo/xcon > >>>> > >>> > >>_______________________________________________ > >>XCON mailing list > >>XCON@ietf.org > >>https://www1.ietf.org/mailman/listinfo/xcon > >> > > > > > > >_______________________________________________ >XCON mailing list >XCON@ietf.org >https://www1.ietf.org/mailman/listinfo/xcon > >_______________________________________________ >XCON mailing list >XCON@ietf.org >https://www1.ietf.org/mailman/listinfo/xcon _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Thu Dec 4 10:28:16 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00625 for ; Thu, 4 Dec 2003 10:28:16 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARvOc-0005i8-3L for xcon-archive@odin.ietf.org; Thu, 04 Dec 2003 10:28:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB4FS2Nn021952 for xcon-archive@odin.ietf.org; Thu, 4 Dec 2003 10:28:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARvOb-0005hz-SK for xcon-web-archive@optimus.ietf.org; Thu, 04 Dec 2003 10:28:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00613 for ; Thu, 4 Dec 2003 10:27:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARvOZ-00030e-00 for xcon-web-archive@ietf.org; Thu, 04 Dec 2003 10:27:59 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARvOZ-00030b-00 for xcon-web-archive@ietf.org; Thu, 04 Dec 2003 10:27:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARvOa-0005hb-QC; Thu, 04 Dec 2003 10:28:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARvOR-0005hP-F1 for xcon@optimus.ietf.org; Thu, 04 Dec 2003 10:27:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00610 for ; Thu, 4 Dec 2003 10:27:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARvOM-00030P-00 for xcon@ietf.org; Thu, 04 Dec 2003 10:27:46 -0500 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 1ARvOL-0002zu-00 for xcon@ietf.org; Thu, 04 Dec 2003 10:27:45 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA19580 for ; Thu, 4 Dec 2003 10:27:12 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA21509 for ; Thu, 4 Dec 2003 09:48:23 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Thu, 4 Dec 2003 09:48:23 -0500 Message-ID: <313680C9A886D511A06000204840E1CF070B617A@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'xcon@ietf.org'" Date: Thu, 4 Dec 2003 09:48:17 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [XCON] CPCP and Conference URIs - there are more than one! Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , The discussion of multiple ways to create conferences triggered a discussion of XCON work being useable with multiple "using" (to borrow a phrase from geopriv) protocols. We have been assuming that CPCP will, at one time or another, accept or receive a conference uri, which has so far been thought of as a SIP uri. This will not do. There has to be a LIST of conference URIs, one for each using protocol the conference might support. There are already conference bridges that accept both SIP and H.323 endpoints intermixed. The conference uri for the H.323 endpoints does not start with "sip:" folks! There might even be a tel uri in there, right?!!! Ooh, Ooh, sure would be nice if that tel uri could have the PIN. Nah, over the top :) Brian _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Thu Dec 4 10:35:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00999 for ; Thu, 4 Dec 2003 10:35:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARvVQ-0005zc-LG for xcon-archive@odin.ietf.org; Thu, 04 Dec 2003 10:35:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB4FZ4aY023030 for xcon-archive@odin.ietf.org; Thu, 4 Dec 2003 10:35:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARvVQ-0005zN-Ej for xcon-web-archive@optimus.ietf.org; Thu, 04 Dec 2003 10:35:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00974 for ; Thu, 4 Dec 2003 10:34:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARvVO-0003AZ-00 for xcon-web-archive@ietf.org; Thu, 04 Dec 2003 10:35:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARvVN-0003AW-00 for xcon-web-archive@ietf.org; Thu, 04 Dec 2003 10:35:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARvVO-0005yt-NB; Thu, 04 Dec 2003 10:35:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARvVB-0005y2-MQ for xcon@optimus.ietf.org; Thu, 04 Dec 2003 10:34:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00960 for ; Thu, 4 Dec 2003 10:34:32 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARvV9-00039u-00 for xcon@ietf.org; Thu, 04 Dec 2003 10:34:47 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1ARvV8-00039o-00 for xcon@ietf.org; Thu, 04 Dec 2003 10:34:46 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hB4FYiw25769 for ; Thu, 4 Dec 2003 17:34:45 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 4 Dec 2003 17:34:44 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 4 Dec 2003 17:34:42 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 4 Dec 2003 17:34:42 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] CPCP and Conference URIs - there are more than one! Date: Thu, 4 Dec 2003 17:34:41 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB70179749F@esebe019.ntc.nokia.com> Thread-Topic: [XCON] CPCP and Conference URIs - there are more than one! Thread-Index: AcO6ezzx1k1NEO+CQzyak5g4rmGnqQAAFiuQ To: , X-OriginalArrivalTime: 04 Dec 2003 15:34:42.0423 (UTC) FILETIME=[231BA070:01C3BA7C] Content-Transfer-Encoding: quoted-printable Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Brian, No argument there. We thought of that when we where creating the xcap = based solution. The current solution can only hold a tel and a sip URI. = We plan on changing this. Looks like a requirement needs to be added to the requirements document. = Does the solution need to be future proof? or do we just allow listing = the currently known protocols? Regards, Hisham > -----Original Message----- > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On Behalf Of ext > Rosen, Brian > Sent: 04.December.2003 16:48 > To: 'xcon@ietf.org' > Subject: [XCON] CPCP and Conference URIs - there are more than one! >=20 >=20 > The discussion of multiple ways to create conferences triggered=20 > a discussion of XCON work being useable with multiple "using" (to > borrow a phrase from geopriv) protocols. >=20 > We have been assuming that CPCP will, at one time or another, accept > or receive a conference uri, which has so far been thought of as a > SIP uri. This will not do. There has to be a LIST of=20 > conference URIs, > one for each using protocol the conference might support. >=20 > There are already conference bridges that accept both SIP and H.323 > endpoints intermixed. The conference uri for the H.323 endpoints does > not start with "sip:" folks! >=20 > There might even be a tel uri in there, right?!!! > Ooh, Ooh, sure would be nice if that tel uri could have the PIN. > Nah, over the top :) >=20 > Brian >=20 > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon >=20 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Thu Dec 4 11:14:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02908 for ; Thu, 4 Dec 2003 11:14:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARw7A-00087U-J2 for xcon-archive@odin.ietf.org; Thu, 04 Dec 2003 11:14:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB4GE4I9031206 for xcon-archive@odin.ietf.org; Thu, 4 Dec 2003 11:14:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARw7A-00087F-Ck for xcon-web-archive@optimus.ietf.org; Thu, 04 Dec 2003 11:14:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02898 for ; Thu, 4 Dec 2003 11:13:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARw79-00043x-00 for xcon-web-archive@ietf.org; Thu, 04 Dec 2003 11:14:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARw79-00043u-00 for xcon-web-archive@ietf.org; Thu, 04 Dec 2003 11:14:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARw77-00086d-IQ; Thu, 04 Dec 2003 11:14:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARw6y-000869-0q for xcon@optimus.ietf.org; Thu, 04 Dec 2003 11:13:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02886 for ; Thu, 4 Dec 2003 11:13:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARw6x-00043Q-00 for xcon@ietf.org; Thu, 04 Dec 2003 11:13:51 -0500 Received: from thoth.sbs.de ([192.35.17.2]) by ietf-mx with esmtp (Exim 4.12) id 1ARw6w-00043N-00 for xcon@ietf.org; Thu, 04 Dec 2003 11:13:50 -0500 Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by thoth.sbs.de (8.11.7/8.11.7) with ESMTP id hB4GDn204835 for ; Thu, 4 Dec 2003 17:13:49 +0100 (MET) Received: from moody.mchh.siemens.de (moody.mchh.siemens.de [139.21.205.85]) by mail1.siemens.de (8.11.7/8.11.7) with ESMTP id hB4GDmL06473 for ; Thu, 4 Dec 2003 17:13:48 +0100 (MET) Received: from mchh275e.mchh.siemens.de (mchh275e.mchh.siemens.de [139.21.200.61]) by moody.mchh.siemens.de (8.9.3/8.9.1) with ESMTP id RAA23895 for ; Thu, 4 Dec 2003 17:13:48 +0100 (MET) Received: by mchh275e.mchh.siemens.de with Internet Mail Service (5.5.2653.19) id ; Thu, 4 Dec 2003 17:13:47 +0100 Message-ID: <5B788FC2CAFBD6118BAE0030848B025C7A21AB@LNN201E> From: Marjou Xavier To: xcon@ietf.org Subject: RE: [XCON] CPCP requirements to support IMS Date: Thu, 4 Dec 2003 17:13:23 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , > You send an INVITE to the conference factory uri, > and it returns a Contact which is a conference uri. Although I understand the need for this for an ad-hoc conference, is it really inline with SIP to return a specialized Contact header in a response to an INVITE message? In my opinion, returning a specialized Contact header is only possible during the REGISTER step. (However, I agree I did not find this explicitly written in 3261) Xavier _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Thu Dec 4 11:27:16 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03374 for ; Thu, 4 Dec 2003 11:27:16 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARwJh-0000G9-Hl for xcon-archive@odin.ietf.org; Thu, 04 Dec 2003 11:27:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB4GR1wq000991 for xcon-archive@odin.ietf.org; Thu, 4 Dec 2003 11:27:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARwJh-0000Fb-CR for xcon-web-archive@optimus.ietf.org; Thu, 04 Dec 2003 11:27:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03323 for ; Thu, 4 Dec 2003 11:26:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARwJg-0004GV-00 for xcon-web-archive@ietf.org; Thu, 04 Dec 2003 11:27:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARwJf-0004GS-00 for xcon-web-archive@ietf.org; Thu, 04 Dec 2003 11:26:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARwJg-0000CK-Ae; Thu, 04 Dec 2003 11:27:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARwJ2-0000A6-Ol for xcon@optimus.ietf.org; Thu, 04 Dec 2003 11:26:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03295 for ; Thu, 4 Dec 2003 11:26:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARwJ1-0004GD-00 for xcon@ietf.org; Thu, 04 Dec 2003 11:26:19 -0500 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 1ARwJ1-0004FP-00 for xcon@ietf.org; Thu, 04 Dec 2003 11:26:19 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA23405; Thu, 4 Dec 2003 11:24:01 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA11819; Thu, 4 Dec 2003 11:22:39 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Thu, 4 Dec 2003 11:22:39 -0500 Message-ID: <313680C9A886D511A06000204840E1CF070B6182@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Marjou Xavier'" , xcon@ietf.org Subject: RE: [XCON] CPCP requirements to support IMS Date: Thu, 4 Dec 2003 11:22:34 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , Look at how 3XX responses are handled in RFC3261 The Contact header has the URI for the client to use. Brian > -----Original Message----- > From: Marjou Xavier [mailto:xavier.marjou@siemens.com] > Sent: Thursday, December 04, 2003 11:13 AM > To: xcon@ietf.org > Subject: RE: [XCON] CPCP requirements to support IMS > > > > You send an INVITE to the conference factory uri, > > and it returns a Contact which is a conference uri. > > Although I understand the need for this for an ad-hoc > conference, is it really inline with SIP to return a > specialized Contact header in a response to an INVITE message? > > In my opinion, returning a specialized Contact header is only > possible during the REGISTER step. (However, I agree I did > not find this explicitly written in 3261) > > Xavier > > > > > > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon > _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Thu Dec 4 13:40:40 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07821 for ; Thu, 4 Dec 2003 13:40:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARyOn-0001jP-2N for xcon-archive@odin.ietf.org; Thu, 04 Dec 2003 13:40:25 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB4IePh4006651 for xcon-archive@odin.ietf.org; Thu, 4 Dec 2003 13:40:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARyOm-0001jC-U1 for xcon-web-archive@optimus.ietf.org; Thu, 04 Dec 2003 13:40:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07808 for ; Thu, 4 Dec 2003 13:39:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARyOY-00068p-00 for xcon-web-archive@ietf.org; Thu, 04 Dec 2003 13:40:10 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARyOY-00068m-00 for xcon-web-archive@ietf.org; Thu, 04 Dec 2003 13:40:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARyOU-0001e9-8E; Thu, 04 Dec 2003 13:40:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARyNn-0001Zn-9E for xcon@optimus.ietf.org; Thu, 04 Dec 2003 13:39:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07728 for ; Thu, 4 Dec 2003 13:39:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARyNk-00067w-00 for xcon@ietf.org; Thu, 04 Dec 2003 13:39:20 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1ARyNk-00066t-00 for xcon@ietf.org; Thu, 04 Dec 2003 13:39:20 -0500 Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hB4Icgxi006687; Thu, 4 Dec 2003 13:38:46 -0500 (EST) Received: from mhammer-w2k03.cisco.com (dhcp-hrn-64-100-229-166.cisco.com [64.100.229.166]) by fruitpie.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AVK42913; Thu, 4 Dec 2003 10:38:41 -0800 (PST) Message-Id: <4.3.2.7.2.20031204133143.00b6b048@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 04 Dec 2003 13:38:41 -0500 To: Avshalom Houri From: Michael Hammer Subject: Re: [XCON] Chicken and Egg - Can CPCP create a conference Cc: xcon@ietf.org In-Reply-To: References: <3FCE7495.2020402@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , From the peanut gallery, inline below. At 01:59 PM 12/4/2003 +0200, Avshalom Houri wrote: >I agree with Paul, Alan and I think that also Orit. The XCON protocol >should be a different protocol from SIP. >Other protocols that will want to create conferences should be able to use >ti. > >Reading again the XCON charter it explicitly says that the XCON protocol >can be used by other protocols. >I think that coupling INVITE with the conference creation does not agree >with the charter. Help me understand this. Not knowing the protocol syntax of XCON, is it not possible that CPCP could be orthogonal to SIP? Could for instance the CPCP be a body that is carried inside a SIP message so that both could be established coincidentally as well as in separate messages? ><<< >Due to the centralized architecture of the WG, XCON's mechanisms will >place requirements on the signaling protocol used between the focus and >the participants. At a high level, the signaling protocol must be able >to establish, tear down, modify, and perform call control operations on >multimedia streams, including voice, video, and instant messaging, in >both a centralized and distributed mixing architecture. >***SIP will be the >reference session signaling protocol used for examples; however, none of >the XCON solutions themselves will be signaling protocols, nor will XCON >extend existing signaling protocols.*** This seems to indicate that what I suggest above is not only possible, but desirable. But, I am still trying to align the picture in my head with what is in other's heads. Mike >Other signaling protocols than SIP >may be used between the focus and participants, including non-IETF >protocols, but the requirements and possible extensions needed for other >signaling protocols to utilize the full functionality of the XCON >architecture is outside the scope of XCON. > >>> > > >Avshalom >_______________________ >Avshalom Houri >Architect - Lotus Software, IBM SWG >Science Park, Building 18 floor D Rehovot, Israel 76470 >Email: avshalom@il.ibm.com >Office: +972-8-9409761 Ext. 123 Fax: +972-8-9944697 Cell: +972-54-686021 > > > >Paul Kyzivat >Sent by: xcon-admin@ietf.org > >04/12/2003 01:41 AM >To > xcon@ietf.org >cc >Subject >Re: [XCON] Chicken and Egg - Can CPCP create a conference > > > > >I am in agreement with Alan and others that binding the names of the two > uris together algorithmically is a terrible idea, at least as part of >a standard. (There is nothing to stop a particular implementation from >doing this. It just won't be interoperable, and needn't be.) > >What we have here are not two names for the same thing, but rather two >names for different things that happen to be in 1:1 correspondence with >one another. We have >- a sip uri identifying the focus of a conference >- an http uri identifying the policy for a conference > >If all an application cares about is call control, then all it needs to >implement is sip, and the only identifier it needs is the sip uri. > >If all an application cares about is policy managment, then all it needs >to implement is http and xcap, and the only identifier it needs is the >http uri. > >If an application cares about both of these, then it must implement both >sets of protocols, and it needs both uris. Each protocol should provide >a protocol to obtain the uri for the other object/protocol. > > Paul > >Rosen, Brian wrote: > > I don't understand this. I'm not changing the definition of a focus. > > I'm observing that the host of the focus is the host of the policy > > server, at least for now. At some point in the future, we could > > change this, but now, we can easily make them the same. > > > > If we use XCAP for CPCP, this seems very straightforward, > > and it's even a uri! > > > > suppose the conferenceID is: > > sip:hishams-weekly-status-meeting@confa.example.com > > > > Then the XCAP URI for this conference is > > http:confa.example.com/cpcp/hishams-weekly-status-meeting... > > > > at least for now. All I propose is that the root service uri for > > CPCP be slightly more structured for CPCP than XCAP, which proposes > > that the root service uri be provisioned. If this offends you > > that much, you could always say that if you have an XCAP service > > root, use it, adding cpcp/hishams-weekly-status-meeting to it > > to access the policy for this conference. > > > > If it's not XCAP, we still use the focus host as the CPCP host, > > and the conference uri userpart as the id, with whatever convention > > the chosen protocol uses to encode it. > > > > > >>-----Original Message----- > >>From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > >>Sent: Wednesday, December 03, 2003 9:44 AM > >>To: Brian.Rosen@marconi.com; pkyzivat@cisco.com > >>Cc: rohan@cisco.com; alan.johnston@mci.com; georg.mayer@nokia.com; > >>oritl@microsoft.com; xcon@ietf.org > >>Subject: RE: [XCON] Chicken and Egg - Can CPCP create a conference > >> > >> > >>You are asking to change the definition of a focus. It is > >>created when the conference is instantiated (using your > >>definition of instantiation) and destroyed when the > >>conference instance is destroyed. Therefore, pre-establishing > >>a conference is not possible using CPCP unless a conference > >>is instantiated. That is not desirable. > >> > >>We have a conference framework in place, lets use it. > >> > >>/Hisham > >> > >> > >>>-----Original Message----- > >>>From: ext Rosen, Brian [mailto:Brian.Rosen@marconi.com] > >>>Sent: 03.December.2003 14:58 > >>>To: 'Paul Kyzivat' > >>>Cc: Khartabil Hisham (NMP-MSW/Helsinki); rohan@cisco.com; > >>>alan.johnston@mci.com; Mayer Georg (NMP-MSW/Helsinki); > >>>oritl@microsoft.com; xcon@ietf.org > >>>Subject: RE: [XCON] Chicken and Egg - Can CPCP create a conference > >>> > >>> > >>>Ah, I wondered when we would get to this. > >>> > >>>This is one of the bigger problems in separating conference policy > >>>from sip signalling. Everything would be simpler if the conference > >>>policy server was always the focus. > >>> > >>>So, I want to ask, can we make it be so? > >>> > >>>What are the advantages of making the conference policy server > >>>separate from the focus? Two ideas occur to me: > >>> 1. Separation of implementation > >>> But this is not possible with the > current framework > >>> because we don't specify the > interface between > >>> CPCP and SIP; we assume that it is > proprietary > >>> 2. Load Balancing > >>> But I really, really doubt that > works. It > >>>would be easier > >>> to have a separate CPS with every > focus, and replicate > >>> the combination > >>> > >>>So, what if we assume they are the same entity, and use the same ID? > >>>We don't need to have the conference policy be a URI, we merely have > >>>to locate the address of the server. So, it's the hostname of the > >>>conference URI. And a sip uri is a fine conference ID for the > >>>purpose of specifying which policy once we know where the server is. > >>> > >>>Is there some advantage of having the conference policy explicitly > >>>be a URI that I'm missing? > >>> > >>>Brian > >>> > >>> > >>>>-----Original Message----- > >>>>From: Paul Kiribati [mailto:pkyzivat@cisco.com] > >>>>Sent: Tuesday, December 02, 2003 2:44 PM > >>>>To: Rosen, Brian > >>>>Cc: 'hisham.khartabil@nokia.com'; rohan@cisco.com; > >>>>alan.johnston@mci.com; georg.mayer@nokia.com; oritl@microsoft.com; > >>>>xcon@ietf.org > >>>>Subject: Re: [XCON] Chicken and Egg - Can CPCP create a conference > >>>> > >>>> > >>>> > >>>> > >>>>Rosen, Brian wrote: > >>>> > >>>>>>If you look at XCAP list usage for example, you will see that > >>>>>>the list-URI used when sending SIP SUBSCRIBE requests to the > >>>>>>list is not the same as the URI used to manipulate the list > >>>>>>using XCAP. They certainly need to be linked, but not > >>>>>>necessarily the same. > >>>>>> > >>>>>>Depending on the protocol we chose, a SIP URI can or cannot > >>>>>>be used to identify a conference policy. > >>>>> > >>>>>I think we CAN always have the same ID. > >>>>>I think there is a lot of value in one ID > >>>>>I don't think there is any problem in having one ID > >>>>> > >>>>>So, I think there should be one. > >>>>> > >>>>>If there is a good reason, we can burden the conference > >>>> > >>>>policy server > >>>> > >>>>>with keeping the relationship, but unless there is a good > >>>> > >>>>reason, history > >>>> > >>>>>suggests that one namespace is better than two with linkage. > >>>> > >>>>[The chicken and the egg are different things. If I want to > >>>>talk to the > >>>>egg I need the address of the egg - having the address of > >>> > >>>the chicken > >>> > >>>>isn't sufficient. Its probably a bad idea to crack the egg in > >>>>order to > >>>>ask the chicken for the address of the egg.] > >>>> > >>>>Getting away from metaphors, this seems to be coming down to the > >>>>distinction between URIs and URLs. > >>>> > >>>>A sip address is a URL in that it is sufficient for me to > >>> > >>locate a > >> > >>>>corresponding (sip) resource. > >>>> > >>>>But it isn't sufficient for me to locate a CPCP resource. If > >>>>I knew how > >>>>to contact the appropriate CPCP server, perhaps a sip uri > >>>>could serve to > >>>>identify the policy. But that would require me to know the > >>> > >>>address of > >>> > >>>>the server a-priori. > >>>> > >>>>If all I have is the sip conference id, then to derive the > >>>>URI for the > >>>>policy from it I must invoke sip operations on it. > >>>> > >>>> Paul > >>>> > >>>> > >>>>_______________________________________________ > >>>>XCON mailing list > >>>>XCON@ietf.org > >>>>https://www1.ietf.org/mailman/listinfo/xcon > >>>> > >>> > >>_______________________________________________ > >>XCON mailing list > >>XCON@ietf.org > >>https://www1.ietf.org/mailman/listinfo/xcon > >> > > > > > > >_______________________________________________ >XCON mailing list >XCON@ietf.org >https://www1.ietf.org/mailman/listinfo/xcon _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Thu Dec 4 13:48:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08281 for ; Thu, 4 Dec 2003 13:48:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARyWA-00023M-8N for xcon-archive@odin.ietf.org; Thu, 04 Dec 2003 13:48:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB4Im2xi007886 for xcon-archive@odin.ietf.org; Thu, 4 Dec 2003 13:48:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARyWA-00022n-3E for xcon-web-archive@optimus.ietf.org; Thu, 04 Dec 2003 13:48:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08237 for ; Thu, 4 Dec 2003 13:47:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARyW7-0006Lj-00 for xcon-web-archive@ietf.org; Thu, 04 Dec 2003 13:47:59 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARyW7-0006Lf-00 for xcon-web-archive@ietf.org; Thu, 04 Dec 2003 13:47:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARyW8-00021X-K5; Thu, 04 Dec 2003 13:48:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARyVr-00020V-RK for xcon@optimus.ietf.org; Thu, 04 Dec 2003 13:47:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08231 for ; Thu, 4 Dec 2003 13:47:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARyVp-0006Lb-00 for xcon@ietf.org; Thu, 04 Dec 2003 13:47:41 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1ARyVo-0006Kq-00 for xcon@ietf.org; Thu, 04 Dec 2003 13:47:40 -0500 Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hB4Il6xg008678; Thu, 4 Dec 2003 13:47:06 -0500 (EST) Received: from mhammer-w2k03.cisco.com (dhcp-hrn-64-100-229-166.cisco.com [64.100.229.166]) by fruitpie.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AVK43836; Thu, 4 Dec 2003 10:46:55 -0800 (PST) Message-Id: <4.3.2.7.2.20031204134606.00b2d158@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 04 Dec 2003 13:46:55 -0500 To: hisham.khartabil@nokia.com From: Michael Hammer Subject: RE: [XCON] Chicken and Egg - Can CPCP create a conference Cc: , , , In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB701797493@esebe019.ntc.noki a.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , Hopefully, the security section addresses this as a potential DoS attack avenue. Mike At 11:56 AM 12/4/2003 +0200, hisham.khartabil@nokia.com wrote: >This is up to your conference server's intelligence. The server should >have rejected the second conference creation request if it has a first >come first serve logic. Or it can prioritise according to some method (or >you can buy more ports :) I don't think this is a show stopper either. > >/Hisham > > > -----Original Message----- > > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On Behalf Of ext > > Chris Boulton > > Sent: 04.December.2003 11:03 > > To: Nermeen Ismail; Rosen, Brian > > Cc: xcon@ietf.org > > Subject: RE: [XCON] Chicken and Egg - Can CPCP create a conference > > > > > > > > > > >-----Original Message----- > > >From: Nermeen Ismail [mailto:nismail@cisco.com] > > >Sent: 04 December 2003 03:56 > > >To: Rosen, Brian > > >Cc: xcon@ietf.org > > >Subject: RE: [XCON] Chicken and Egg - Can CPCP create a conference > > > > > >I have just seen this thread so I might be repeating what is laredy > > been > > >said. > > > > > >I agree that from the protocols point of view a conference is a > > conference. > > >It does not matter if it is ad hoc or scheduled. It has a unique URI, > > its > > >policy can be manipulated and authorized users can join/leave them > > either > > >by dial-in or dial-out. > > > > > >My understanding for why there are two ways to create a conference is > > to > > >support : > > >1- Creating a conference and joining it without having to implement > > >anything other than SIP (cc-conferencing). In this case sending an > > >INVITE to the URI factory is sufficient. Off course if the endpoint > > needs > > >to do something more like modifying the conference policy then > > >it needs to also implement CPCP/MPCP in which case it might have just > > used > > >that to create the conference. However the point is still that an > > >application can create, join a conference and get the roster without > > >needing anything other than a SIP stack. > > > > > >2- Creating a conference and never joining it. This is like > > the case of > > a > > >scheduling automata that at the time of conference scheduling it > > creates a > > >conference and a focus. In this case and as the application > > will never > > send > > >or receive media to the conference it was deemed inappropriate to > > demand > > >the application to have a SIP stack and send a no-media INVITE to > > create > > >the conference. Hence some non-SIP method will be used to create the > > >conference. A non-sip method will be used to create the conference > > (enters > > >CPCP) and this create-conference will be sent to the top-level policy > > >server URI which in return will send the conference URI and > > the policy > > >server URI for that conference. The only benefot that this method has > > >over number 1 is that the application does not have to support SIP. > > > > > >So a conference server needs to have a SIP stack, CPCP/MPCP and the > > >conference package but a client might only have a SIP stack, a > > CPCP/MPCP > > >implementation or both. > > > > > >On a separate topic, it was mentioned before that when a > > conference is > > >created a future start time can be specified. I see lots of > > complications > > >with that to do with time zones etc. Already the client that created > > the > > >conference has to deal with that and I do not see any benefit in > > extending > > >that to the conference server as well. So I see benefits in > > specifying > > a > > >conference duration but no benefit in specifying conference > > start time. > > >If the client creating the conference wishes the conference to start > > >accepting users in 5 minutes time then it needs to delay sending the > > create > > >conference 5 minutes. > > > > [Chris Boulton] I'm not disagreeing with this point just > > thinking about > > it a bit more. I guess the main concern I have is related to the > > scheduling of resources. Are you saying that resources would not be > > scheduled (not reserved) for this conference until the moment > > it starts. > > So if I schedule a conference for a weeks time - then on the > > day of the > > conference, one of my colleagues schedules + starts a conference 10 > > minutes before mine and uses up all of my companies port allocation - > > that means it's tough for me???? (And the answer isn't to buy more > > ports before anyone suggests it ;-) > > > > > > > > > > >nermeen > > > > > > > > > > > > > > > > > >> > >We must stop talking about "ad-hoc conferences" and "scheduled > > >> > conferences" > > >> > >- there is no such thing. There are only ad-hoc mechanisms and > > >> > scheduled > > >> > >mechanisms to create/join a conference. > > >>Which, I think, is completely useless. > > >>And, to be specific: > > >> There is no difference in how you join a conference > > >> You always send an INVITE, or get a REFER, > > >> or receive an INVITE. You can't join with > > >> CPCP. > > >> There is no reason to have a difference to create one > > >> > > >> > > > >> > [Chris Boulton] I totally agree. Whether 'ad-hoc' or > > >> > 'scheduled' means > > >> > are used to create a conference should have no effect - a > > conference > > >> > should be created and a default policy applied. Then, > > if it is an > > >> > 'ad-hoc' conference, a participant is free to join and if it is a > > >> > scheduled, the creator may manipulate the conference policy. > > >>Why is it different with ad-hoc that a participant is free to join? > > >>Why is it different with scheduled that the creator may manipulate > > >>the conference policy? > > >> > > >>I think there is no difference at all. No matter how you create it, > > >>participants are free to join any time the policy says they pay. > > >>No matter how you create it, the creator may manipulate the > > conference > > >>policy (and participants may manipulate it also, subject to > > permissions). > > >> > > >> > > >> > >So, if The Example Company already has their public web server > > home > > >> > page at > > >> > >example.com where everyone goes to download the latest examples, > > this > > >> > web > > >> > >server now needs to become the conference policy server? > > >>No, unless the example.com is also the focus host. If it > > is, then the > > >>web server is there too. That is just not a limitation > > worth worrying > > >>about. > > >> > > >> > > >> > > > > >> > >There are significant disadvantages in limiting > > ourselves to such > > >> > >conventions - especially when there are other ways of > > discovering > > the > > >> > >policy URI. One way that has been discussed is advertising > > >> > the policy > > >> > URI > > >> > >in conference package notifications. Is this not sufficient? > > This > > >> > >approach is flexible and extensible (different protocols for > > policy > > >> > >manipulation can be defined with a new URI scheme) and has > > >> > none of the > > >> > name > > >> > >space limitations of this proposal. > > >> > > > >> > [Chris Boulton] This approach does seem to 'shoe-horn' the HTTP > > usage > > >> > and IMHO is quite an ugly solution. As Alan points out, > > policy URI > > >> > contained in conference packages is a far more elegant solution. > > >> > > > >>My problem is that we seem to be heading to a solution where there > > >>is no subset of capabilities. To do anything, you need to > > implement: > > >> cc conference > > >>AND > > >> cpcp > > >>AND > > >> mpcp > > >>AND > > >> the conference package > > >> > > >>There are no simple implementations other than conference unaware. > > >>Is that really what we want to do? Intertwine all the > > pieces so that > > >>there is no clean functional separation that allows implementation > > >>flexibility without creating incompatibility? In this specific > > >>case, why do you have to implement the conference package in order > > >>to discover the conference policy uri? > > >> > > >>A message or two ago, Alan talked about automata manipulating > > conference > > >>policy, and you were aghast that I proposed using SIP means to > > >>create a conference ID. You now want the automata to use SIP means > > >>to find a conference policy URI given a conference URI; > > they even have > > >>to join the conference to do so, unless the automata created the > > >>conference in the first place, where it may get the > > conference policy > > >>uri returned to it). > > >> > > >>Can't we give up a slight amount of flexibility to get the > > possibility > > >>of more widespread use of this facility by limiting implementation > > >>complexity? Maybe we need some use case stuff to see how subsets > > might > > >>be useful. > > >> > > >> > > >>_______________________________________________ > > >>XCON mailing list > > >>XCON@ietf.org > > >>https://www1.ietf.org/mailman/listinfo/xcon > > > > > > > > >_______________________________________________ > > >XCON mailing list > > >XCON@ietf.org > > >https://www1.ietf.org/mailman/listinfo/xcon > > > > > >_____________________________________________________________ > > __________ > > _ > > >This email has been scanned for all viruses by the MessageLabs Email > > >Security System. For more information on a proactive email security > > >service working around the clock, around the globe, visit > > >http://www.messagelabs.com > > >_____________________________________________________________ > > __________ > > _ > > > > ______________________________________________________________ > > __________ > > This email has been scanned for all viruses by the MessageLabs Email > > Security System. For more information on a proactive email security > > service working around the clock, around the globe, visit > > http://www.messagelabs.com > > ______________________________________________________________ > > __________ > > > > _______________________________________________ > > XCON mailing list > > XCON@ietf.org > > https://www1.ietf.org/mailman/listinfo/xcon > > > >_______________________________________________ >XCON mailing list >XCON@ietf.org >https://www1.ietf.org/mailman/listinfo/xcon _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Thu Dec 4 14:06:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08862 for ; Thu, 4 Dec 2003 14:06:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARync-0002lU-W7 for xcon-archive@odin.ietf.org; Thu, 04 Dec 2003 14:06:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB4J64Ta010622 for xcon-archive@odin.ietf.org; Thu, 4 Dec 2003 14:06:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARync-0002lF-RM for xcon-web-archive@optimus.ietf.org; Thu, 04 Dec 2003 14:06:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08858 for ; Thu, 4 Dec 2003 14:05:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARynZ-0006be-00 for xcon-web-archive@ietf.org; Thu, 04 Dec 2003 14:06:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARynY-0006bW-00 for xcon-web-archive@ietf.org; Thu, 04 Dec 2003 14:06:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARyna-0002kW-0T; Thu, 04 Dec 2003 14:06:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARymy-0002jy-K7 for xcon@optimus.ietf.org; Thu, 04 Dec 2003 14:05:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08809 for ; Thu, 4 Dec 2003 14:05:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARymw-0006bC-00 for xcon@ietf.org; Thu, 04 Dec 2003 14:05:22 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1ARymv-0006aq-00 for xcon@ietf.org; Thu, 04 Dec 2003 14:05:21 -0500 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hB4J4mxg014232 for ; Thu, 4 Dec 2003 14:04:48 -0500 (EST) Received: from cisco.com ([161.44.79.239]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AEK74388; Thu, 4 Dec 2003 14:04:47 -0500 (EST) Message-ID: <3FCF854F.5050508@cisco.com> Date: Thu, 04 Dec 2003 14:04:47 -0500 From: Paul Kyzivat 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: xcon@ietf.org Subject: Re: [XCON] Chicken and Egg - Can CPCP create a conference References: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD902D592F0@esebe013.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit aki.niemi@nokia.com wrote: > > In any case, aren't we talking about simply passing on some information about > the conference to its participants. So, have the focus return in a 200 OK > to an INVITE: > > Call-Info: ;purpose=xcap-cpcp > > This lets the client know where to go and do XCAP CPCP if it wants to manipulate the policy. This seems like a good idea. Carrying that thought further, consider the case where, by policy, the conference isn't accepting calls now. (E.g. the start time of the conference hasn't arrived yet.) In that case the server must respond with some sort of error to incoming invites. An obvious thing to do would be to return 480 Temporarily Unavailable. In addition to that, it might be good to return an Error-Info with a reference to the conference policy. This would provide a translation from focus uri to policy uri that can't easily be obtained any other way. I suggest that some well defined and useful behavior (whether its exactly what I propose above or something else) be normative. Paul _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Thu Dec 4 14:07:28 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08992 for ; Thu, 4 Dec 2003 14:07:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARyoa-0002qw-4h for xcon-archive@odin.ietf.org; Thu, 04 Dec 2003 14:07:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB4J73Vo010902 for xcon-archive@odin.ietf.org; Thu, 4 Dec 2003 14:07:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARyoZ-0002pH-Cw for xcon-web-archive@optimus.ietf.org; Thu, 04 Dec 2003 14:07:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08903 for ; Thu, 4 Dec 2003 14:06:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARyoW-0006cJ-00 for xcon-web-archive@ietf.org; Thu, 04 Dec 2003 14:07:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARyoW-0006cG-00 for xcon-web-archive@ietf.org; Thu, 04 Dec 2003 14:07:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARyoY-0002oN-Bb; Thu, 04 Dec 2003 14:07:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARyoR-0002nH-G9 for xcon@optimus.ietf.org; Thu, 04 Dec 2003 14:06:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08900 for ; Thu, 4 Dec 2003 14:06:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARyoO-0006cB-00 for xcon@ietf.org; Thu, 04 Dec 2003 14:06:52 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1ARyoO-0006bt-00 for xcon@ietf.org; Thu, 04 Dec 2003 14:06:52 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by sj-iport-5.cisco.com with ESMTP; 04 Dec 2003 11:06:58 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hB4J6Ixg014705; Thu, 4 Dec 2003 14:06:19 -0500 (EST) Received: from cisco.com ([161.44.79.239]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AEK74523; Thu, 4 Dec 2003 14:06:17 -0500 (EST) Message-ID: <3FCF85A9.9000505@cisco.com> Date: Thu, 04 Dec 2003 14:06:17 -0500 From: Paul Kyzivat 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: Alan Johnston CC: "Rosen, Brian" , "'Avshalom Houri'" , xcon@ietf.org Subject: Re: [XCON] Chicken and Egg - Can CPCP create a conference References: <5.2.1.1.0.20031204090448.02bd2608@pop.mcit.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Alan Johnston wrote: > At 09:41 AM 12/4/2003 -0500, Rosen, Brian wrote: > >> Although I've caved on the issue of using conference uri to generate >> conference policy uri, this message seems to address the issue of one >> or two mechanisms to create conferences. I think that just because we >> create SIP mechanisms to create conferences does not prohibit any other >> signaling protocol (H.323 for example) from creating conferences, >> which could then use CPCP for conference policy control. >> They might already have mechanisms to create conferences. >> >> Looking at it another way, why should CPCP create SIP (emphasis added) >> uris? Clearly, it should be independent of the signalling protocol. >> To make this work, we would have to have a way to specify what kind >> of uri we wanted to create if CPCP can create conferences. > > > This is a very good point. It seems logical that sip, sips, tel, h323, > and maybe even im URIs could be requested. We need to give this > requirement some more thought. I agree. Paul P.S. Brian - see, I don't always disagree with you. _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Thu Dec 4 18:28:17 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25130 for ; Thu, 4 Dec 2003 18:28:16 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AS2t9-0007Oa-6a for xcon-archive@odin.ietf.org; Thu, 04 Dec 2003 18:28:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB4NS3DE028422 for xcon-archive@odin.ietf.org; Thu, 4 Dec 2003 18:28:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AS2t8-0007OL-VZ for xcon-web-archive@optimus.ietf.org; Thu, 04 Dec 2003 18:28:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25100 for ; Thu, 4 Dec 2003 18:27:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AS2t6-0004PB-00 for xcon-web-archive@ietf.org; Thu, 04 Dec 2003 18:28:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AS2t5-0004P7-00 for xcon-web-archive@ietf.org; Thu, 04 Dec 2003 18:27:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AS2t6-0007O3-Vs; Thu, 04 Dec 2003 18:28:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AS2sd-0007Nl-HM for xcon@optimus.ietf.org; Thu, 04 Dec 2003 18:27:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25073 for ; Thu, 4 Dec 2003 18:27:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AS2sa-0004OZ-00 for xcon@ietf.org; Thu, 04 Dec 2003 18:27:28 -0500 Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx with esmtp (Exim 4.12) id 1AS2sZ-0004OF-00 for xcon@ietf.org; Thu, 04 Dec 2003 18:27:28 -0500 Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 4 Dec 2003 15:26:29 -0800 Received: from 157.54.8.109 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 04 Dec 2003 15:26:58 -0800 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by inet-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 4 Dec 2003 15:26:56 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] CPCP and Conference URIs - there are more than one! Date: Thu, 4 Dec 2003 15:26:59 -0800 Message-ID: Thread-Topic: [XCON] CPCP and Conference URIs - there are more than one! Thread-Index: AcO6ezzx1k1NEO+CQzyak5g4rmGnqQAAFiuQAAaxUQA= From: "Orit Levin" To: , , X-OriginalArrivalTime: 04 Dec 2003 23:26:56.0842 (UTC) FILETIME=[1BBCDAA0:01C3BABE] Content-Transfer-Encoding: quoted-printable Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Yes, a conference can have a list of URI identifiers and the CPCP needs to reflect it. My question is: Would we like to reflect this fact in the SIP Conference Package as well? (At least - as an optional structure :-) Orit.=20 -----Original Message----- From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org] On Behalf Of hisham.khartabil@nokia.com Sent: Thursday, December 04, 2003 7:35 AM To: Brian.Rosen@marconi.com; xcon@ietf.org Subject: RE: [XCON] CPCP and Conference URIs - there are more than one! Brian, No argument there. We thought of that when we where creating the xcap based solution. The current solution can only hold a tel and a sip URI. We plan on changing this. Looks like a requirement needs to be added to the requirements document. Does the solution need to be future proof? or do we just allow listing the currently known protocols? Regards, Hisham > -----Original Message----- > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On Behalf Of ext > Rosen, Brian > Sent: 04.December.2003 16:48 > To: 'xcon@ietf.org' > Subject: [XCON] CPCP and Conference URIs - there are more than one! >=20 >=20 > The discussion of multiple ways to create conferences triggered a=20 > discussion of XCON work being useable with multiple "using" (to borrow > a phrase from geopriv) protocols. >=20 > We have been assuming that CPCP will, at one time or another, accept=20 > or receive a conference uri, which has so far been thought of as a SIP > uri. This will not do. There has to be a LIST of conference URIs,=20 > one for each using protocol the conference might support. >=20 > There are already conference bridges that accept both SIP and H.323=20 > endpoints intermixed. The conference uri for the H.323 endpoints does > not start with "sip:" folks! >=20 > There might even be a tel uri in there, right?!!! > Ooh, Ooh, sure would be nice if that tel uri could have the PIN. > Nah, over the top :) >=20 > Brian >=20 > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon >=20 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Thu Dec 4 18:45:18 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26084 for ; Thu, 4 Dec 2003 18:45:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AS39c-00088G-Ld for xcon-archive@odin.ietf.org; Thu, 04 Dec 2003 18:45:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB4Nj4tw031254 for xcon-archive@odin.ietf.org; Thu, 4 Dec 2003 18:45:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AS39c-00087t-1w for xcon-web-archive@optimus.ietf.org; Thu, 04 Dec 2003 18:45:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26074 for ; Thu, 4 Dec 2003 18:44:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AS39Z-0004l6-00 for xcon-web-archive@ietf.org; Thu, 04 Dec 2003 18:45:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AS39Y-0004l3-00 for xcon-web-archive@ietf.org; Thu, 04 Dec 2003 18:45:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AS39a-00087W-5R; Thu, 04 Dec 2003 18:45:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AS39G-000879-MO for xcon@optimus.ietf.org; Thu, 04 Dec 2003 18:44:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26068 for ; Thu, 4 Dec 2003 18:44:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AS39D-0004kl-00 for xcon@ietf.org; Thu, 04 Dec 2003 18:44:39 -0500 Received: from dgesmtp02.wcom.com ([199.249.16.17]) by ietf-mx with esmtp (Exim 4.12) id 1AS39C-0004ki-00 for xcon@ietf.org; Thu, 04 Dec 2003 18:44:38 -0500 Received: from pmismtp01.wcomnet.com ([166.38.62.36]) by firewall.wcom.com (Iplanet MTA 5.2) with ESMTP id <0HPE00GDL9H7MD@firewall.wcom.com> for xcon@ietf.org; Thu, 04 Dec 2003 23:34:19 +0000 (GMT) Received: from pmismtp01.wcomnet.com by pmismtp01.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0HPE009019H771@pmismtp01.wcomnet.com>; Thu, 04 Dec 2003 23:34:19 +0000 (GMT) Received: from xs578v3521.mci.com ([166.50.128.164]) by pmismtp01.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0HPE006QY9H45I@pmismtp01.wcomnet.com>; Thu, 04 Dec 2003 23:34:19 +0000 (GMT) Date: Thu, 04 Dec 2003 17:34:16 -0600 From: Alan Johnston Subject: RE: [XCON] CPCP and Conference URIs - there are more than one! X-Sender: Alan.Johnston@pop.mcit.com To: Orit Levin , hisham.khartabil@nokia.com, Brian.Rosen@marconi.com, xcon@ietf.org Message-id: <5.2.1.1.0.20031204173244.02a2f998@pop.mcit.com> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Content-type: text/plain; charset=us-ascii; format=flowed Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , At 03:26 PM 12/4/2003 -0800, Orit Levin wrote: >Yes, a conference can have a list of URI identifiers and the CPCP needs >to reflect it. > >My question is: Would we like to reflect this fact in the SIP Conference >Package as well? (At least - as an optional structure :-) Yes! Thanks, Alan Johnston MCI sip:alan@sipstation.com >Orit. > >-----Original Message----- >From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org] On Behalf Of >hisham.khartabil@nokia.com >Sent: Thursday, December 04, 2003 7:35 AM >To: Brian.Rosen@marconi.com; xcon@ietf.org >Subject: RE: [XCON] CPCP and Conference URIs - there are more than one! > >Brian, > >No argument there. We thought of that when we where creating the xcap >based solution. The current solution can only hold a tel and a sip URI. >We plan on changing this. > >Looks like a requirement needs to be added to the requirements document. >Does the solution need to be future proof? or do we just allow listing >the currently known protocols? > >Regards, >Hisham > > > -----Original Message----- > > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On Behalf Of ext > > > Rosen, Brian > > Sent: 04.December.2003 16:48 > > To: 'xcon@ietf.org' > > Subject: [XCON] CPCP and Conference URIs - there are more than one! > > > > > > The discussion of multiple ways to create conferences triggered a > > discussion of XCON work being useable with multiple "using" (to borrow > > > a phrase from geopriv) protocols. > > > > We have been assuming that CPCP will, at one time or another, accept > > or receive a conference uri, which has so far been thought of as a SIP > > > uri. This will not do. There has to be a LIST of conference URIs, > > one for each using protocol the conference might support. > > > > There are already conference bridges that accept both SIP and H.323 > > endpoints intermixed. The conference uri for the H.323 endpoints does > > > not start with "sip:" folks! > > > > There might even be a tel uri in there, right?!!! > > Ooh, Ooh, sure would be nice if that tel uri could have the PIN. > > Nah, over the top :) > > > > Brian > > > > _______________________________________________ > > XCON mailing list > > XCON@ietf.org > > https://www1.ietf.org/mailman/listinfo/xcon > > > >_______________________________________________ >XCON mailing list >XCON@ietf.org >https://www1.ietf.org/mailman/listinfo/xcon > > > >_______________________________________________ >XCON mailing list >XCON@ietf.org >https://www1.ietf.org/mailman/listinfo/xcon _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Fri Dec 5 03:38:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25690 for ; Fri, 5 Dec 2003 03:38:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASBTR-0001tY-1A for xcon-archive@odin.ietf.org; Fri, 05 Dec 2003 03:38:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB58c4oR007271 for xcon-archive@odin.ietf.org; Fri, 5 Dec 2003 03:38:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASBTQ-0001t4-6J for xcon-web-archive@optimus.ietf.org; Fri, 05 Dec 2003 03:38:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25678 for ; Fri, 5 Dec 2003 03:37:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ASBTN-0004nP-00 for xcon-web-archive@ietf.org; Fri, 05 Dec 2003 03:38:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ASBTN-0004nK-00 for xcon-web-archive@ietf.org; Fri, 05 Dec 2003 03:38:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASBTO-0001sK-5T; Fri, 05 Dec 2003 03:38:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASBSp-0001kC-N4 for xcon@optimus.ietf.org; Fri, 05 Dec 2003 03:37:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25665 for ; Fri, 5 Dec 2003 03:37:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ASBSn-0004n0-00 for xcon@ietf.org; Fri, 05 Dec 2003 03:37:25 -0500 Received: from mail49.messagelabs.com ([193.109.255.19]) by ietf-mx with smtp (Exim 4.12) id 1ASBSm-0004ml-00 for xcon@ietf.org; Fri, 05 Dec 2003 03:37:24 -0500 X-VirusChecked: Checked X-Env-Sender: cboulton@ubiquity.net X-Msg-Ref: server-6.tower-49.messagelabs.com!1070613389!609846 X-StarScan-Version: 5.1.13; banners=ubiquity.net,-,- Received: (qmail 7264 invoked from network); 5 Dec 2003 08:36:30 -0000 Received: from news.ubiquity.net (HELO gbnewp0186s1.eu.ubiquity.net) (194.202.146.92) by server-6.tower-49.messagelabs.com with SMTP; 5 Dec 2003 08:36:30 -0000 Received: from mailhost.eu.ubiquity.net by gbnewp0186s1.eu.ubiquity.net via smtpd (for mail49.messagelabs.com [193.109.255.19]) with SMTP; Fri, 5 Dec 2003 08:39:02 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] CPCP and Conference URIs - there are more than one! Date: Fri, 5 Dec 2003 08:34:27 -0000 Message-ID: <45730E094814E44488F789C1CDED27AE01E22F09@gbnewp0758m.eu.ubiquity.net> Thread-Topic: [XCON] CPCP and Conference URIs - there are more than one! Thread-Index: AcO6wGuTTY3Lox8RS1+NO3BetT4h6gASe5QA From: "Chris Boulton" To: "Alan Johnston" , "Orit Levin" , , , Content-Transfer-Encoding: quoted-printable Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Yes=20I=20think=20so=20also=20-=20for=20completeness=20the=20package=20sho= uld=20indicate=20a generic=20URI=20rather=20than=20binding=20only=20to=20SIP. Chris. >-----Original=20Message----- >From:=20Alan=20Johnston=20[mailto:alan.johnston@mci.com] >Sent:=2004=20December=202003=2023:34 >To:=20Orit=20Levin;=20hisham.khartabil@nokia.com;=20Brian.Rosen@marconi.c= om; >xcon@ietf.org >Subject:=20RE:=20[XCON]=20CPCP=20and=20Conference=20URIs=20-=20there=20ar= e=20more=20than=20one! > >At=2003:26=20PM=2012/4/2003=20-0800,=20Orit=20Levin=20wrote: >>Yes,=20a=20conference=20can=20have=20a=20list=20of=20URI=20identifiers=20= and=20the=20CPCP needs >>to=20reflect=20it. >> >>My=20question=20is:=20Would=20we=20like=20to=20reflect=20this=20fact=20i= n=20the=20SIP Conference >>Package=20as=20well?=20(At=20least=20-=20as=20an=20optional=20structure=20= :-) > >Yes! > >Thanks, >Alan=20Johnston >MCI >sip:alan@sipstation.com > >>Orit. >> >>-----Original=20Message----- >>From:=20xcon-admin@ietf.org=20[mailto:xcon-admin@ietf.org]=20On=20Behalf= =20Of >>hisham.khartabil@nokia.com >>Sent:=20Thursday,=20December=2004,=202003=207:35=20AM >>To:=20Brian.Rosen@marconi.com;=20xcon@ietf.org >>Subject:=20RE:=20[XCON]=20CPCP=20and=20Conference=20URIs=20-=20there=20a= re=20more=20than one! >> >>Brian, >> >>No=20argument=20there.=20We=20thought=20of=20that=20when=20we=20where=20= creating=20the=20xcap >>based=20solution.=20The=20current=20solution=20can=20only=20hold=20a=20t= el=20and=20a=20sip URI. >>We=20plan=20on=20changing=20this. >> >>Looks=20like=20a=20requirement=20needs=20to=20be=20added=20to=20the=20re= quirements document. >>Does=20the=20solution=20need=20to=20be=20future=20proof?=20or=20do=20we=20= just=20allow=20listing >>the=20currently=20known=20protocols? >> >>Regards, >>Hisham >> >>=20>=20-----Original=20Message----- >>=20>=20From:=20xcon-admin@ietf.org=20[mailto:xcon-admin@ietf.org]On=20Be= half=20Of ext >> >>=20>=20Rosen,=20Brian >>=20>=20Sent:=2004.December.2003=2016:48 >>=20>=20To:=20'xcon@ietf.org' >>=20>=20Subject:=20[XCON]=20CPCP=20and=20Conference=20URIs=20-=20there=20= are=20more=20than=20one! >>=20> >>=20> >>=20>=20The=20discussion=20of=20multiple=20ways=20to=20create=20conferenc= es=20triggered=20a >>=20>=20discussion=20of=20XCON=20work=20being=20useable=20with=20multiple= =20"using"=20(to borrow >> >>=20>=20a=20phrase=20from=20geopriv)=20protocols. >>=20> >>=20>=20We=20have=20been=20assuming=20that=20CPCP=20will,=20at=20one=20ti= me=20or=20another, accept >>=20>=20or=20receive=20a=20conference=20uri,=20which=20has=20so=20far=20b= een=20thought=20of=20as=20a SIP >> >>=20>=20uri.=20=20This=20will=20not=20do.=20=20There=20has=20to=20be=20a=20= LIST=20of=20conference=20URIs, >>=20>=20one=20for=20each=20using=20protocol=20the=20conference=20might=20= support. >>=20> >>=20>=20There=20are=20already=20conference=20bridges=20that=20accept=20bo= th=20SIP=20and=20H.323 >>=20>=20endpoints=20intermixed.=20=20The=20conference=20uri=20for=20the=20= H.323=20endpoints does >> >>=20>=20not=20start=20with=20"sip:"=20folks! >>=20> >>=20>=20There=20might=20even=20be=20a=20tel=20uri=20in=20there,=20right?!= !! >>=20>=20Ooh,=20Ooh,=20sure=20would=20be=20nice=20if=20that=20tel=20uri=20= could=20have=20the=20PIN. >>=20>=20Nah,=20over=20the=20top=20:) >>=20> >>=20>=20Brian >>=20> >>=20>=20_______________________________________________ >>=20>=20XCON=20mailing=20list >>=20>=20XCON@ietf.org >>=20>=20https://www1.ietf.org/mailman/listinfo/xcon >>=20> >> >>_______________________________________________ >>XCON=20mailing=20list >>XCON@ietf.org >>https://www1.ietf.org/mailman/listinfo/xcon >> >> >> >>_______________________________________________ >>XCON=20mailing=20list >>XCON@ietf.org >>https://www1.ietf.org/mailman/listinfo/xcon > > >_______________________________________________ >XCON=20mailing=20list >XCON@ietf.org >https://www1.ietf.org/mailman/listinfo/xcon > >_______________________________________________________________________ _ >This=20email=20has=20been=20scanned=20for=20all=20viruses=20by=20the=20Me= ssageLabs=20Email >Security=20System.=20For=20more=20information=20on=20a=20proactive=20emai= l=20security >service=20working=20around=20the=20clock,=20around=20the=20globe,=20visit= >http://www.messagelabs.com >_______________________________________________________________________ _ ________________________________________________________________________ This=20email=20has=20been=20scanned=20for=20all=20viruses=20by=20the=20Mes= sageLabs=20Email Security=20System.=20For=20more=20information=20on=20a=20proactive=20email= =20security service=20working=20around=20the=20clock,=20around=20the=20globe,=20visit http://www.messagelabs.com ________________________________________________________________________ _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Fri Dec 5 03:41:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25738 for ; Fri, 5 Dec 2003 03:41:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASBWK-00024F-U8 for xcon-archive@odin.ietf.org; Fri, 05 Dec 2003 03:41:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB58f4ns007937 for xcon-archive@odin.ietf.org; Fri, 5 Dec 2003 03:41:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASBWK-00023s-4t for xcon-web-archive@optimus.ietf.org; Fri, 05 Dec 2003 03:41:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25731 for ; Fri, 5 Dec 2003 03:40:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ASBWH-0004oU-00 for xcon-web-archive@ietf.org; Fri, 05 Dec 2003 03:41:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ASBWH-0004oR-00 for xcon-web-archive@ietf.org; Fri, 05 Dec 2003 03:41:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASBWI-00023G-BV; Fri, 05 Dec 2003 03:41:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASBVP-00022E-7x for xcon@optimus.ietf.org; Fri, 05 Dec 2003 03:40:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25720 for ; Fri, 5 Dec 2003 03:39:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ASBVM-0004oA-00 for xcon@ietf.org; Fri, 05 Dec 2003 03:40:04 -0500 Received: from mail49.messagelabs.com ([193.109.255.19]) by ietf-mx with smtp (Exim 4.12) id 1ASBVL-0004ny-00 for xcon@ietf.org; Fri, 05 Dec 2003 03:40:04 -0500 X-VirusChecked: Checked X-Env-Sender: cboulton@ubiquity.net X-Msg-Ref: server-15.tower-49.messagelabs.com!1070613572!455555 X-StarScan-Version: 5.1.13; banners=ubiquity.net,-,- Received: (qmail 14846 invoked from network); 5 Dec 2003 08:39:33 -0000 Received: from news.ubiquity.net (HELO gbnewp0186s1.eu.ubiquity.net) (194.202.146.92) by server-15.tower-49.messagelabs.com with SMTP; 5 Dec 2003 08:39:33 -0000 Received: from mailhost.eu.ubiquity.net by gbnewp0186s1.eu.ubiquity.net via smtpd (for mail49.messagelabs.com [193.109.255.19]) with SMTP; Fri, 5 Dec 2003 08:42:06 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] CPCP requirements to support IMS Date: Fri, 5 Dec 2003 08:37:31 -0000 Message-ID: <45730E094814E44488F789C1CDED27AE01E22F0A@gbnewp0758m.eu.ubiquity.net> Thread-Topic: [XCON] CPCP requirements to support IMS Thread-Index: AcO6gz32i1nhy9udTvm4kFzCbK3E6gAh6dKQ From: "Chris Boulton" To: "Rosen, Brian" , "Marjou Xavier" , Content-Transfer-Encoding: quoted-printable Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Agreed=20-=20that=20is=20the=20whole=20point=20of=20contact.=20=20You=20in= itiate=20a=20request with=20a=20generalized=20location=20and=20get=20pointed=20to=20a=20specifi= c=20location=20for subsequent=20requests.=20=20This=20fits=20perfectly. Chris. >-----Original=20Message----- >From:=20Rosen,=20Brian=20[mailto:Brian.Rosen@marconi.com] >Sent:=2004=20December=202003=2016:23 >To:=20'Marjou=20Xavier';=20xcon@ietf.org >Subject:=20RE:=20[XCON]=20CPCP=20requirements=20to=20support=20IMS > >Look=20at=20how=203XX=20responses=20are=20handled=20in=20RFC3261 >The=20Contact=20header=20has=20the=20URI=20for=20the=20client=20to=20use.= > >Brian > >>=20-----Original=20Message----- >>=20From:=20Marjou=20Xavier=20[mailto:xavier.marjou@siemens.com] >>=20Sent:=20Thursday,=20December=2004,=202003=2011:13=20AM >>=20To:=20xcon@ietf.org >>=20Subject:=20RE:=20[XCON]=20CPCP=20requirements=20to=20support=20IMS >> >> >>=20>=20You=20send=20an=20INVITE=20to=20the=20conference=20factory=20uri,= >>=20>=20and=20it=20returns=20a=20Contact=20which=20is=20a=20conference=20= uri. >> >>=20Although=20I=20understand=20the=20need=20for=20this=20for=20an=20ad-h= oc >>=20conference,=20is=20it=20really=20inline=20with=20SIP=20to=20return=20= a >>=20specialized=20Contact=20header=20in=20a=20response=20to=20an=20INVITE= =20message? >> >>=20In=20my=20opinion,=20returning=20a=20specialized=20Contact=20header=20= is=20only >>=20possible=20during=20the=20REGISTER=20step.=20(However,=20I=20agree=20= I=20did >>=20not=20find=20this=20explicitly=20written=20in=203261) >> >>=20Xavier >> >> >> >> >> >>=20_______________________________________________ >>=20XCON=20mailing=20list >>=20XCON@ietf.org >>=20https://www1.ietf.org/mailman/listinfo/xcon >> > >_______________________________________________ >XCON=20mailing=20list >XCON@ietf.org >https://www1.ietf.org/mailman/listinfo/xcon > >_______________________________________________________________________ _ >This=20email=20has=20been=20scanned=20for=20all=20viruses=20by=20the=20Me= ssageLabs=20Email >Security=20System.=20For=20more=20information=20on=20a=20proactive=20emai= l=20security >service=20working=20around=20the=20clock,=20around=20the=20globe,=20visit= >http://www.messagelabs.com >_______________________________________________________________________ _ ________________________________________________________________________ This=20email=20has=20been=20scanned=20for=20all=20viruses=20by=20the=20Mes= sageLabs=20Email Security=20System.=20For=20more=20information=20on=20a=20proactive=20email= =20security service=20working=20around=20the=20clock,=20around=20the=20globe,=20visit http://www.messagelabs.com ________________________________________________________________________ _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Fri Dec 5 04:37:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28040 for ; Fri, 5 Dec 2003 04:37:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASCOY-0004G1-PB for xcon-archive@odin.ietf.org; Fri, 05 Dec 2003 04:37:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB59b628016308 for xcon-archive@odin.ietf.org; Fri, 5 Dec 2003 04:37:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASCOX-0004Ex-9t for xcon-web-archive@optimus.ietf.org; Fri, 05 Dec 2003 04:37:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28028 for ; Fri, 5 Dec 2003 04:36:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ASCOU-0005uG-00 for xcon-web-archive@ietf.org; Fri, 05 Dec 2003 04:37:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ASCOT-0005uD-00 for xcon-web-archive@ietf.org; Fri, 05 Dec 2003 04:37:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASCOV-0004E9-N9; Fri, 05 Dec 2003 04:37:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASCNt-0004DV-Ht for xcon@optimus.ietf.org; Fri, 05 Dec 2003 04:36:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28017 for ; Fri, 5 Dec 2003 04:36:10 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ASCNq-0005tx-00 for xcon@ietf.org; Fri, 05 Dec 2003 04:36:22 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1ASCNp-0005tu-00 for xcon@ietf.org; Fri, 05 Dec 2003 04:36:21 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hB59aL105398 for ; Fri, 5 Dec 2003 11:36:22 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 5 Dec 2003 11:36:20 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 5 Dec 2003 11:36:20 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] Chicken and Egg - Can CPCP create a conference Date: Fri, 5 Dec 2003 11:36:20 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7017974A8@esebe019.ntc.nokia.com> Thread-Topic: [XCON] Chicken and Egg - Can CPCP create a conference Thread-Index: AcO5209o+fZpgKN/TGqWjYfbPaph6AAfvqKwAACSeyAALZ5R4A== To: , , Cc: X-OriginalArrivalTime: 05 Dec 2003 09:36:20.0898 (UTC) FILETIME=[3D9D0820:01C3BB13] Content-Transfer-Encoding: quoted-printable Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > >=20 > > I don't like to couple these elements unnecessarily using any=20 > > type of URI naming conventions. An equally possible setup is=20 > > one where the policy server is in fact separate XCAP server,=20 > > and both the conference participant and the focus are XCAP clients. > >=20 > > In any case, aren't we talking about simply passing on some=20 > > information about the conference to its participants. So,=20 > > have the focus return in a 200 OK to an INVITE: > >=20 > > Call-Info:=20 > > > icy12345.xml>;purpose=3Dxcap-cpcp > >=20 > > This lets the client know where to go and do XCAP CPCP if it=20 > > wants to manipulate the policy. >=20 > This would work for participants who don't want to subscribe=20 > to the conference event package. Carrying the policy ID in=20 > the event package is also beneficial in that users can=20 > manipulate the conference policy without having to actually=20 > join the conference. They learn the policy ID using SUB/NOT=20 > without having to send INVITE. >=20 > So I guess both methods are needed. Where should these solutions be documented? in cc conferencing document = in sipping? >=20 > Regards, > Hisham >=20 > >=20 > > Cheers, > > Aki > >=20 > >=20 > >=20 > > > >=20 > > _______________________________________________ > > XCON mailing list > > XCON@ietf.org > > https://www1.ietf.org/mailman/listinfo/xcon > >=20 >=20 > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon >=20 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Fri Dec 5 12:54:18 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16165 for ; Fri, 5 Dec 2003 12:54:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASK9T-0005sw-4Q for xcon-archive@odin.ietf.org; Fri, 05 Dec 2003 12:54:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB5Hs3Cd022618 for xcon-archive@odin.ietf.org; Fri, 5 Dec 2003 12:54:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASK9S-0005sj-Sd for xcon-web-archive@optimus.ietf.org; Fri, 05 Dec 2003 12:54:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16131 for ; Fri, 5 Dec 2003 12:53:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ASK9R-0006DQ-00 for xcon-web-archive@ietf.org; Fri, 05 Dec 2003 12:54:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ASK9Q-0006DL-00 for xcon-web-archive@ietf.org; Fri, 05 Dec 2003 12:54:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASK9R-0005rS-CO; Fri, 05 Dec 2003 12:54:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASK96-0005qy-Na for xcon@optimus.ietf.org; Fri, 05 Dec 2003 12:53:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16119 for ; Fri, 5 Dec 2003 12:53:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ASK94-0006D5-00 for xcon@ietf.org; Fri, 05 Dec 2003 12:53:39 -0500 Received: from bzq-179-16-107.cust.bezeqint.net ([212.179.16.107] helo=accord-ntsrv3.accord.co.il) by ietf-mx with esmtp (Exim 4.12) id 1ASK94-0006Cm-00 for xcon@ietf.org; Fri, 05 Dec 2003 12:53:38 -0500 Received: by accord-ntsrv3.accord.co.il with Internet Mail Service (5.5.2656.59) id ; Fri, 5 Dec 2003 19:53:03 +0200 Message-ID: From: "Even, Roni" To: "'Orit Levin '" , "'hisham.khartabil@nokia.com '" , "'Brian.Rosen@marconi.com '" , "'xcon@ietf.org '" Subject: RE: [XCON] CPCP and Conference URIs - there are more than one! Date: Fri, 5 Dec 2003 19:53:02 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="ISO-8859-1" Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , Hi, I think that Brian's point is very important. As for the SIP conference package, I think that the information in the XCON CPCP may support many call setup protocols (SP, H.323, H.320, PSTN) but the SIP conferencing package should be for SIP addresses. Roni Even -----Original Message----- From: Orit Levin To: hisham.khartabil@nokia.com; Brian.Rosen@marconi.com; xcon@ietf.org Sent: 05/12/2003 01:26 Subject: RE: [XCON] CPCP and Conference URIs - there are more than one! Yes, a conference can have a list of URI identifiers and the CPCP needs to reflect it. My question is: Would we like to reflect this fact in the SIP Conference Package as well? (At least - as an optional structure :-) Orit. -----Original Message----- From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org] On Behalf Of hisham.khartabil@nokia.com Sent: Thursday, December 04, 2003 7:35 AM To: Brian.Rosen@marconi.com; xcon@ietf.org Subject: RE: [XCON] CPCP and Conference URIs - there are more than one! Brian, No argument there. We thought of that when we where creating the xcap based solution. The current solution can only hold a tel and a sip URI. We plan on changing this. Looks like a requirement needs to be added to the requirements document. Does the solution need to be future proof? or do we just allow listing the currently known protocols? Regards, Hisham > -----Original Message----- > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On Behalf Of ext > Rosen, Brian > Sent: 04.December.2003 16:48 > To: 'xcon@ietf.org' > Subject: [XCON] CPCP and Conference URIs - there are more than one! > > > The discussion of multiple ways to create conferences triggered a > discussion of XCON work being useable with multiple "using" (to borrow > a phrase from geopriv) protocols. > > We have been assuming that CPCP will, at one time or another, accept > or receive a conference uri, which has so far been thought of as a SIP > uri. This will not do. There has to be a LIST of conference URIs, > one for each using protocol the conference might support. > > There are already conference bridges that accept both SIP and H.323 > endpoints intermixed. The conference uri for the H.323 endpoints does > not start with "sip:" folks! > > There might even be a tel uri in there, right?!!! > Ooh, Ooh, sure would be nice if that tel uri could have the PIN. > Nah, over the top :) > > Brian > > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon > _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Mon Dec 8 15:24:18 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29416 for ; Mon, 8 Dec 2003 15:24:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATRvH-00035u-He for xcon-archive@odin.ietf.org; Mon, 08 Dec 2003 15:24:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB8KO3LE011895 for xcon-archive@odin.ietf.org; Mon, 8 Dec 2003 15:24:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATRvG-00035m-Up for xcon-web-archive@optimus.ietf.org; Mon, 08 Dec 2003 15:24:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29396 for ; Mon, 8 Dec 2003 15:23:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATRvF-0004Bl-00 for xcon-web-archive@ietf.org; Mon, 08 Dec 2003 15:24:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ATRvF-0004Bh-00 for xcon-web-archive@ietf.org; Mon, 08 Dec 2003 15:24:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATRvF-00035R-2u; Mon, 08 Dec 2003 15:24:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATRuj-00034Z-8D for xcon@optimus.ietf.org; Mon, 08 Dec 2003 15:23:29 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29304; Mon, 8 Dec 2003 15:23:13 -0500 (EST) Message-Id: <200312082023.PAA29304@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: xcon@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Mon, 08 Dec 2003 15:23:13 -0500 Subject: [XCON] I-D ACTION:draft-ietf-xcon-cpcp-reqs-00.txt Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Centralized Conferencing Working Group of the IETF. Title : Requirements for Conference Policy Control Protocol Author(s) : P. Koskelainen Filename : draft-ietf-xcon-cpcp-reqs-00.txt Pages : 16 Date : 2003-12-8 The conference policy server allows clients to manipulate and interact with the conference policy. One mechanism to manipulate the policy is to use conference policy control protocol (CPCP). This document gives the requirements for CPCP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-xcon-cpcp-reqs-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-xcon-cpcp-reqs-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-xcon-cpcp-reqs-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-12-8151928.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-xcon-cpcp-reqs-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-xcon-cpcp-reqs-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-12-8151928.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Tue Dec 9 20:00:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27264 for ; Tue, 9 Dec 2003 20:00:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATsi1-0002ul-0o for xcon-archive@odin.ietf.org; Tue, 09 Dec 2003 20:00:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBA1084N011197 for xcon-archive@odin.ietf.org; Tue, 9 Dec 2003 20:00:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATshz-0002uO-4M for xcon-web-archive@optimus.ietf.org; Tue, 09 Dec 2003 20:00:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27232 for ; Tue, 9 Dec 2003 19:59:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATshx-0005eg-00 for xcon-web-archive@ietf.org; Tue, 09 Dec 2003 20:00:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ATshw-0005eb-00 for xcon-web-archive@ietf.org; Tue, 09 Dec 2003 20:00:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATshw-0002u1-Ki; Tue, 09 Dec 2003 20:00:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATsh6-0002sn-6w for xcon@optimus.ietf.org; Tue, 09 Dec 2003 19:59:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27176 for ; Tue, 9 Dec 2003 19:58:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATsh4-0005cb-00 for xcon@ietf.org; Tue, 09 Dec 2003 19:59:10 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1ATsh3-0005bi-00 for xcon@ietf.org; Tue, 09 Dec 2003 19:59:09 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 10 Dec 2003 00:59:29 +0000 Received: from SCOTTF-W2K5.cisco.com (dhcp-128-107-141-144.cisco.com [128.107.141.144]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id hBA0wTiO014037; Tue, 9 Dec 2003 16:58:30 -0800 (PST) Message-Id: <4.3.1.2.20031209164248.01998078@VTG-UM-E2K1> X-Sender: nismail@VTG-UM-E2K1 X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Tue, 09 Dec 2003 17:00:51 -0800 To: "Rosen, Brian" From: Nermeen Ismail Subject: RE: [XCON] CPCP and resource allocation. (was: Chicken and Egg - Can CPCP create a conference) Cc: "'hisham.khartabil@nokia.com'" , xcon@ietf.org In-Reply-To: <313680C9A886D511A06000204840E1CF070B6177@whq-msgusr-02.pit .comms.marconi.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , Ok back to the hot seat. I agree that CPCP should allow conferences that have been scheduled in adavnce to be created. However that does not mean that CPCP should provide the inetrafce for resource allocation. I am not sure that resource allocation is a function of the conference server because: - The same DSP resources can be scheduled for mixing(conferencing) or for other types of services (e.g. transcoding). So really resource allocation is not a conferencing-specific function - I can not see the point of allocating a URI (be it SIP, SPIS, TEL, H.323) when really the conference is going to start in two weeks time. I prefer to separate the problem of resource allocation which can happen way in adavance and can cater for more than just mixing resources from the problem of allocating a conference URI and a conferenec policy that allows participants to join into the conference right now. I have understood CPCP to be targeting the latter and not the first. nermeen >Hurray, someone else on the hot seat. > >I agree with Hisham, and others, that schedule in advance is >a clear requirement we must support (existing systems do it), >it's not hard, and the resource allocation is local policy at the >conference service. The simplest way to get around time >zone issues is to simply have the schedule always be in GMT, >and leave it to the clients to deal with local conversion for display >purposes. > >Conference system vendors have coped with the scheduling problem for >years, and have sensible, albeit not foolproof heuristics to make >scheduled conferences work pretty well. The reality these days is >that calculating conference resources is already an inexact science, >and you don't really know if your DSP will run out of horsepower until >it does. Again, vendors often use heuristics and approximations to >give you a "port count". > >Brian > > > -----Original Message----- > > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > > Sent: Thursday, December 04, 2003 4:54 AM > > To: nismail@cisco.com; Brian.Rosen@marconi.com > > Cc: xcon@ietf.org > > Subject: RE: [XCON] Chicken and Egg - Can CPCP create a conference > > > > > > I can't believe people still think time zones are a problem. > > There are many time zone standards that can be used. The only > > requirement is that the client and the server need to > > implement the same one. That is hardly a show stopper. > > > > /Hisham > > > > > -----Original Message----- > > > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On > > Behalf Of ext > > > Nermeen Ismail > > > Sent: 04.December.2003 05:56 > > > To: Rosen, Brian > > > Cc: xcon@ietf.org > > > Subject: RE: [XCON] Chicken and Egg - Can CPCP create a conference > > > > > > > > > I have just seen this thread so I might be repeating what is > > > laredy been said. > > > > > > I agree that from the protocols point of view a conference is > > > a conference. > > > It does not matter if it is ad hoc or scheduled. It has a > > > unique URI, its > > > policy can be manipulated and authorized users can join/leave > > > them either > > > by dial-in or dial-out. > > > > > > My understanding for why there are two ways to create a > > > conference is to > > > support : > > > 1- Creating a conference and joining it without having to implement > > > anything other than SIP (cc-conferencing). In this case sending an > > > INVITE to the URI factory is sufficient. Off course if the > > > endpoint needs > > > to do something more like modifying the conference policy then > > > it needs to also implement CPCP/MPCP in which case it might > > > have just used > > > that to create the conference. However the point is still that an > > > application can create, join a conference and get the > > roster without > > > needing anything other than a SIP stack. > > > > > > 2- Creating a conference and never joining it. This is like > > > the case of a > > > scheduling automata that at the time of conference scheduling > > > it creates a > > > conference and a focus. In this case and as the application > > > will never send > > > or receive media to the conference it was deemed > > > inappropriate to demand > > > the application to have a SIP stack and send a no-media > > > INVITE to create > > > the conference. Hence some non-SIP method will be used to > > create the > > > conference. A non-sip method will be used to create the > > > conference (enters > > > CPCP) and this create-conference will be sent to the > > top-level policy > > > server URI which in return will send the conference URI and > > > the policy > > > server URI for that conference. The only benefot that this > > method has > > > over number 1 is that the application does not have to support SIP. > > > > > > So a conference server needs to have a SIP stack, CPCP/MPCP and the > > > conference package but a client might only have a SIP stack, > > > a CPCP/MPCP > > > implementation or both. > > > > > > On a separate topic, it was mentioned before that when a > > > conference is > > > created a future start time can be specified. I see lots of > > > complications > > > with that to do with time zones etc. Already the client that > > > created the > > > conference has to deal with that and I do not see any benefit > > > in extending > > > that to the conference server as well. So I see benefits in > > > specifying a > > > conference duration but no benefit in specifying conference > > > start time. > > > If the client creating the conference wishes the conference > > to start > > > accepting users in 5 minutes time then it needs to delay > > > sending the create > > > conference 5 minutes. > > > > > > > > > nermeen > > > > > > > > > > > > > > > > > > > > >We must stop talking about "ad-hoc conferences" and "scheduled > > > > > conferences" > > > > > >- there is no such thing. There are only ad-hoc mechanisms and > > > > > scheduled > > > > > >mechanisms to create/join a conference. > > > >Which, I think, is completely useless. > > > >And, to be specific: > > > > There is no difference in how you join a conference > > > > You always send an INVITE, or get a REFER, > > > > or receive an INVITE. You can't join with > > > > CPCP. > > > > There is no reason to have a difference to create one > > > > > > > > > > > > > > [Chris Boulton] I totally agree. Whether 'ad-hoc' or > > > > > 'scheduled' means > > > > > are used to create a conference should have no effect - a > > > conference > > > > > should be created and a default policy applied. Then, > > if it is an > > > > > 'ad-hoc' conference, a participant is free to join and > > if it is a > > > > > scheduled, the creator may manipulate the conference policy. > > > >Why is it different with ad-hoc that a participant is free to join? > > > >Why is it different with scheduled that the creator may manipulate > > > >the conference policy? > > > > > > > >I think there is no difference at all. No matter how you > > create it, > > > >participants are free to join any time the policy says they pay. > > > >No matter how you create it, the creator may manipulate the > > > conference > > > >policy (and participants may manipulate it also, subject to > > > permissions). > > > > > > > > > > > > > >So, if The Example Company already has their public web > > > server home > > > > > page at > > > > > >example.com where everyone goes to download the latest > > > examples, this > > > > > web > > > > > >server now needs to become the conference policy server? > > > >No, unless the example.com is also the focus host. If it > > > is, then the > > > >web server is there too. That is just not a limitation > > worth worrying > > > >about. > > > > > > > > > > > > > > > > > > > >There are significant disadvantages in limiting > > ourselves to such > > > > > >conventions - especially when there are other ways of > > > discovering the > > > > > >policy URI. One way that has been discussed is advertising > > > > > the policy > > > > > URI > > > > > >in conference package notifications. Is this not > > > sufficient? This > > > > > >approach is flexible and extensible (different protocols > > > for policy > > > > > >manipulation can be defined with a new URI scheme) and has > > > > > none of the > > > > > name > > > > > >space limitations of this proposal. > > > > > > > > > > [Chris Boulton] This approach does seem to 'shoe-horn' > > > the HTTP usage > > > > > and IMHO is quite an ugly solution. As Alan points out, > > > policy URI > > > > > contained in conference packages is a far more elegant solution. > > > > > > > > >My problem is that we seem to be heading to a solution where there > > > >is no subset of capabilities. To do anything, you need to > > implement: > > > > cc conference > > > >AND > > > > cpcp > > > >AND > > > > mpcp > > > >AND > > > > the conference package > > > > > > > >There are no simple implementations other than conference unaware. > > > >Is that really what we want to do? Intertwine all the > > pieces so that > > > >there is no clean functional separation that allows implementation > > > >flexibility without creating incompatibility? In this specific > > > >case, why do you have to implement the conference package in order > > > >to discover the conference policy uri? > > > > > > > >A message or two ago, Alan talked about automata > > > manipulating conference > > > >policy, and you were aghast that I proposed using SIP means to > > > >create a conference ID. You now want the automata to use SIP means > > > >to find a conference policy URI given a conference URI; they > > > even have > > > >to join the conference to do so, unless the automata created the > > > >conference in the first place, where it may get the > > conference policy > > > >uri returned to it). > > > > > > > >Can't we give up a slight amount of flexibility to get the > > > possibility > > > >of more widespread use of this facility by limiting implementation > > > >complexity? Maybe we need some use case stuff to see how > > > subsets might > > > >be useful. > > > > > > > > > > > >_______________________________________________ > > > >XCON mailing list > > > >XCON@ietf.org > > > >https://www1.ietf.org/mailman/listinfo/xcon > > > > > > > > > _______________________________________________ > > > XCON mailing list > > > XCON@ietf.org > > > https://www1.ietf.org/mailman/listinfo/xcon > > > > > _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Wed Dec 10 03:31:34 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04168 for ; Wed, 10 Dec 2003 03:31:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATzkP-0000Xb-So for xcon-archive@odin.ietf.org; Wed, 10 Dec 2003 03:31:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBA8V5xW002077 for xcon-archive@odin.ietf.org; Wed, 10 Dec 2003 03:31:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATzkO-0000XQ-Dg for xcon-web-archive@optimus.ietf.org; Wed, 10 Dec 2003 03:31:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04164 for ; Wed, 10 Dec 2003 03:31:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATzkM-0005fG-00 for xcon-web-archive@ietf.org; Wed, 10 Dec 2003 03:31:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ATzkL-0005fD-00 for xcon-web-archive@ietf.org; Wed, 10 Dec 2003 03:31:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATzkM-0000Wz-6w; Wed, 10 Dec 2003 03:31:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATzjg-0000Ua-5u for xcon@optimus.ietf.org; Wed, 10 Dec 2003 03:30:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04141 for ; Wed, 10 Dec 2003 03:30:18 -0500 (EST) From: aki.niemi@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATzjd-0005eq-00 for xcon@ietf.org; Wed, 10 Dec 2003 03:30:17 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1ATzjd-0005em-00 for xcon@ietf.org; Wed, 10 Dec 2003 03:30:17 -0500 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hBA8UG814403 for ; Wed, 10 Dec 2003 10:30:17 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 10 Dec 2003 10:28:27 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 10 Dec 2003 10:28:27 +0200 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 10 Dec 2003 10:28:26 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] Chicken and Egg - Can CPCP create a conference Date: Wed, 10 Dec 2003 10:28:26 +0200 Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD902D592FE@esebe013.ntc.nokia.com> Thread-Topic: [XCON] Chicken and Egg - Can CPCP create a conference Thread-Index: AcO5209o+fZpgKN/TGqWjYfbPaph6AAfvqKwAACSeyAALZ5R4AD43JxA To: , , Cc: X-OriginalArrivalTime: 10 Dec 2003 08:28:26.0840 (UTC) FILETIME=[9559DD80:01C3BEF7] Content-Transfer-Encoding: quoted-printable Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hisham wrote: > > > I don't like to couple these elements unnecessarily using any=20 > > > type of URI naming conventions. An equally possible setup is=20 > > > one where the policy server is in fact separate XCAP server,=20 > > > and both the conference participant and the focus are=20 > XCAP clients. > > >=20 > > > In any case, aren't we talking about simply passing on some=20 > > > information about the conference to its participants. So,=20 > > > have the focus return in a 200 OK to an INVITE: > > >=20 > > > Call-Info:=20 > > > > > icy12345.xml>;purpose=3Dxcap-cpcp > > >=20 > > > This lets the client know where to go and do XCAP CPCP if it=20 > > > wants to manipulate the policy. > >=20 > > This would work for participants who don't want to subscribe=20 > > to the conference event package. Carrying the policy ID in=20 > > the event package is also beneficial in that users can=20 > > manipulate the conference policy without having to actually=20 > > join the conference. They learn the policy ID using SUB/NOT=20 > > without having to send INVITE. > >=20 > > So I guess both methods are needed. >=20 >=20 > Where should these solutions be documented? in cc=20 > conferencing document in sipping? Perhaps, but I'm not the editor of that document so maybe we should take = this to the SIPPING mailing list? I would imagine that this might = involve defining a new Call-Info purpose token of "cpcp" or similar. = Otherwise it's really a walk in the park :)=20 Cheers, Aki >=20 >=20 > >=20 > > Regards, > > Hisham > >=20 > > >=20 > > > Cheers, > > > Aki > > >=20 > > >=20 > > >=20 > > > > > >=20 > > > _______________________________________________ > > > XCON mailing list > > > XCON@ietf.org > > > https://www1.ietf.org/mailman/listinfo/xcon > > >=20 > >=20 > > _______________________________________________ > > XCON mailing list > > XCON@ietf.org > > https://www1.ietf.org/mailman/listinfo/xcon > >=20 >=20 > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon >=20 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Wed Dec 10 06:01:36 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07149 for ; Wed, 10 Dec 2003 06:01:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AU25d-0005W6-CN for xcon-archive@odin.ietf.org; Wed, 10 Dec 2003 06:01:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBAB19ld021200 for xcon-archive@odin.ietf.org; Wed, 10 Dec 2003 06:01:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AU25d-0005Vr-6Z for xcon-web-archive@optimus.ietf.org; Wed, 10 Dec 2003 06:01:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07145 for ; Wed, 10 Dec 2003 06:01:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AU25Z-0007GT-00 for xcon-web-archive@ietf.org; Wed, 10 Dec 2003 06:01:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AU25Z-0007GQ-00 for xcon-web-archive@ietf.org; Wed, 10 Dec 2003 06:01:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AU25W-0005VN-JL; Wed, 10 Dec 2003 06:01:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AU25U-0005SU-Qj for xcon@optimus.ietf.org; Wed, 10 Dec 2003 06:01:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07133 for ; Wed, 10 Dec 2003 06:00:56 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AU25Q-0007GN-00 for xcon@ietf.org; Wed, 10 Dec 2003 06:00:56 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AU25Q-0007GK-00 for xcon@ietf.org; Wed, 10 Dec 2003 06:00:56 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hBAB0un04086 for ; Wed, 10 Dec 2003 13:00:56 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 10 Dec 2003 13:00:55 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 10 Dec 2003 13:00:54 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] CPCP and resource allocation. (was: Chicken and Egg - Can CPCP create a conference) Date: Wed, 10 Dec 2003 13:00:22 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7017974CB@esebe019.ntc.nokia.com> Thread-Topic: [XCON] CPCP and resource allocation. (was: Chicken and Egg - Can CPCP create a conference) Thread-Index: AcO+uL1CUFy9gfebQEyscdwgsy9IEwAUdQng To: , Cc: X-OriginalArrivalTime: 10 Dec 2003 11:00:54.0461 (UTC) FILETIME=[E1C20ED0:01C3BF0C] Content-Transfer-Encoding: quoted-printable Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable I don't think anyone was suggesting that as soon as a conference policy = is in place, the resources must be reserved. CPCP does not provide an = interface for resource allocation, but it does provide the scheduled = time for the conference. It is up to the conference host to read the = start and stop times for a conference and allocate resources using some = local intelligence. In my definitions, conference host and conference server are the same = thing. More comment inline... > -----Original Message----- > From: ext Nermeen Ismail [mailto:nismail@cisco.com] > Sent: 10.December.2003 03:01 > To: Rosen, Brian > Cc: Khartabil Hisham (NMP-MSW/Helsinki); xcon@ietf.org > Subject: RE: [XCON] CPCP and resource allocation. (was:=20 > Chicken and Egg > - Can CPCP create a conference) >=20 >=20 > Ok back to the hot seat. >=20 > I agree that CPCP should allow conferences that have been=20 > scheduled in=20 > adavnce to be created. However that does not mean that CPCP > should provide the inetrafce for resource allocation. >=20 > I am not sure that resource allocation is a function of the=20 > conference=20 > server because: > - The same DSP resources can be scheduled for=20 > mixing(conferencing) or for=20 > other types of services (e.g. transcoding). So really=20 > resource allocation=20 > is not a conferencing-specific function > - I can not see the point of allocating a URI (be it SIP,=20 > SPIS, TEL, H.323)=20 > when really the conference is going to start in two weeks=20 > time. I prefer to > separate the problem of resource allocation which can happen way in=20 > adavance and can cater for more than just mixing resources from the=20 > problem of allocating a conference URI and a conferenec=20 > policy that allows=20 > participants to join into the conference right now. I have=20 > understood CPCP=20 > to be targeting the latter and not the first. I don't quite understand what your saying here, but I'll comment anyway: = Assigning a conference URI is not assigning resources. It is merely = assigning an ID to that conference. It does not matter when that ID is = assigned as long as it is done before the conference starts. But I would = be done long enough to enable users to pass it around. Regards, Hisham >=20 > nermeen >=20 >=20 >=20 >=20 >=20 >=20 > >Hurray, someone else on the hot seat. > > > >I agree with Hisham, and others, that schedule in advance is > >a clear requirement we must support (existing systems do it), > >it's not hard, and the resource allocation is local policy at the > >conference service. The simplest way to get around time > >zone issues is to simply have the schedule always be in GMT, > >and leave it to the clients to deal with local conversion for display > >purposes. > > > >Conference system vendors have coped with the scheduling problem for > >years, and have sensible, albeit not foolproof heuristics to make > >scheduled conferences work pretty well. The reality these days is > >that calculating conference resources is already an inexact science, > >and you don't really know if your DSP will run out of=20 > horsepower until > >it does. Again, vendors often use heuristics and approximations to > >give you a "port count". > > > >Brian _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Wed Dec 10 10:18:30 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16048 for ; Wed, 10 Dec 2003 10:18:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AU66F-0006wq-6e for xcon-archive@odin.ietf.org; Wed, 10 Dec 2003 10:18:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBAFI393026704 for xcon-archive@odin.ietf.org; Wed, 10 Dec 2003 10:18:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AU66F-0006wd-0i for xcon-web-archive@optimus.ietf.org; Wed, 10 Dec 2003 10:18:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15996 for ; Wed, 10 Dec 2003 10:17:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AU66C-0003mW-00 for xcon-web-archive@ietf.org; Wed, 10 Dec 2003 10:18:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AU66C-0003mT-00 for xcon-web-archive@ietf.org; Wed, 10 Dec 2003 10:18:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AU66D-0006vr-EP; Wed, 10 Dec 2003 10:18:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AU65n-0006vJ-Te for xcon@optimus.ietf.org; Wed, 10 Dec 2003 10:17:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15935 for ; Wed, 10 Dec 2003 10:17:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AU65l-0003lf-00 for xcon@ietf.org; Wed, 10 Dec 2003 10:17:33 -0500 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 1AU65k-0003iN-00 for xcon@ietf.org; Wed, 10 Dec 2003 10:17:32 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA04700; Wed, 10 Dec 2003 10:16:49 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA13629; Wed, 10 Dec 2003 10:16:48 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Wed, 10 Dec 2003 10:16:47 -0500 Message-ID: <313680C9A886D511A06000204840E1CF070B61C6@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Nermeen Ismail'" Cc: "'hisham.khartabil@nokia.com'" , xcon@ietf.org Subject: RE: [XCON] CPCP and resource allocation. (was: Chicken and Egg - Can CPCP create a conference) Date: Wed, 10 Dec 2003 10:16:46 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , The kind of resources you are discussing are actually media resources, and thus really part of media policy, but there is no escaping the fact that a pre-established conference reserves some resources. So, scheduling a conference does some resource reservation. The resource reservation is a byproduct of the scheduled nature of the conference and the specific media (and other) resources that reservation may need. I don't see CPCP needing any specific capabilities for resource reservation, and an implementation may choose to not reserve any resources Except one -- the URI(s). When you schedule a conference, you get the conference URI (and, I guess, the conference policy URI and the media policy URI) right away. You need the conference uri to pass to participants in some circumstances (consider, for example, the calendar automaton that schedules a conference as a result of a calendar operation, and places the conference URI in the calendar for later use to create the connection for the user to the conference. There is no "later"; you have to get the URI upon scheduling it. You can also manipulate the conference policy and the media policy any time between creation and the end of the conference, so you need those also. To extend the example; you might reserve "ports" for all the people you invite to a conference. The calendar mechanisms usually have invitation mechanisms with accept/decline. The decline operation could result in decreasing the number of reserved "ports" in an intelligent implementation. Such operations would occur after scheduling and before the start of the conference. Brian > -----Original Message----- > From: Nermeen Ismail [mailto:nismail@cisco.com] > Sent: Tuesday, December 09, 2003 8:01 PM > To: Rosen, Brian > Cc: 'hisham.khartabil@nokia.com'; xcon@ietf.org > Subject: RE: [XCON] CPCP and resource allocation. (was: > Chicken and Egg > - Can CPCP create a conference) > > > Ok back to the hot seat. > > I agree that CPCP should allow conferences that have been > scheduled in > adavnce to be created. However that does not mean that CPCP > should provide the inetrafce for resource allocation. > > I am not sure that resource allocation is a function of the > conference > server because: > - The same DSP resources can be scheduled for > mixing(conferencing) or for > other types of services (e.g. transcoding). So really > resource allocation > is not a conferencing-specific function > - I can not see the point of allocating a URI (be it SIP, > SPIS, TEL, H.323) > when really the conference is going to start in two weeks > time. I prefer to > separate the problem of resource allocation which can happen way in > adavance and can cater for more than just mixing resources from the > problem of allocating a conference URI and a conferenec > policy that allows > participants to join into the conference right now. I have > understood CPCP > to be targeting the latter and not the first. > > nermeen > > > > > > > >Hurray, someone else on the hot seat. > > > >I agree with Hisham, and others, that schedule in advance is > >a clear requirement we must support (existing systems do it), > >it's not hard, and the resource allocation is local policy at the > >conference service. The simplest way to get around time > >zone issues is to simply have the schedule always be in GMT, > >and leave it to the clients to deal with local conversion for display > >purposes. > > > >Conference system vendors have coped with the scheduling problem for > >years, and have sensible, albeit not foolproof heuristics to make > >scheduled conferences work pretty well. The reality these days is > >that calculating conference resources is already an inexact science, > >and you don't really know if your DSP will run out of > horsepower until > >it does. Again, vendors often use heuristics and approximations to > >give you a "port count". > > > >Brian > > > > > -----Original Message----- > > > From: hisham.khartabil@nokia.com > [mailto:hisham.khartabil@nokia.com] > > > Sent: Thursday, December 04, 2003 4:54 AM > > > To: nismail@cisco.com; Brian.Rosen@marconi.com > > > Cc: xcon@ietf.org > > > Subject: RE: [XCON] Chicken and Egg - Can CPCP create a conference > > > > > > > > > I can't believe people still think time zones are a problem. > > > There are many time zone standards that can be used. The only > > > requirement is that the client and the server need to > > > implement the same one. That is hardly a show stopper. > > > > > > /Hisham > > > > > > > -----Original Message----- > > > > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On > > > Behalf Of ext > > > > Nermeen Ismail > > > > Sent: 04.December.2003 05:56 > > > > To: Rosen, Brian > > > > Cc: xcon@ietf.org > > > > Subject: RE: [XCON] Chicken and Egg - Can CPCP create a > conference > > > > > > > > > > > > I have just seen this thread so I might be repeating what is > > > > laredy been said. > > > > > > > > I agree that from the protocols point of view a conference is > > > > a conference. > > > > It does not matter if it is ad hoc or scheduled. It has a > > > > unique URI, its > > > > policy can be manipulated and authorized users can join/leave > > > > them either > > > > by dial-in or dial-out. > > > > > > > > My understanding for why there are two ways to create a > > > > conference is to > > > > support : > > > > 1- Creating a conference and joining it without having > to implement > > > > anything other than SIP (cc-conferencing). In this case > sending an > > > > INVITE to the URI factory is sufficient. Off course if the > > > > endpoint needs > > > > to do something more like modifying the conference policy then > > > > it needs to also implement CPCP/MPCP in which case it might > > > > have just used > > > > that to create the conference. However the point is > still that an > > > > application can create, join a conference and get the > > > roster without > > > > needing anything other than a SIP stack. > > > > > > > > 2- Creating a conference and never joining it. This is like > > > > the case of a > > > > scheduling automata that at the time of conference scheduling > > > > it creates a > > > > conference and a focus. In this case and as the application > > > > will never send > > > > or receive media to the conference it was deemed > > > > inappropriate to demand > > > > the application to have a SIP stack and send a no-media > > > > INVITE to create > > > > the conference. Hence some non-SIP method will be used to > > > create the > > > > conference. A non-sip method will be used to create the > > > > conference (enters > > > > CPCP) and this create-conference will be sent to the > > > top-level policy > > > > server URI which in return will send the conference URI and > > > > the policy > > > > server URI for that conference. The only benefot that this > > > method has > > > > over number 1 is that the application does not have to > support SIP. > > > > > > > > So a conference server needs to have a SIP stack, > CPCP/MPCP and the > > > > conference package but a client might only have a SIP stack, > > > > a CPCP/MPCP > > > > implementation or both. > > > > > > > > On a separate topic, it was mentioned before that when a > > > > conference is > > > > created a future start time can be specified. I see lots of > > > > complications > > > > with that to do with time zones etc. Already the client that > > > > created the > > > > conference has to deal with that and I do not see any benefit > > > > in extending > > > > that to the conference server as well. So I see benefits in > > > > specifying a > > > > conference duration but no benefit in specifying conference > > > > start time. > > > > If the client creating the conference wishes the conference > > > to start > > > > accepting users in 5 minutes time then it needs to delay > > > > sending the create > > > > conference 5 minutes. > > > > > > > > > > > > nermeen > > > > > > > > > > > > > > > > > > > > > > > > > > >We must stop talking about "ad-hoc conferences" > and "scheduled > > > > > > conferences" > > > > > > >- there is no such thing. There are only ad-hoc > mechanisms and > > > > > > scheduled > > > > > > >mechanisms to create/join a conference. > > > > >Which, I think, is completely useless. > > > > >And, to be specific: > > > > > There is no difference in how you join a conference > > > > > You always send an INVITE, or get a REFER, > > > > > or receive an INVITE. You > can't join with > > > > > CPCP. > > > > > There is no reason to have a difference to create one > > > > > > > > > > > > > > > > > [Chris Boulton] I totally agree. Whether 'ad-hoc' or > > > > > > 'scheduled' means > > > > > > are used to create a conference should have no effect - a > > > > conference > > > > > > should be created and a default policy applied. Then, > > > if it is an > > > > > > 'ad-hoc' conference, a participant is free to join and > > > if it is a > > > > > > scheduled, the creator may manipulate the conference policy. > > > > >Why is it different with ad-hoc that a participant is > free to join? > > > > >Why is it different with scheduled that the creator > may manipulate > > > > >the conference policy? > > > > > > > > > >I think there is no difference at all. No matter how you > > > create it, > > > > >participants are free to join any time the policy says > they pay. > > > > >No matter how you create it, the creator may manipulate the > > > > conference > > > > >policy (and participants may manipulate it also, subject to > > > > permissions). > > > > > > > > > > > > > > > > >So, if The Example Company already has their public web > > > > server home > > > > > > page at > > > > > > >example.com where everyone goes to download the latest > > > > examples, this > > > > > > web > > > > > > >server now needs to become the conference policy server? > > > > >No, unless the example.com is also the focus host. If it > > > > is, then the > > > > >web server is there too. That is just not a limitation > > > worth worrying > > > > >about. > > > > > > > > > > > > > > > > > > > > > > > >There are significant disadvantages in limiting > > > ourselves to such > > > > > > >conventions - especially when there are other ways of > > > > discovering the > > > > > > >policy URI. One way that has been discussed is advertising > > > > > > the policy > > > > > > URI > > > > > > >in conference package notifications. Is this not > > > > sufficient? This > > > > > > >approach is flexible and extensible (different protocols > > > > for policy > > > > > > >manipulation can be defined with a new URI scheme) and has > > > > > > none of the > > > > > > name > > > > > > >space limitations of this proposal. > > > > > > > > > > > > [Chris Boulton] This approach does seem to 'shoe-horn' > > > > the HTTP usage > > > > > > and IMHO is quite an ugly solution. As Alan points out, > > > > policy URI > > > > > > contained in conference packages is a far more > elegant solution. > > > > > > > > > > >My problem is that we seem to be heading to a solution > where there > > > > >is no subset of capabilities. To do anything, you need to > > > implement: > > > > > cc conference > > > > >AND > > > > > cpcp > > > > >AND > > > > > mpcp > > > > >AND > > > > > the conference package > > > > > > > > > >There are no simple implementations other than > conference unaware. > > > > >Is that really what we want to do? Intertwine all the > > > pieces so that > > > > >there is no clean functional separation that allows > implementation > > > > >flexibility without creating incompatibility? In this specific > > > > >case, why do you have to implement the conference > package in order > > > > >to discover the conference policy uri? > > > > > > > > > >A message or two ago, Alan talked about automata > > > > manipulating conference > > > > >policy, and you were aghast that I proposed using SIP means to > > > > >create a conference ID. You now want the automata to > use SIP means > > > > >to find a conference policy URI given a conference URI; they > > > > even have > > > > >to join the conference to do so, unless the automata > created the > > > > >conference in the first place, where it may get the > > > conference policy > > > > >uri returned to it). > > > > > > > > > >Can't we give up a slight amount of flexibility to get the > > > > possibility > > > > >of more widespread use of this facility by limiting > implementation > > > > >complexity? Maybe we need some use case stuff to see how > > > > subsets might > > > > >be useful. > > > > > > > > > > > > > > >_______________________________________________ > > > > >XCON mailing list > > > > >XCON@ietf.org > > > > >https://www1.ietf.org/mailman/listinfo/xcon > > > > > > > > > > > > _______________________________________________ > > > > XCON mailing list > > > > XCON@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/xcon > > > > > > > > _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Thu Dec 11 02:15:56 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20210 for ; Thu, 11 Dec 2003 02:15:56 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUL2m-0005q1-PS for xcon-archive@odin.ietf.org; Thu, 11 Dec 2003 02:15:28 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBB7FSFV022435 for xcon-archive@odin.ietf.org; Thu, 11 Dec 2003 02:15:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUL2l-0005pm-0u for xcon-web-archive@optimus.ietf.org; Thu, 11 Dec 2003 02:15:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20144 for ; Thu, 11 Dec 2003 02:15:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUL2b-0004cz-00 for xcon-web-archive@ietf.org; Thu, 11 Dec 2003 02:15:17 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AUL2b-0004cn-00 for xcon-web-archive@ietf.org; Thu, 11 Dec 2003 02:15:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUL2L-0005mi-Iw; Thu, 11 Dec 2003 02:15:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUL1d-0005ic-P7 for xcon@optimus.ietf.org; Thu, 11 Dec 2003 02:14:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20054 for ; Thu, 11 Dec 2003 02:14:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUL1Z-0004c0-00 for xcon@ietf.org; Thu, 11 Dec 2003 02:14:13 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1AUL1Y-0004bo-00 for xcon@ietf.org; Thu, 11 Dec 2003 02:14:12 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 11 Dec 2003 07:14:58 +0000 Received: from juheew2k (sjc-vpn4-65.cisco.com [10.21.80.65]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id hBB7DeiN022440 for ; Wed, 10 Dec 2003 23:13:41 -0800 (PST) Reply-To: From: "Juhee Garg \(juhee\)" To: Date: Wed, 10 Dec 2003 23:13:40 -0800 Message-ID: <6677B3346233B94EBB11C060935101202C6853@vtg-um-e2k1.sj21ad.cisco.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0000_01C3BF73.40732CA0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 Subject: [XCON] Questions/Comments on draft-koskelainen-xcon-xcap-cpcp-usage-01 Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0000_01C3BF73.40732CA0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Petri/Hisham, I have some questions/comments on draft-koskelainen-xcon-xcap-cpcp-usage-01. 1) What is the format of the response that you get back from the server in 200 OK, for a request to create a conference? Is it the entire CPCP document with the conference URI filled out? Or is it just the conference URI? If latter, what is the schema? 2) At what point is a CPCP request deemed to have been handled successfully - when the conference policy change is successfully made or when the action corresponding to the policy change is successfully made? For e.g. when a request is issued to the CPS to dial out to a participant, when does the CPS send back a 200 OK - when it has been able to successfully communicate the change to the focus or when the participant is successfully added to the conference? 3) XCAP doc says that an XCAP server should return a 405 to an HTTP POST to an XCAP URI, but the CPCP doc is using POST in several places. 4) Section 11.2 says that Conference-Info element is optional, but in the schema, it is not (minOccurs=1, which I think means that the element is mandatory). I am confused. 5) Similarly, Section 10 says that Conference-time is an optional element, but in the schema it is not (minOccurs=1). 6) The schema doesn't have values for minOccurs for a lot of elements. http://xml.coverpages.org/REC-xmlschema-1-20010502.html says that if minOccurs is not present, then its default value is 1, which in my mind means that those elements are mandatory. This is not consistent with the rest of the document. The schema needs to be consistent with the rest of the document. 7) I had brought this up in Minneapolis, but possibly in context of a wrong draft :( We need to have a way to specify when the conference should be ended (if these conditions occur before the conference time expires). This could have multiple token values like: a) When no participants are left (this is useful for an adhoc conference) b) When the owner of the conference leaves (this is useful for avoiding toll fraud kinda cases) c) When only two parties are left, convert it to a two-party call and end the conference. Thanks, Juhee ------=_NextPart_000_0000_01C3BF73.40732CA0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Petri/Hisham,
 
I have = some=20 questions/comments on=20 draft-koskelainen-xcon-xcap-cpcp-usage-01.
 
1) What is the format of the = response that=20 you get back from the server in 200 OK, = for a=20 request to create a conference? Is it the entire CPCP document with the=20 conference URI filled out? Or is it just the conference URI? If latter, = what is=20 the schema?
 
2) At = what point is=20 a CPCP request deemed to have been handled successfully - when the = conference=20 policy change is successfully made or when the action corresponding to = the=20 policy change is successfully made? For e.g. when a request is issued to = the CPS=20 to dial out to a participant, when does the CPS send back a 200 OK - = when it has=20 been able to successfully communicate the change to the focus or when = the=20 participant is successfully added to the conference?
 
3) XCAP=20 doc says that an XCAP server = should return a=20 405 to an HTTP POST to an = XCAP=20 URI, but the CPCP doc is = using=20 POST in several=20 places.
 
4)=20 Section 11.2 says that Conference-Info element is optional, but in the = schema,=20 it is not (minOccurs=3D1, which I think = means that=20 the element is mandatory). I am confused.
 
5) = Similarly,=20 Section 10 says that Conference-time is an optional element, but in the = schema=20 it is not (minOccurs=3D1).
 
6) The=20 schema doesn't have values for minOccurs for a lot of elements. = http://xml.coverpages.org/REC-xmlschema-1-20010502.html says that if minOccurs is not present, then its = default value=20 is 1, which in my mind means that those = elements=20 are mandatory. This is not consistent with the rest of the = document. The schema needs to be consistent with the = rest of the=20 document. 
 
7) I had=20 brought this up in Minneapolis, but possibly in context of a wrong draft = :( We=20 need to have a way to = specify when=20 the conference should be ended (if = these=20 conditions occur before the conference time expires). This could have multiple token values=20 like:
   =20 a) When no participants are left (this is useful for an adhoc=20 conference)
   =20 b) When the owner of the conference leaves (this is useful for avoiding = toll=20 fraud kinda cases)
   =20 c) When only two parties are left, convert it to a two-party call and = end the=20 conference.
 
Thanks,
Juhee
------=_NextPart_000_0000_01C3BF73.40732CA0-- _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Thu Dec 11 04:36:35 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23431 for ; Thu, 11 Dec 2003 04:36:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUNEt-0003Ze-DN for xcon-archive@odin.ietf.org; Thu, 11 Dec 2003 04:36:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBB9a7tx013735 for xcon-archive@odin.ietf.org; Thu, 11 Dec 2003 04:36:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUNEr-0003ZL-QM for xcon-web-archive@optimus.ietf.org; Thu, 11 Dec 2003 04:36:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23428 for ; Thu, 11 Dec 2003 04:36:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUNEn-0006dh-00 for xcon-web-archive@ietf.org; Thu, 11 Dec 2003 04:36:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AUNEn-0006de-00 for xcon-web-archive@ietf.org; Thu, 11 Dec 2003 04:36:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUNEo-0003Z0-O6; Thu, 11 Dec 2003 04:36:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUNEE-0003YQ-Ka for xcon@optimus.ietf.org; Thu, 11 Dec 2003 04:35:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23425 for ; Thu, 11 Dec 2003 04:35:23 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUNEA-0006da-00 for xcon@ietf.org; Thu, 11 Dec 2003 04:35:22 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AUNEA-0006dX-00 for xcon@ietf.org; Thu, 11 Dec 2003 04:35:22 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hBB9ZJQ27793 for ; Thu, 11 Dec 2003 11:35:19 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 11 Dec 2003 11:35:15 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 11 Dec 2003 11:35:15 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 11 Dec 2003 11:35:15 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3BFCA.009187BE" Subject: RE: [XCON] Questions/Comments on draft-koskelainen-xcon-xcap-cpcp-usage-01 Date: Thu, 11 Dec 2003 11:34:41 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB70118B137@esebe019.ntc.nokia.com> Thread-Topic: [XCON] Questions/Comments on draft-koskelainen-xcon-xcap-cpcp-usage-01 Thread-Index: AcO/ton3Rq5p44f4QbC84soeeZ8RiwAD9APA To: , X-OriginalArrivalTime: 11 Dec 2003 09:35:15.0484 (UTC) FILETIME=[151A25C0:01C3BFCA] Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C3BFCA.009187BE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Juhee, =20 Thanks for the comments. Reponses inline... -----Original Message----- From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On Behalf Of ext = Juhee Garg (juhee) Sent: 11.December.2003 09:14 To: xcon@ietf.org Subject: [XCON] Questions/Comments on = draft-koskelainen-xcon-xcap-cpcp-usage-01 Petri/Hisham, =20 I have some questions/comments on = draft-koskelainen-xcon-xcap-cpcp-usage-01. =20 1) What is the format of the response that you get back from the server = in 200 OK, for a request to create a conference? Is it the entire CPCP = document with the conference URI filled out? Or is it just the = conference URI? If latter, what is the schema?=20 =20 I'm not sure if this is an XCAP related issue of if every XCAP usage = needs to define such. RFC2616 was not clear of what goes in the 200 of a = PUT request. I'll ask on the SIMPLE mailing list. =20 2) At what point is a CPCP request deemed to have been handled = successfully - when the conference policy change is successfully made or = when the action corresponding to the policy change is successfully made? = For e.g. when a request is issued to the CPS to dial out to a = participant, when does the CPS send back a 200 OK - when it has been = able to successfully communicate the change to the focus or when the = participant is successfully added to the conference?=20 =20 I believe it is when the conference policy change is successful. You = will learn that the participant has joined using the conference state = event package.=20 =20 3) XCAP doc says that an XCAP server should return a 405 to an HTTP POST = to an XCAP URI, but the CPCP doc is using POST in several places.=20 =20 We used the previous version on XCAP to produce the current CPCP = document. That version allowed the use of POST. We need to modify CPCP = accordingly in the next revision.=20 =20 4) Section 11.2 says that Conference-Info element is optional, but in = the schema, it is not (minOccurs=3D1, which I think means that the = element is mandatory). I am confused.=20 =20 It is optional, we need to fix the schema.=20 =20 5) Similarly, Section 10 says that Conference-time is an optional = element, but in the schema it is not (minOccurs=3D1).=20 =20 It is mandatory. We need to fix the text.=20 =20 6) The schema doesn't have values for minOccurs for a lot of elements. = = http://xml.coverpages.org/REC-xmlschema-1-20010502.html says that if = minOccurs is not present, then its default value is 1, which in my mind = means that those elements are mandatory. This is not consistent with the = rest of the document. The schema needs to be consistent with the rest of = the document. =20 =20 Obviously we have failed to align the text with the schema. Apologies = for that. We will do a more thorough alignment in the next rev.=20 =20 7) I had brought this up in Minneapolis, but possibly in context of a = wrong draft :( We need to have a way to specify when the conference = should be ended (if these conditions occur before the conference time = expires). This could have multiple token values like:=20 =20 The conference ends when the stop-time is reached. If no stop time is = specified, then the conference ends when the last participant leaves. =20 a) When no participants are left (this is useful for an adhoc = conference) b) When the owner of the conference leaves (this is useful for = avoiding toll fraud kinda cases)=20 Can you be more elaborate here. What is the use case? =20 c) When only two parties are left, convert it to a two-party call = and end the conference. Are you proposing the the focus needs to behave as a 3pcc entity? Are = you also proposing the this should be configured using CPCP? =20 Thanks again for the comments, Hisham =20 Thanks, Juhee ------_=_NextPart_001_01C3BFCA.009187BE Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message
Juhee,
 
Thanks=20 for the comments. Reponses inline...
-----Original Message-----
From: = xcon-admin@ietf.org=20 [mailto:xcon-admin@ietf.org]On Behalf Of ext Juhee Garg=20 (juhee)
Sent: 11.December.2003 09:14
To:=20 xcon@ietf.org
Subject: [XCON] Questions/Comments on=20 draft-koskelainen-xcon-xcap-cpcp-usage-01

Petri/Hisham,
 
I = have some=20 questions/comments on=20 draft-koskelainen-xcon-xcap-cpcp-usage-01.
 
1) What is the format of the = response=20 that you get back from the server in 200 OK,=20 for a request to create a conference? Is it the entire CPCP document = with the=20 conference URI filled out? Or is it just the conference URI? If = latter, what=20 is the schema? 
 
I'm not sure if this = is an XCAP=20 related issue of if every XCAP usage needs to define such. RFC2616 was = not=20 clear of what goes in the 200 of a PUT request. I'll ask on the SIMPLE = mailing=20 list.
 
2) At what=20 point is a CPCP request deemed to have been handled successfully - = when the=20 conference policy change is successfully made or when the action = corresponding=20 to the policy change is successfully made?   For e.g. when a request is = issued to=20 the CPS to dial out to a participant, when does the CPS send back a = 200 OK -=20 when it has been able to successfully communicate the change to the = focus or=20 when the participant is successfully added to the conference? 
 
I believe it is when the = conference=20 policy change is successful. You will learn that the participant has = joined=20 using the conference state event=20 = package. 
 
3)=20 XCAP doc says that an XCAP = server should=20 return a 405 to an HTTP POST to an=20 XCAP URI, but the CPCP doc is using=20 POST in several = places. 
 
We used the previous version on XCAP to produce=20 the current CPCP document. That version allowed the use of = POST. We=20 need to modify CPCP accordingly in the=20 next revision. 
 
4)=20 Section 11.2 says that Conference-Info element is optional, but in the = schema,=20 it is not (minOccurs=3D1, which I = think means=20 that the element is mandatory). I am confused. 
 
It is optional, we = need to fix=20 the schema. 
 
5)=20 Similarly, Section 10 says that Conference-time is an optional = element, but in=20 the schema it is not (minOccurs=3D1). 
 
It is mandatory. We = need to fix=20 the text. 
 
6)=20 The schema doesn't have values for minOccurs for a lot of elements.=20 http://xml.coverpages.org/REC-xmlschema-1-20010502.html says that if minOccurs is not present, = then its=20 default value is 1, which in my mind = means that=20 those elements are mandatory. This is not consistent with the rest of = the=20 document. The schema needs to = be=20 consistent with the rest of the document.  
 
Obviously we have failed to align the text with the = schema.=20 Apologies for that. We will do a more thorough alignment in the next=20 rev. 
 
7) I had=20 brought this up in Minneapolis, but possibly in context of a wrong = draft :( We=20 need to have a way to = specify=20 when the conference should be ended = (if these=20 conditions occur before the conference time expires). This could have multiple token values = like: 
 
The conference ends = when the=20 stop-time is reached. If no stop time is specified, then the=20 conference ends when the last participant=20 leaves.
 
   =20 a) When no participants are left (this is useful for an adhoc=20 conference)
    b) When the owner of the conference leaves = (this is=20 useful for avoiding toll fraud kinda cases) 
Can you be more elaborate = here. What is=20 the use case?
 
   =20 c) When only two parties are left, convert it to a two-party call and = end the=20 conference.
Are you = proposing the=20 the focus needs to behave as a 3pcc entity? Are you also proposing the = this=20 should be configured using CPCP?
 
Thanks = again for the=20 comments,
Hisham
 
Thanks,
Juhee
<= /HTML> ------_=_NextPart_001_01C3BFCA.009187BE-- _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Thu Dec 11 14:46:31 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16915 for ; Thu, 11 Dec 2003 14:46:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUWl7-0005Ev-S1 for xcon-archive@odin.ietf.org; Thu, 11 Dec 2003 14:46:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBBJk138020135 for xcon-archive@odin.ietf.org; Thu, 11 Dec 2003 14:46:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUWl7-0005ET-Ml for xcon-web-archive@optimus.ietf.org; Thu, 11 Dec 2003 14:46:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16900 for ; Thu, 11 Dec 2003 14:45:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUWl4-0005pD-00 for xcon-web-archive@ietf.org; Thu, 11 Dec 2003 14:45:59 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AUWl4-0005pA-00 for xcon-web-archive@ietf.org; Thu, 11 Dec 2003 14:45:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUWl6-0005ED-JW; Thu, 11 Dec 2003 14:46:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUWks-0005DA-0C for xcon@optimus.ietf.org; Thu, 11 Dec 2003 14:45:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16887 for ; Thu, 11 Dec 2003 14:45:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUWkp-0005oX-00 for xcon@ietf.org; Thu, 11 Dec 2003 14:45:43 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AUWko-0005kx-00 for xcon@ietf.org; Thu, 11 Dec 2003 14:45:42 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 11 Dec 2003 11:47:34 +0000 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id hBBJjAZ0011543 for ; Thu, 11 Dec 2003 11:45:11 -0800 (PST) Received: from [128.107.171.228] ([128.107.171.228]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AKR27365; Thu, 11 Dec 2003 11:45:09 -0800 (PST) User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Thu, 11 Dec 2003 11:45:10 -0800 From: Cullen Jennings To: XCON-IETF Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [XCON] Use case for conferring Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Don't know who is collecting use cases these days - do we have an editor for them - but .... There is a conference with several audio break out sessions going on. At some point in the time, the moderator wants to record a message like "in 5 minutes, everyone please come back to the main meeting" then play that message to all of the breakout sessions. _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Thu Dec 11 16:23:32 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25788 for ; Thu, 11 Dec 2003 16:23:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUYH2-0001Dt-7I for xcon-archive@odin.ietf.org; Thu, 11 Dec 2003 16:23:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBBLN4Rm004697 for xcon-archive@odin.ietf.org; Thu, 11 Dec 2003 16:23:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUYH2-0001Dg-1U for xcon-web-archive@optimus.ietf.org; Thu, 11 Dec 2003 16:23:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25748 for ; Thu, 11 Dec 2003 16:23:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUYGz-0001am-00 for xcon-web-archive@ietf.org; Thu, 11 Dec 2003 16:23:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AUYGz-0001aT-00 for xcon-web-archive@ietf.org; Thu, 11 Dec 2003 16:23:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUYGz-0001DF-9V; Thu, 11 Dec 2003 16:23:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUYGG-0000yc-Me for xcon@optimus.ietf.org; Thu, 11 Dec 2003 16:22:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25586 for ; Thu, 11 Dec 2003 16:22:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUYGE-0001VQ-00 for xcon@ietf.org; Thu, 11 Dec 2003 16:22:14 -0500 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 1AUYGC-0001Ur-00 for xcon@ietf.org; Thu, 11 Dec 2003 16:22:13 -0500 Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id hBBLLOHQ016584; Thu, 11 Dec 2003 15:21:24 -0600 (CST) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Thu, 11 Dec 2003 15:21:24 -0600 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3E866D3@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'Henning Schulzrinne'" , hisham.khartabil@nokia.com Cc: Markus.Isomaki@nokia.com, xcon@ietf.org Subject: RE: [XCON] CPCP - making something simple that works Date: Thu, 11 Dec 2003 15:21:19 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , Henning Schulzrinne [mailto:hgs@cs.columbia.edu] writes: > > There is also the issue of expelling users. What is the opinion on > > that? Is it important? > > I have never seen that be used in real conferences, even where the > feature was available. [as not chair] I would argue that this is probably due more to the interfaces of current "real" conferences rather than people not wanting to make use of the feature. Navigating the list of participants to select one to eject is clunky at best over a DTMF interface -- and that's assuming one can recall the magic series of keystrokes to invoke the procedure in the first place. **SSSSSSSSSSSSSHHHSHSHSHHSH** "I think someone's cordless phone died. Does anyone remember how to kick someone off the bridge?" "I think it's star-eight-something." "No, that's on the Acme bridges. I think you hold down pound for a long time and then wait for the menu." **BEEEEEEEP** "Hmmm. That didn't work." As has been pointed out, in text environments (think IRC), removing people from a conference is used quite often. ("/kick offensive_user" has a good mnemonic value to it). Ease of use leads to use. [as chair] From a more immediate perspective, I sincerely hope that the protocol we develop is useful enough that it can be used with -- or at least interoperate with -- XMPP systems. Without an ejection function, there is no chance of either. /a _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Thu Dec 11 16:41:31 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27086 for ; Thu, 11 Dec 2003 16:41:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUYYR-0002W3-M4 for xcon-archive@odin.ietf.org; Thu, 11 Dec 2003 16:41:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBBLf3eP009648 for xcon-archive@odin.ietf.org; Thu, 11 Dec 2003 16:41:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUYYR-0002VX-BI for xcon-web-archive@optimus.ietf.org; Thu, 11 Dec 2003 16:41:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27051 for ; Thu, 11 Dec 2003 16:41:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUYYP-0002B0-00 for xcon-web-archive@ietf.org; Thu, 11 Dec 2003 16:41:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AUYYO-0002Ax-00 for xcon-web-archive@ietf.org; Thu, 11 Dec 2003 16:41:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUYYP-0002V6-Tf; Thu, 11 Dec 2003 16:41:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUYXl-0002QJ-FP for xcon@optimus.ietf.org; Thu, 11 Dec 2003 16:40:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27013 for ; Thu, 11 Dec 2003 16:40:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUYXj-00029K-00 for xcon@ietf.org; Thu, 11 Dec 2003 16:40:19 -0500 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 1AUYXj-00027p-00 for xcon@ietf.org; Thu, 11 Dec 2003 16:40:19 -0500 Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id hBBLdjHQ016646; Thu, 11 Dec 2003 15:39:45 -0600 (CST) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Thu, 11 Dec 2003 15:39:45 -0600 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3E866D4@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'petri.koskelainen@nokia.com'" , xcon@ietf.org Subject: RE: [XCON] CPCP requirements to support IMS Date: Thu, 11 Dec 2003 15:39:34 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , [as chair] petri.koskelainen@nokia.com [mailto:petri.koskelainen@nokia.com] wrote: > I'm a bit worried about media policy-CPCP integration > and WG schedule regarding it. > > Currently the charter says the following: > May 04 Submit Membership Manipulation Protocol for publication as PS > Jul 04 Submit Protocol for Media Topology Control for publication > > What I would like to have by May 04 is CPCP with the ability > to set up typical real-life conference, e.g. with audio codec X and > centralized mixer. ... > Current media policy seems to be extremely complex and the RFC goal > is not until July. > > Georg can probably comment on 3GPP schedules but in any case, > should we adopt simple media definition in CPCP itself (or divide > media policy into basic and advanced parts so basic media policy > could be ready by May 04)? Media policy was pushed to July precisely because it is more complex and (at this point, at least) more contentious. I fear that diverting resources to getting a bare-bones media policy out the door early will only cause significant delays to not just advanced media policy, but to all of our deliverables. That seems a steep price to pay for a two-month advance on publication. Hopefully, by the time the membership manipulation document is ready for publication, the media policy draft will be stable enough to give you a basis to start implementation. What is important to keep in mind is that we are not performing these tasks serially. The documents should develop pretty much in parallel. /a _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Thu Dec 11 23:25:31 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA10850 for ; Thu, 11 Dec 2003 23:25:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUerP-0004im-Mp for xcon-archive@odin.ietf.org; Thu, 11 Dec 2003 23:25:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBC4P3Xa018142 for xcon-archive@odin.ietf.org; Thu, 11 Dec 2003 23:25:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUerO-0004iH-Q2 for xcon-web-archive@optimus.ietf.org; Thu, 11 Dec 2003 23:25:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA10843 for ; Thu, 11 Dec 2003 23:24:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUerM-0002nm-00 for xcon-web-archive@ietf.org; Thu, 11 Dec 2003 23:25:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AUerM-0002nj-00 for xcon-web-archive@ietf.org; Thu, 11 Dec 2003 23:25:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUerN-0004hV-1Q; Thu, 11 Dec 2003 23:25:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUeqa-0004gm-Gd for xcon@optimus.ietf.org; Thu, 11 Dec 2003 23:24:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA10830 for ; Thu, 11 Dec 2003 23:24:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUeqY-0002nR-00 for xcon@ietf.org; Thu, 11 Dec 2003 23:24:10 -0500 Received: from goalie.snowshore.com ([216.57.133.4] helo=webshield.office.snowshore.com) by ietf-mx with smtp (Exim 4.12) id 1AUeqX-0002mp-00 for xcon@ietf.org; Thu, 11 Dec 2003 23:24:09 -0500 Received: from zoe.office.snowshore.com(192.168.1.172) by webshield.office.snowshore.com via csmap id 6334; Thu, 11 Dec 2003 23:28:40 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] CPCP and resource allocation. (was: Chicken and Egg - Can CPCP create a conference) Date: Thu, 11 Dec 2003 23:23:37 -0500 Message-ID: <4A3384433CE2AB46A63468CB207E209DB19FF3@zoe.office.snowshore.com> Thread-Topic: [XCON] CPCP and resource allocation. (was: Chicken and Egg - Can CPCP create a conference) Thread-Index: AcO/MNISmW1Vt9FjQw+HFwTpX9Ia0gA4PV2Q From: "Eric Burger" To: "Rosen, Brian" , "Nermeen Ismail" Cc: Content-Transfer-Encoding: quoted-printable Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable I, too, get to agree with Brian :-) On the issue of creating the conference/policy/etc URI family: If we do = not do that, what are we doing with CPCP, anyway? What we would be = saying is, "Use this protocol to schedule a conference. When you do = that, nothing happens. Don't worry -- that is by design." That does = not make much sense! I fully agree that media resource allocation is independent of a = conference scheduling protocol. Let me also propose that it is OUT OF SCOPE for what has been described = as "media policy." Media policy is about who gets to talk to whom NOW. = Resource allocation is about manipulating resources, in this case at the = DSP or media server level. That is another, yet solved, problem. [A nit is that the conference server/media server interface is out of = scope for XCON.] > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > Sent: Wed, December 10, 2003 10:17 AM > To: 'Nermeen Ismail' > Cc: 'hisham.khartabil@nokia.com'; xcon@ietf.org > Subject: RE: [XCON] CPCP and resource allocation. (was:=20 > Chicken and Egg > - Can CPCP create a conference) >=20 >=20 > The kind of resources you are discussing are actually media resources, > and thus really part of media policy, but there is no escaping the > fact that a pre-established conference reserves some resources. > So, scheduling a conference does some resource reservation. The > resource reservation is a byproduct of the scheduled nature of > the conference and the specific media (and other) resources that > reservation may need. I don't see CPCP needing any specific > capabilities for resource reservation, and an implementation may > choose to not reserve any resources >=20 > Except one -- the URI(s). >=20 > When you schedule a conference, you get the conference URI (and, > I guess, the conference policy URI and the media policy URI) right > away. You need the conference uri to pass to participants in some > circumstances (consider, for example, the calendar automaton that > schedules a conference as a result of a calendar operation, and > places the conference URI in the calendar for later use to create > the connection for the user to the conference. There is no "later"; > you have to get the URI upon scheduling it. >=20 > You can also manipulate the conference policy and the media policy > any time between creation and the end of the conference, so you > need those also. To extend the example; you might reserve "ports" > for all the people you invite to a conference. The calendar=20 > mechanisms > usually have invitation mechanisms with accept/decline. The decline > operation could result in decreasing the number of reserved "ports" > in an intelligent implementation. Such operations would occur=20 > after scheduling and before the start of the conference. >=20 > Brian >=20 > > -----Original Message----- > > From: Nermeen Ismail [mailto:nismail@cisco.com] > > Sent: Tuesday, December 09, 2003 8:01 PM > > To: Rosen, Brian > > Cc: 'hisham.khartabil@nokia.com'; xcon@ietf.org > > Subject: RE: [XCON] CPCP and resource allocation. (was:=20 > > Chicken and Egg > > - Can CPCP create a conference) > >=20 > >=20 > > Ok back to the hot seat. > >=20 > > I agree that CPCP should allow conferences that have been=20 > > scheduled in=20 > > adavnce to be created. However that does not mean that CPCP > > should provide the inetrafce for resource allocation. > >=20 > > I am not sure that resource allocation is a function of the=20 > > conference=20 > > server because: > > - The same DSP resources can be scheduled for=20 > > mixing(conferencing) or for=20 > > other types of services (e.g. transcoding). So really=20 > > resource allocation=20 > > is not a conferencing-specific function > > - I can not see the point of allocating a URI (be it SIP,=20 > > SPIS, TEL, H.323)=20 > > when really the conference is going to start in two weeks=20 > > time. I prefer to > > separate the problem of resource allocation which can happen way in=20 > > adavance and can cater for more than just mixing resources =20 > from the=20 > > problem of allocating a conference URI and a conferenec=20 > > policy that allows=20 > > participants to join into the conference right now. I have=20 > > understood CPCP=20 > > to be targeting the latter and not the first. > >=20 > > nermeen > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > > >Hurray, someone else on the hot seat. > > > > > >I agree with Hisham, and others, that schedule in advance is > > >a clear requirement we must support (existing systems do it), > > >it's not hard, and the resource allocation is local policy at the > > >conference service. The simplest way to get around time > > >zone issues is to simply have the schedule always be in GMT, > > >and leave it to the clients to deal with local conversion=20 > for display > > >purposes. > > > > > >Conference system vendors have coped with the scheduling=20 > problem for > > >years, and have sensible, albeit not foolproof heuristics to make > > >scheduled conferences work pretty well. The reality these days is > > >that calculating conference resources is already an=20 > inexact science, > > >and you don't really know if your DSP will run out of=20 > > horsepower until > > >it does. Again, vendors often use heuristics and approximations to > > >give you a "port count". > > > > > >Brian > > > > > > > -----Original Message----- > > > > From: hisham.khartabil@nokia.com=20 > > [mailto:hisham.khartabil@nokia.com] > > > > Sent: Thursday, December 04, 2003 4:54 AM > > > > To: nismail@cisco.com; Brian.Rosen@marconi.com > > > > Cc: xcon@ietf.org > > > > Subject: RE: [XCON] Chicken and Egg - Can CPCP create a=20 > conference > > > > > > > > > > > > I can't believe people still think time zones are a problem. > > > > There are many time zone standards that can be used. The only > > > > requirement is that the client and the server need to > > > > implement the same one. That is hardly a show stopper. > > > > > > > > /Hisham > > > > > > > > > -----Original Message----- > > > > > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On > > > > Behalf Of ext > > > > > Nermeen Ismail > > > > > Sent: 04.December.2003 05:56 > > > > > To: Rosen, Brian > > > > > Cc: xcon@ietf.org > > > > > Subject: RE: [XCON] Chicken and Egg - Can CPCP create a=20 > > conference > > > > > > > > > > > > > > > I have just seen this thread so I might be repeating what is > > > > > laredy been said. > > > > > > > > > > I agree that from the protocols point of view a conference is > > > > > a conference. > > > > > It does not matter if it is ad hoc or scheduled. It has a > > > > > unique URI, its > > > > > policy can be manipulated and authorized users can join/leave > > > > > them either > > > > > by dial-in or dial-out. > > > > > > > > > > My understanding for why there are two ways to create a > > > > > conference is to > > > > > support : > > > > > 1- Creating a conference and joining it without having=20 > > to implement > > > > > anything other than SIP (cc-conferencing). In this case=20 > > sending an > > > > > INVITE to the URI factory is sufficient. Off course if the > > > > > endpoint needs > > > > > to do something more like modifying the conference policy then > > > > > it needs to also implement CPCP/MPCP in which case it might > > > > > have just used > > > > > that to create the conference. However the point is=20 > > still that an > > > > > application can create, join a conference and get the > > > > roster without > > > > > needing anything other than a SIP stack. > > > > > > > > > > 2- Creating a conference and never joining it. This is like > > > > > the case of a > > > > > scheduling automata that at the time of conference scheduling > > > > > it creates a > > > > > conference and a focus. In this case and as the application > > > > > will never send > > > > > or receive media to the conference it was deemed > > > > > inappropriate to demand > > > > > the application to have a SIP stack and send a no-media > > > > > INVITE to create > > > > > the conference. Hence some non-SIP method will be used to > > > > create the > > > > > conference. A non-sip method will be used to create the > > > > > conference (enters > > > > > CPCP) and this create-conference will be sent to the > > > > top-level policy > > > > > server URI which in return will send the conference URI and > > > > > the policy > > > > > server URI for that conference. The only benefot that this > > > > method has > > > > > over number 1 is that the application does not have to=20 > > support SIP. > > > > > > > > > > So a conference server needs to have a SIP stack,=20 > > CPCP/MPCP and the > > > > > conference package but a client might only have a SIP stack, > > > > > a CPCP/MPCP > > > > > implementation or both. > > > > > > > > > > On a separate topic, it was mentioned before that when a > > > > > conference is > > > > > created a future start time can be specified. I see lots of > > > > > complications > > > > > with that to do with time zones etc. Already the client that > > > > > created the > > > > > conference has to deal with that and I do not see any benefit > > > > > in extending > > > > > that to the conference server as well. So I see benefits in > > > > > specifying a > > > > > conference duration but no benefit in specifying conference > > > > > start time. > > > > > If the client creating the conference wishes the conference > > > > to start > > > > > accepting users in 5 minutes time then it needs to delay > > > > > sending the create > > > > > conference 5 minutes. > > > > > > > > > > > > > > > nermeen > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >We must stop talking about "ad-hoc conferences"=20 > > and "scheduled > > > > > > > conferences" > > > > > > > >- there is no such thing. There are only ad-hoc=20 > > mechanisms and > > > > > > > scheduled > > > > > > > >mechanisms to create/join a conference. > > > > > >Which, I think, is completely useless. > > > > > >And, to be specific: > > > > > > There is no difference in how you join a conference > > > > > > You always send an INVITE, or get a REFER, > > > > > > or receive an INVITE. You=20 > > can't join with > > > > > > CPCP. > > > > > > There is no reason to have a difference to=20 > create one > > > > > > > > > > > > > > > > > > > > [Chris Boulton] I totally agree. Whether 'ad-hoc' or > > > > > > > 'scheduled' means > > > > > > > are used to create a conference should have no effect - a > > > > > conference > > > > > > > should be created and a default policy applied. Then, > > > > if it is an > > > > > > > 'ad-hoc' conference, a participant is free to join and > > > > if it is a > > > > > > > scheduled, the creator may manipulate the=20 > conference policy. > > > > > >Why is it different with ad-hoc that a participant is=20 > > free to join? > > > > > >Why is it different with scheduled that the creator=20 > > may manipulate > > > > > >the conference policy? > > > > > > > > > > > >I think there is no difference at all. No matter how you > > > > create it, > > > > > >participants are free to join any time the policy says=20 > > they pay. > > > > > >No matter how you create it, the creator may manipulate the > > > > > conference > > > > > >policy (and participants may manipulate it also, subject to > > > > > permissions). > > > > > > > > > > > > > > > > > > > >So, if The Example Company already has their public web > > > > > server home > > > > > > > page at > > > > > > > >example.com where everyone goes to download the latest > > > > > examples, this > > > > > > > web > > > > > > > >server now needs to become the conference policy server? > > > > > >No, unless the example.com is also the focus host. If it > > > > > is, then the > > > > > >web server is there too. That is just not a limitation > > > > worth worrying > > > > > >about. > > > > > > > > > > > > > > > > > > > > > > > > > > > >There are significant disadvantages in limiting > > > > ourselves to such > > > > > > > >conventions - especially when there are other ways of > > > > > discovering the > > > > > > > >policy URI. One way that has been discussed is=20 > advertising > > > > > > > the policy > > > > > > > URI > > > > > > > >in conference package notifications. Is this not > > > > > sufficient? This > > > > > > > >approach is flexible and extensible (different protocols > > > > > for policy > > > > > > > >manipulation can be defined with a new URI=20 > scheme) and has > > > > > > > none of the > > > > > > > name > > > > > > > >space limitations of this proposal. > > > > > > > > > > > > > > [Chris Boulton] This approach does seem to 'shoe-horn' > > > > > the HTTP usage > > > > > > > and IMHO is quite an ugly solution. As Alan points out, > > > > > policy URI > > > > > > > contained in conference packages is a far more=20 > > elegant solution. > > > > > > > > > > > > >My problem is that we seem to be heading to a solution=20 > > where there > > > > > >is no subset of capabilities. To do anything, you need to > > > > implement: > > > > > > cc conference > > > > > >AND > > > > > > cpcp > > > > > >AND > > > > > > mpcp > > > > > >AND > > > > > > the conference package > > > > > > > > > > > >There are no simple implementations other than=20 > > conference unaware. > > > > > >Is that really what we want to do? Intertwine all the > > > > pieces so that > > > > > >there is no clean functional separation that allows=20 > > implementation > > > > > >flexibility without creating incompatibility? In=20 > this specific > > > > > >case, why do you have to implement the conference=20 > > package in order > > > > > >to discover the conference policy uri? > > > > > > > > > > > >A message or two ago, Alan talked about automata > > > > > manipulating conference > > > > > >policy, and you were aghast that I proposed using=20 > SIP means to > > > > > >create a conference ID. You now want the automata to=20 > > use SIP means > > > > > >to find a conference policy URI given a conference URI; they > > > > > even have > > > > > >to join the conference to do so, unless the automata=20 > > created the > > > > > >conference in the first place, where it may get the > > > > conference policy > > > > > >uri returned to it). > > > > > > > > > > > >Can't we give up a slight amount of flexibility to get the > > > > > possibility > > > > > >of more widespread use of this facility by limiting=20 > > implementation > > > > > >complexity? Maybe we need some use case stuff to see how > > > > > subsets might > > > > > >be useful. > > > > > > > > > > > > > > > > > >_______________________________________________ > > > > > >XCON mailing list > > > > > >XCON@ietf.org > > > > > >https://www1.ietf.org/mailman/listinfo/xcon > > > > > > > > > > > > > > > _______________________________________________ > > > > > XCON mailing list > > > > > XCON@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/xcon > > > > > > > > > > >=20 >=20 > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon >=20 >=20 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Thu Dec 11 23:25:31 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA10854 for ; Thu, 11 Dec 2003 23:25:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUerP-0004iX-Jt for xcon-archive@odin.ietf.org; Thu, 11 Dec 2003 23:25:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBC4P3Ki018127 for xcon-archive@odin.ietf.org; Thu, 11 Dec 2003 23:25:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUerP-0004iI-CJ for xcon-web-archive@optimus.ietf.org; Thu, 11 Dec 2003 23:25:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA10846 for ; Thu, 11 Dec 2003 23:25:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUerN-0002ns-00 for xcon-web-archive@ietf.org; Thu, 11 Dec 2003 23:25:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AUerN-0002np-00 for xcon-web-archive@ietf.org; Thu, 11 Dec 2003 23:25:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUerO-0004i1-E1; Thu, 11 Dec 2003 23:25:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUeqb-0004gn-18 for xcon@optimus.ietf.org; Thu, 11 Dec 2003 23:24:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA10833 for ; Thu, 11 Dec 2003 23:24:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUeqZ-0002nW-00 for xcon@ietf.org; Thu, 11 Dec 2003 23:24:11 -0500 Received: from goalie.snowshore.com ([216.57.133.4] helo=webshield.office.snowshore.com) by ietf-mx with smtp (Exim 4.12) id 1AUeqY-0002mp-00 for xcon@ietf.org; Thu, 11 Dec 2003 23:24:10 -0500 Received: from zoe.office.snowshore.com(192.168.1.172) by webshield.office.snowshore.com via csmap id 6334; Thu, 11 Dec 2003 23:28:41 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] CPCP and Conference URIs - there are more than one! Date: Thu, 11 Dec 2003 23:23:37 -0500 Message-ID: <4A3384433CE2AB46A63468CB207E209DB19FF4@zoe.office.snowshore.com> Thread-Topic: [XCON] CPCP and Conference URIs - there are more than one! Thread-Index: AcO7WMndAt1QJz/iQRC7zCRfA18SoQEuaDZg From: "Eric Burger" To: "Even, Roni" Cc: Content-Transfer-Encoding: quoted-printable Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Would I be interpreting this statement correctly "but the SIP conferencing package should be for SIP addresses" to mean that the SIP conferencing package only includes SIP stuff? Consider a multi-protocol conference bridge that has four users. A, B, = and C use SIP while D uses H.323. A, B, and C subscribe to the SIP conferencing package, being conference = aware. Do they know about D? D does not have a SIP address. What D does have is a URL. I would propose that if anything changes, it is that the packages (and = XCON, too) just refer to URI's. We should not place any restriction on = URI scheme. They are opaque objects. > -----Original Message----- > From: Even, Roni [mailto:roni.even@polycom.co.il] > Sent: Fri, December 05, 2003 12:53 PM > To: 'Orit Levin '; 'hisham.khartabil@nokia.com '; > 'Brian.Rosen@marconi.com '; 'xcon@ietf.org ' > Subject: RE: [XCON] CPCP and Conference URIs - there are more=20 > than one! >=20 >=20 > Hi, > I think that Brian's point is very important. As for the SIP=20 > conference > package, I think that the information in the XCON CPCP may=20 > support many call > setup protocols (SP, H.323, H.320, PSTN) but the SIP=20 > conferencing package > should be for SIP addresses. > Roni Even=20 >=20 > -----Original Message----- > From: Orit Levin > To: hisham.khartabil@nokia.com; Brian.Rosen@marconi.com; xcon@ietf.org > Sent: 05/12/2003 01:26 > Subject: RE: [XCON] CPCP and Conference URIs - there are more=20 > than one! >=20 > Yes, a conference can have a list of URI identifiers and the=20 > CPCP needs > to reflect it. >=20 > My question is: Would we like to reflect this fact in the SIP=20 > Conference > Package as well? (At least - as an optional structure :-) >=20 > Orit.=20 >=20 > -----Original Message----- > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org] On Behalf Of > hisham.khartabil@nokia.com > Sent: Thursday, December 04, 2003 7:35 AM > To: Brian.Rosen@marconi.com; xcon@ietf.org > Subject: RE: [XCON] CPCP and Conference URIs - there are more=20 > than one! >=20 > Brian, >=20 > No argument there. We thought of that when we where creating the xcap > based solution. The current solution can only hold a tel and=20 > a sip URI. > We plan on changing this. >=20 > Looks like a requirement needs to be added to the=20 > requirements document. > Does the solution need to be future proof? or do we just allow listing > the currently known protocols? >=20 > Regards, > Hisham >=20 > > -----Original Message----- > > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On=20 > Behalf Of ext >=20 > > Rosen, Brian > > Sent: 04.December.2003 16:48 > > To: 'xcon@ietf.org' > > Subject: [XCON] CPCP and Conference URIs - there are more than one! > >=20 > >=20 > > The discussion of multiple ways to create conferences triggered a=20 > > discussion of XCON work being useable with multiple "using"=20 > (to borrow >=20 > > a phrase from geopriv) protocols. > >=20 > > We have been assuming that CPCP will, at one time or=20 > another, accept=20 > > or receive a conference uri, which has so far been thought=20 > of as a SIP >=20 > > uri. This will not do. There has to be a LIST of conference URIs,=20 > > one for each using protocol the conference might support. > >=20 > > There are already conference bridges that accept both SIP and H.323=20 > > endpoints intermixed. The conference uri for the H.323=20 > endpoints does >=20 > > not start with "sip:" folks! > >=20 > > There might even be a tel uri in there, right?!!! > > Ooh, Ooh, sure would be nice if that tel uri could have the PIN. > > Nah, over the top :) > >=20 > > Brian > >=20 > > _______________________________________________ > > XCON mailing list > > XCON@ietf.org > > https://www1.ietf.org/mailman/listinfo/xcon > >=20 >=20 > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon >=20 >=20 >=20 > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon >=20 > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon >=20 >=20 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Fri Dec 12 03:51:36 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01435 for ; Fri, 12 Dec 2003 03:51:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUj0s-0007uW-Eh for xcon-archive@odin.ietf.org; Fri, 12 Dec 2003 03:51:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBC8p6mb030402 for xcon-archive@odin.ietf.org; Fri, 12 Dec 2003 03:51:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUj0p-0007uH-L0 for xcon-web-archive@optimus.ietf.org; Fri, 12 Dec 2003 03:51:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01418 for ; Fri, 12 Dec 2003 03:51:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUj0n-0007i6-00 for xcon-web-archive@ietf.org; Fri, 12 Dec 2003 03:51:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AUj0m-0007i3-00 for xcon-web-archive@ietf.org; Fri, 12 Dec 2003 03:51:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUj0n-0007td-Om; Fri, 12 Dec 2003 03:51:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUizr-0007sb-Tw for xcon@optimus.ietf.org; Fri, 12 Dec 2003 03:50:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01397 for ; Fri, 12 Dec 2003 03:50:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUizp-0007gr-00 for xcon@ietf.org; Fri, 12 Dec 2003 03:50:01 -0500 Received: from 212.199.61.2.forward.012.net.il ([212.199.61.2] helo=accord-mail.accord.co.il) by ietf-mx with esmtp (Exim 4.12) id 1AUizo-0007ft-00 for xcon@ietf.org; Fri, 12 Dec 2003 03:50:00 -0500 Received: by accord-mail.accord.co.il with Internet Mail Service (5.5.2653.19) id ; Fri, 12 Dec 2003 10:49:35 +0200 Message-ID: From: "Even, Roni" To: "'Cullen Jennings '" , "'XCON-IETF '" Subject: RE: [XCON] Use case for conferring Date: Fri, 12 Dec 2003 10:49:28 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , Cullen, I am doing it, will add. You also suggested to supply a text conference scenario. Regards Roni Even Polycom -----Original Message----- From: Cullen Jennings To: XCON-IETF Sent: 11/12/2003 21:45 Subject: [XCON] Use case for conferring Don't know who is collecting use cases these days - do we have an editor for them - but .... There is a conference with several audio break out sessions going on. At some point in the time, the moderator wants to record a message like "in 5 minutes, everyone please come back to the main meeting" then play that message to all of the breakout sessions. _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Fri Dec 12 09:32:29 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09248 for ; Fri, 12 Dec 2003 09:32:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUoKo-0004Vz-BU for xcon-archive@odin.ietf.org; Fri, 12 Dec 2003 09:32:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBCEW26h017354 for xcon-archive@odin.ietf.org; Fri, 12 Dec 2003 09:32:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUoKo-0004Vp-6a for xcon-web-archive@optimus.ietf.org; Fri, 12 Dec 2003 09:32:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09240 for ; Fri, 12 Dec 2003 09:31:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUoKm-000613-00 for xcon-web-archive@ietf.org; Fri, 12 Dec 2003 09:32:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AUoKm-00060z-00 for xcon-web-archive@ietf.org; Fri, 12 Dec 2003 09:32:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUoKn-0004VD-3k; Fri, 12 Dec 2003 09:32:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUoKX-0004UV-Tv for xcon@optimus.ietf.org; Fri, 12 Dec 2003 09:31:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09214 for ; Fri, 12 Dec 2003 09:31:42 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUoKW-000609-00 for xcon@ietf.org; Fri, 12 Dec 2003 09:31:44 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AUoKV-000606-00 for xcon@ietf.org; Fri, 12 Dec 2003 09:31:43 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hBCEVgn24966 for ; Fri, 12 Dec 2003 16:31:42 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 12 Dec 2003 16:31:39 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 12 Dec 2003 16:31:38 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] CPCP requirements to support IMS X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Fri, 12 Dec 2003 16:31:38 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB70118B13C@esebe019.ntc.nokia.com> Thread-Topic: [XCON] CPCP requirements to support IMS Thread-Index: AcPAL38YEqFS9+kZRk2MQEOFch7dywAjIM9Q To: , , X-OriginalArrivalTime: 12 Dec 2003 14:31:38.0955 (UTC) FILETIME=[A74A39B0:01C3C0BC] Content-Transfer-Encoding: quoted-printable Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable The issue I have is that we at least need to know the media to be used = in the conference (audio, video, text), to enable the server to reserve = resources and to enable the focus to include/exclude certain media from = the INVITEs SDP it sends out to the dial-out list, and also enables the = focus to reject the media streams in the SDP of INVITE request coming = from dial-in participants. I don't think in the basic media policy needs to define what the codecs = to be used are, this can be a normal offer answer exchange between the = client and the server. This is a basic requirement and enables CPCP to work without the = complicated media policy. If the people working on the media policy = could work on a basic one like this, it would be great. We can then work = on an advanced media policy as a second step. Regards, Hisham > -----Original Message----- > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On Behalf Of ext > Adam Roach > Sent: 11.December.2003 23:40 > To: Koskelainen Petri (NRC/Tampere); xcon@ietf.org > Subject: RE: [XCON] CPCP requirements to support IMS >=20 >=20 > [as chair] >=20 > petri.koskelainen@nokia.com=20 > [mailto:petri.koskelainen@nokia.com] wrote: >=20 > > I'm a bit worried about media policy-CPCP integration=20 > > and WG schedule regarding it. > >=20 > > Currently the charter says the following: > > May 04 Submit Membership Manipulation Protocol for=20 > publication as PS=20 > > Jul 04 Submit Protocol for Media Topology Control for publication > >=20 > > What I would like to have by May 04 is CPCP with the ability=20 > > to set up typical real-life conference, e.g. with audio codec X and > > centralized mixer.=20 > ... > > Current media policy seems to be extremely complex and the RFC goal=20 > > is not until July. > >=20 > > Georg can probably comment on 3GPP schedules but in any case,=20 > > should we adopt simple media definition in CPCP itself (or divide > > media policy into basic and advanced parts so basic media policy=20 > > could be ready by May 04)? >=20 > Media policy was pushed to July precisely because it is more complex > and (at this point, at least) more contentious. >=20 > I fear that diverting resources to getting a bare-bones media policy > out the door early will only cause significant delays to not just > advanced media policy, but to all of our deliverables. That seems > a steep price to pay for a two-month advance on publication. >=20 > Hopefully, by the time the membership manipulation document is ready > for publication, the media policy draft will be stable enough to give > you a basis to start implementation. >=20 > What is important to keep in mind is that we are not performing these > tasks serially. The documents should develop pretty much in parallel. >=20 > /a >=20 > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon >=20 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Fri Dec 12 12:45:31 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18024 for ; Fri, 12 Dec 2003 12:45:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUrLc-0006d8-Bd for xcon-archive@odin.ietf.org; Fri, 12 Dec 2003 12:45:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBCHj4YT025480 for xcon-archive@odin.ietf.org; Fri, 12 Dec 2003 12:45:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUrLc-0006ct-6S for xcon-web-archive@optimus.ietf.org; Fri, 12 Dec 2003 12:45:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18015 for ; Fri, 12 Dec 2003 12:45:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUrLa-0002jB-00 for xcon-web-archive@ietf.org; Fri, 12 Dec 2003 12:45:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AUrLa-0002j8-00 for xcon-web-archive@ietf.org; Fri, 12 Dec 2003 12:45:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUrLa-0006cM-UW; Fri, 12 Dec 2003 12:45:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUrKg-0006bK-KF for xcon@optimus.ietf.org; Fri, 12 Dec 2003 12:44:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17972 for ; Fri, 12 Dec 2003 12:44:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUrKe-0002hj-00 for xcon@ietf.org; Fri, 12 Dec 2003 12:44:04 -0500 Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx with esmtp (Exim 4.12) id 1AUrKe-0002h0-00 for xcon@ietf.org; Fri, 12 Dec 2003 12:44:04 -0500 Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 12 Dec 2003 09:43:29 -0800 Received: from 157.54.8.155 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 12 Dec 2003 09:43:33 -0800 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by inet-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 12 Dec 2003 09:43:39 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] CPCP and Conference URIs - there are more than one! Date: Fri, 12 Dec 2003 09:43:28 -0800 Message-ID: Thread-Topic: [XCON] CPCP and Conference URIs - there are more than one! Thread-Index: AcO7WMndAt1QJz/iQRC7zCRfA18SoQEuaDZgADCpWCA= From: "Orit Levin" To: "Eric Burger" , "Even, Roni" Cc: X-OriginalArrivalTime: 12 Dec 2003 17:43:39.0332 (UTC) FILETIME=[79F84040:01C3C0D7] Content-Transfer-Encoding: quoted-printable Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable In the SIP conference package, the participant URIs are opaque URIs. - It fits Eric's view. Should the conference package include different kinds of "Conference URIs" - is a more difficult question. Let's say we do, how are they going to be used by the recipient of the event information? In order to answer this question we need to provide answers to the following first: - Do we envision that other than SIP entities are going to subscribe to the SIP conference package? - Will XCON rely on the SIP conference package exclusively to supply all the basic events information about a conference? Orit. -----Original Message----- From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org] On Behalf Of Eric Burger Sent: Thursday, December 11, 2003 8:24 PM To: Even, Roni Cc: xcon@ietf.org Subject: RE: [XCON] CPCP and Conference URIs - there are more than one! Would I be interpreting this statement correctly "but the SIP conferencing package should be for SIP addresses" to mean that the SIP conferencing package only includes SIP stuff? Consider a multi-protocol conference bridge that has four users. A, B, and C use SIP while D uses H.323. A, B, and C subscribe to the SIP conferencing package, being conference aware. Do they know about D? D does not have a SIP address. What D does have is a URL. I would propose that if anything changes, it is that the packages (and XCON, too) just refer to URI's. We should not place any restriction on URI scheme. They are opaque objects. > -----Original Message----- > From: Even, Roni [mailto:roni.even@polycom.co.il] > Sent: Fri, December 05, 2003 12:53 PM > To: 'Orit Levin '; 'hisham.khartabil@nokia.com ';=20 > 'Brian.Rosen@marconi.com '; 'xcon@ietf.org ' > Subject: RE: [XCON] CPCP and Conference URIs - there are more than=20 > one! >=20 >=20 > Hi, > I think that Brian's point is very important. As for the SIP=20 > conference package, I think that the information in the XCON CPCP may=20 > support many call setup protocols (SP, H.323, H.320, PSTN) but the SIP > conferencing package should be for SIP addresses. > Roni Even >=20 > -----Original Message----- > From: Orit Levin > To: hisham.khartabil@nokia.com; Brian.Rosen@marconi.com; xcon@ietf.org > Sent: 05/12/2003 01:26 > Subject: RE: [XCON] CPCP and Conference URIs - there are more than=20 > one! >=20 > Yes, a conference can have a list of URI identifiers and the CPCP=20 > needs to reflect it. >=20 > My question is: Would we like to reflect this fact in the SIP=20 > Conference Package as well? (At least - as an optional structure :-) >=20 > Orit.=20 >=20 > -----Original Message----- > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org] On Behalf Of=20 > hisham.khartabil@nokia.com > Sent: Thursday, December 04, 2003 7:35 AM > To: Brian.Rosen@marconi.com; xcon@ietf.org > Subject: RE: [XCON] CPCP and Conference URIs - there are more than=20 > one! >=20 > Brian, >=20 > No argument there. We thought of that when we where creating the xcap=20 > based solution. The current solution can only hold a tel and a sip=20 > URI. > We plan on changing this. >=20 > Looks like a requirement needs to be added to the requirements=20 > document. > Does the solution need to be future proof? or do we just allow listing > the currently known protocols? >=20 > Regards, > Hisham >=20 > > -----Original Message----- > > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On > Behalf Of ext >=20 > > Rosen, Brian > > Sent: 04.December.2003 16:48 > > To: 'xcon@ietf.org' > > Subject: [XCON] CPCP and Conference URIs - there are more than one! > >=20 > >=20 > > The discussion of multiple ways to create conferences triggered a=20 > > discussion of XCON work being useable with multiple "using" > (to borrow >=20 > > a phrase from geopriv) protocols. > >=20 > > We have been assuming that CPCP will, at one time or > another, accept > > or receive a conference uri, which has so far been thought > of as a SIP >=20 > > uri. This will not do. There has to be a LIST of conference URIs,=20 > > one for each using protocol the conference might support. > >=20 > > There are already conference bridges that accept both SIP and H.323=20 > > endpoints intermixed. The conference uri for the H.323 > endpoints does >=20 > > not start with "sip:" folks! > >=20 > > There might even be a tel uri in there, right?!!! > > Ooh, Ooh, sure would be nice if that tel uri could have the PIN. > > Nah, over the top :) > >=20 > > Brian > >=20 > > _______________________________________________ > > XCON mailing list > > XCON@ietf.org > > https://www1.ietf.org/mailman/listinfo/xcon > >=20 >=20 > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon >=20 >=20 >=20 > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon >=20 > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon >=20 >=20 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Fri Dec 12 15:41:45 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25447 for ; Fri, 12 Dec 2003 15:41:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUu69-0007hG-9S for xcon-archive@odin.ietf.org; Fri, 12 Dec 2003 15:41:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBCKfHud029580 for xcon-archive@odin.ietf.org; Fri, 12 Dec 2003 15:41:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUu69-0007h1-25 for xcon-web-archive@optimus.ietf.org; Fri, 12 Dec 2003 15:41:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25384 for ; Fri, 12 Dec 2003 15:41:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUu67-0007n0-00 for xcon-web-archive@ietf.org; Fri, 12 Dec 2003 15:41:15 -0500 Received: from [65.246.255.50] (helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1AUu66-0007m3-01 for xcon-web-archive@ietf.org; Fri, 12 Dec 2003 15:41:15 -0500 Received: from [132.151.6.22] (helo=optimus.ietf.org) by manatick with esmtp (Exim 4.24) id 1AUtxC-00074D-SX for xcon-web-archive@ietf.org; Fri, 12 Dec 2003 15:32:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUtxB-0006iv-8I; Fri, 12 Dec 2003 15:32:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUtwq-0006iU-K5 for xcon@optimus.ietf.org; Fri, 12 Dec 2003 15:31:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25110 for ; Fri, 12 Dec 2003 15:31:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUtwp-0007a7-00 for xcon@ietf.org; Fri, 12 Dec 2003 15:31:39 -0500 Received: from goalie.snowshore.com ([216.57.133.4] helo=webshield.office.snowshore.com) by ietf-mx with smtp (Exim 4.12) id 1AUtwo-0007Yj-00 for xcon@ietf.org; Fri, 12 Dec 2003 15:31:38 -0500 Received: from zoe.office.snowshore.com(192.168.1.172) by webshield.office.snowshore.com via csmap id 6358; Fri, 12 Dec 2003 15:36:05 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] CPCP requirements to support IMS Date: Fri, 12 Dec 2003 15:31:08 -0500 Message-ID: <4A3384433CE2AB46A63468CB207E209DB1A009@zoe.office.snowshore.com> Thread-Topic: [XCON] CPCP requirements to support IMS Thread-Index: AcPAL38YEqFS9+kZRk2MQEOFch7dywAjIM9QAAsjMNA= From: "Eric Burger" To: , Content-Transfer-Encoding: quoted-printable Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Why do we need an explicit policy at all? Wouldn't the bridge, by its nature, accept or reject the different media = types? > -----Original Message----- > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > Sent: Fri, December 12, 2003 9:32 AM > To: adam@dynamicsoft.com; petri.koskelainen@nokia.com; xcon@ietf.org > Subject: RE: [XCON] CPCP requirements to support IMS >=20 >=20 > The issue I have is that we at least need to know the media=20 > to be used in the conference (audio, video, text), to enable=20 > the server to reserve resources and to enable the focus to=20 > include/exclude certain media from the INVITEs SDP it sends=20 > out to the dial-out list, and also enables the focus to=20 > reject the media streams in the SDP of INVITE request coming=20 > from dial-in participants. >=20 > I don't think in the basic media policy needs to define what=20 > the codecs to be used are, this can be a normal offer answer=20 > exchange between the client and the server. >=20 > This is a basic requirement and enables CPCP to work without=20 > the complicated media policy. If the people working on the=20 > media policy could work on a basic one like this, it would be=20 > great. We can then work on an advanced media policy as a second step. >=20 > Regards, > Hisham >=20 > > -----Original Message----- > > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On=20 > Behalf Of ext > > Adam Roach > > Sent: 11.December.2003 23:40 > > To: Koskelainen Petri (NRC/Tampere); xcon@ietf.org > > Subject: RE: [XCON] CPCP requirements to support IMS > >=20 > >=20 > > [as chair] > >=20 > > petri.koskelainen@nokia.com=20 > > [mailto:petri.koskelainen@nokia.com] wrote: > >=20 > > > I'm a bit worried about media policy-CPCP integration=20 > > > and WG schedule regarding it. > > >=20 > > > Currently the charter says the following: > > > May 04 Submit Membership Manipulation Protocol for=20 > > publication as PS=20 > > > Jul 04 Submit Protocol for Media Topology Control for publication > > >=20 > > > What I would like to have by May 04 is CPCP with the ability=20 > > > to set up typical real-life conference, e.g. with audio=20 > codec X and > > > centralized mixer.=20 > > ... > > > Current media policy seems to be extremely complex and=20 > the RFC goal=20 > > > is not until July. > > >=20 > > > Georg can probably comment on 3GPP schedules but in any case,=20 > > > should we adopt simple media definition in CPCP itself (or divide > > > media policy into basic and advanced parts so basic media policy=20 > > > could be ready by May 04)? > >=20 > > Media policy was pushed to July precisely because it is more complex > > and (at this point, at least) more contentious. > >=20 > > I fear that diverting resources to getting a bare-bones media policy > > out the door early will only cause significant delays to not just > > advanced media policy, but to all of our deliverables. That seems > > a steep price to pay for a two-month advance on publication. > >=20 > > Hopefully, by the time the membership manipulation document is ready > > for publication, the media policy draft will be stable=20 > enough to give > > you a basis to start implementation. > >=20 > > What is important to keep in mind is that we are not=20 > performing these > > tasks serially. The documents should develop pretty much in=20 > parallel. > >=20 > > /a > >=20 > > _______________________________________________ > > XCON mailing list > > XCON@ietf.org > > https://www1.ietf.org/mailman/listinfo/xcon > >=20 >=20 > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon >=20 >=20 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Sat Dec 13 11:37:51 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07708 for ; Sat, 13 Dec 2003 11:37:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVClb-0001Vp-BS for xcon-archive@odin.ietf.org; Sat, 13 Dec 2003 11:37:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBDGbIMj005772 for xcon-archive@odin.ietf.org; Sat, 13 Dec 2003 11:37:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVClY-0001Us-L7 for xcon-web-archive@optimus.ietf.org; Sat, 13 Dec 2003 11:37:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07686 for ; Sat, 13 Dec 2003 11:37:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AVClX-0004rQ-00 for xcon-web-archive@ietf.org; Sat, 13 Dec 2003 11:37:15 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AVClX-0004rM-00 for xcon-web-archive@ietf.org; Sat, 13 Dec 2003 11:37:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVClK-0001Sb-EV; Sat, 13 Dec 2003 11:37:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVClA-0001PA-1y for xcon@optimus.ietf.org; Sat, 13 Dec 2003 11:36:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07681 for ; Sat, 13 Dec 2003 11:36:49 -0500 (EST) From: aki.niemi@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AVCl8-0004r5-00 for xcon@ietf.org; Sat, 13 Dec 2003 11:36:50 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AVCl8-0004r2-00 for xcon@ietf.org; Sat, 13 Dec 2003 11:36:50 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hBDGamn24317 for ; Sat, 13 Dec 2003 18:36:48 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Sat, 13 Dec 2003 18:36:47 +0200 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Sat, 13 Dec 2003 18:36:47 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] CPCP and Conference URIs - there are more than one! Date: Sat, 13 Dec 2003 18:36:46 +0200 Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD902D59305@esebe013.ntc.nokia.com> Thread-Topic: [XCON] CPCP and Conference URIs - there are more than one! Thread-Index: AcO7WMndAt1QJz/iQRC7zCRfA18SoQEuaDZgADCpWCAAMEU2sA== To: Cc: X-OriginalArrivalTime: 13 Dec 2003 16:36:47.0202 (UTC) FILETIME=[4CF78C20:01C3C197] Content-Transfer-Encoding: quoted-printable Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Orit wrote: > Should the conference package include different kinds of "Conference > URIs" - is a more difficult question. Let's say we do, how are they > going to be used by the recipient of the event information? In theory at least, the recipient might want to subscibe to the = conference package, but join the conference by some other means than a = SIP URI.=20 For example, the client might have a high latency, low bandwidth IP pipe = -- good enough for SIP subscriptions but not good enough for voice. It = might also have a trusty old circuit switched telephony application that = would be perfect for voice. Cheers, Aki _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Mon Dec 15 02:55:44 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28472 for ; Mon, 15 Dec 2003 02:55:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVnZU-0007iA-4Y for xcon-archive@odin.ietf.org; Mon, 15 Dec 2003 02:55:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBF7tEo2029571 for xcon-archive@odin.ietf.org; Mon, 15 Dec 2003 02:55:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVnZR-0007gf-3q for xcon-web-archive@optimus.ietf.org; Mon, 15 Dec 2003 02:55:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28457 for ; Mon, 15 Dec 2003 02:55:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AVnZN-0006bG-00 for xcon-web-archive@ietf.org; Mon, 15 Dec 2003 02:55:09 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AVnZM-0006bC-00 for xcon-web-archive@ietf.org; Mon, 15 Dec 2003 02:55:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVnZO-0007gM-9s; Mon, 15 Dec 2003 02:55:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVnZC-0007fe-G8 for xcon@optimus.ietf.org; Mon, 15 Dec 2003 02:54:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28452 for ; Mon, 15 Dec 2003 02:54:55 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AVnZ8-0006au-00 for xcon@ietf.org; Mon, 15 Dec 2003 02:54:54 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AVnZ8-0006aq-00 for xcon@ietf.org; Mon, 15 Dec 2003 02:54:54 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hBF7srH20104 for ; Mon, 15 Dec 2003 09:54:53 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 15 Dec 2003 09:54:53 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 15 Dec 2003 09:54:52 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] CPCP requirements to support IMS X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Mon, 15 Dec 2003 09:54:52 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797504@esebe019.ntc.nokia.com> Thread-Topic: [XCON] CPCP requirements to support IMS Thread-Index: AcPAL38YEqFS9+kZRk2MQEOFch7dywAjIM9QAAsjMNAAfgFHkA== To: , X-OriginalArrivalTime: 15 Dec 2003 07:54:52.0680 (UTC) FILETIME=[B8E23080:01C3C2E0] Content-Transfer-Encoding: quoted-printable Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Are you suggesting that that creator of a conference has no say in what = media the conference will offer? /Hisham > -----Original Message----- > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On Behalf Of ext > Eric Burger > Sent: 12.December.2003 22:31 > To: Khartabil Hisham (NMP-MSW/Helsinki); xcon@ietf.org > Subject: RE: [XCON] CPCP requirements to support IMS >=20 >=20 > Why do we need an explicit policy at all? >=20 > Wouldn't the bridge, by its nature, accept or reject the=20 > different media types? >=20 > > -----Original Message----- > > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > > Sent: Fri, December 12, 2003 9:32 AM > > To: adam@dynamicsoft.com; petri.koskelainen@nokia.com; xcon@ietf.org > > Subject: RE: [XCON] CPCP requirements to support IMS > >=20 > >=20 > > The issue I have is that we at least need to know the media=20 > > to be used in the conference (audio, video, text), to enable=20 > > the server to reserve resources and to enable the focus to=20 > > include/exclude certain media from the INVITEs SDP it sends=20 > > out to the dial-out list, and also enables the focus to=20 > > reject the media streams in the SDP of INVITE request coming=20 > > from dial-in participants. > >=20 > > I don't think in the basic media policy needs to define what=20 > > the codecs to be used are, this can be a normal offer answer=20 > > exchange between the client and the server. > >=20 > > This is a basic requirement and enables CPCP to work without=20 > > the complicated media policy. If the people working on the=20 > > media policy could work on a basic one like this, it would be=20 > > great. We can then work on an advanced media policy as a=20 > second step. > >=20 > > Regards, > > Hisham > >=20 > > > -----Original Message----- > > > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On=20 > > Behalf Of ext > > > Adam Roach > > > Sent: 11.December.2003 23:40 > > > To: Koskelainen Petri (NRC/Tampere); xcon@ietf.org > > > Subject: RE: [XCON] CPCP requirements to support IMS > > >=20 > > >=20 > > > [as chair] > > >=20 > > > petri.koskelainen@nokia.com=20 > > > [mailto:petri.koskelainen@nokia.com] wrote: > > >=20 > > > > I'm a bit worried about media policy-CPCP integration=20 > > > > and WG schedule regarding it. > > > >=20 > > > > Currently the charter says the following: > > > > May 04 Submit Membership Manipulation Protocol for=20 > > > publication as PS=20 > > > > Jul 04 Submit Protocol for Media Topology Control for=20 > publication > > > >=20 > > > > What I would like to have by May 04 is CPCP with the ability=20 > > > > to set up typical real-life conference, e.g. with audio=20 > > codec X and > > > > centralized mixer.=20 > > > ... > > > > Current media policy seems to be extremely complex and=20 > > the RFC goal=20 > > > > is not until July. > > > >=20 > > > > Georg can probably comment on 3GPP schedules but in any case,=20 > > > > should we adopt simple media definition in CPCP itself=20 > (or divide > > > > media policy into basic and advanced parts so basic=20 > media policy=20 > > > > could be ready by May 04)? > > >=20 > > > Media policy was pushed to July precisely because it is=20 > more complex > > > and (at this point, at least) more contentious. > > >=20 > > > I fear that diverting resources to getting a bare-bones=20 > media policy > > > out the door early will only cause significant delays to not just > > > advanced media policy, but to all of our deliverables. That seems > > > a steep price to pay for a two-month advance on publication. > > >=20 > > > Hopefully, by the time the membership manipulation=20 > document is ready > > > for publication, the media policy draft will be stable=20 > > enough to give > > > you a basis to start implementation. > > >=20 > > > What is important to keep in mind is that we are not=20 > > performing these > > > tasks serially. The documents should develop pretty much in=20 > > parallel. > > >=20 > > > /a > > >=20 > > > _______________________________________________ > > > XCON mailing list > > > XCON@ietf.org > > > https://www1.ietf.org/mailman/listinfo/xcon > > >=20 > >=20 > > _______________________________________________ > > XCON mailing list > > XCON@ietf.org > > https://www1.ietf.org/mailman/listinfo/xcon > >=20 > >=20 >=20 >=20 > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon >=20 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Mon Dec 15 07:55:34 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06050 for ; Mon, 15 Dec 2003 07:55:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVsFc-0001iR-TW for xcon-archive@odin.ietf.org; Mon, 15 Dec 2003 07:55:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBFCt4YH006586 for xcon-archive@odin.ietf.org; Mon, 15 Dec 2003 07:55:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVsFc-0001hx-Mf for xcon-web-archive@optimus.ietf.org; Mon, 15 Dec 2003 07:55:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06021 for ; Mon, 15 Dec 2003 07:55:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AVsFb-0003gr-00 for xcon-web-archive@ietf.org; Mon, 15 Dec 2003 07:55:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AVsFb-0003gl-00 for xcon-web-archive@ietf.org; Mon, 15 Dec 2003 07:55:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVsFb-0001hO-80; Mon, 15 Dec 2003 07:55:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVsFX-0001gh-Rt for xcon@optimus.ietf.org; Mon, 15 Dec 2003 07:54:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06011 for ; Mon, 15 Dec 2003 07:54:58 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AVsFX-0003gZ-00 for xcon@ietf.org; Mon, 15 Dec 2003 07:54:59 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AVsFW-0003gW-00 for xcon@ietf.org; Mon, 15 Dec 2003 07:54:58 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hBFCsvH19295 for ; Mon, 15 Dec 2003 14:54:57 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 15 Dec 2003 14:54:55 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 15 Dec 2003 14:54:55 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 15 Dec 2003 14:54:54 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB70118B145@esebe019.ntc.nokia.com> Thread-Topic: CPCP Requirement: Conference package subscribers Thread-Index: AcPDCqKXFQaTbjOoSKCVoG8EwWWp/w== To: X-OriginalArrivalTime: 15 Dec 2003 12:54:55.0418 (UTC) FILETIME=[A35A01A0:01C3C30A] Content-Transfer-Encoding: quoted-printable Subject: [XCON] CPCP Requirement: Conference package subscribers Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable This is in reference to requirement REQ-H5 in = http://www.ietf.org/internet-drafts/draft-ietf-xcon-cpcp-reqs-00.txt REQ-H5: It SHOULD be possible to define users who are allowed to subscribe to conference event package [4] Should this be a separate list? or should a combination of Dial-out = list, Dial-in list be sufficient? i.e. only participants and potential = participants can subscribe to the conference event package (outside = users not allowed)? In any case, I think the requirement needs to stay, but needs rewording = according to the conclusions we come up with that answer the above = question. Regards, Hisham _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Mon Dec 15 07:56:31 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06088 for ; Mon, 15 Dec 2003 07:56:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVsGY-0001mN-C1 for xcon-archive@odin.ietf.org; Mon, 15 Dec 2003 07:56:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBFCu27H006833 for xcon-archive@odin.ietf.org; Mon, 15 Dec 2003 07:56:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVsGY-0001m8-53 for xcon-web-archive@optimus.ietf.org; Mon, 15 Dec 2003 07:56:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06079 for ; Mon, 15 Dec 2003 07:56:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AVsGX-0003hU-00 for xcon-web-archive@ietf.org; Mon, 15 Dec 2003 07:56:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AVsGW-0003hR-00 for xcon-web-archive@ietf.org; Mon, 15 Dec 2003 07:56:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVsGX-0001lb-7M; Mon, 15 Dec 2003 07:56:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVsFw-0001kx-DM for xcon@optimus.ietf.org; Mon, 15 Dec 2003 07:55:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06047 for ; Mon, 15 Dec 2003 07:55:23 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AVsFv-0003h9-00 for xcon@ietf.org; Mon, 15 Dec 2003 07:55:23 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AVsFv-0003h6-00 for xcon@ietf.org; Mon, 15 Dec 2003 07:55:23 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hBFCtMH19764 for ; Mon, 15 Dec 2003 14:55:22 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 15 Dec 2003 14:55:21 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 15 Dec 2003 14:55:21 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 15 Dec 2003 14:55:21 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB70118B13F@esebe019.ntc.nokia.com> Thread-Topic: CPCP Requirement: Hidden Participants Thread-Index: AcPDCrKHCjkGxhopT3GgjdpgZxXlUw== To: X-OriginalArrivalTime: 15 Dec 2003 12:55:21.0886 (UTC) FILETIME=[B320B3E0:01C3C30A] Content-Transfer-Encoding: quoted-printable Subject: [XCON] CPCP Requirement: Hidden Participants Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable This is in reference to requirements REQ-A7 and REQ-E10 in = http://www.ietf.org/internet-drafts/draft-ietf-xcon-cpcp-reqs-00.txt REQ-A7: It SHOULD be possible to participate in a conference as a hidden user. Hidden user is present in a conference, but his presence is not revealed. REQ-E10: It MUST be possible to allow and disallow hidden membership in a conference. Should a conference policy, using CPCP, specify if a user can be hidden? = This means that the conference state package does not report the = participation on the hidden user. CPCP is used to identify which users = are hidden. The list of hidden users is only manipulated by a privileged = user such as the moderator. Regards, Hisham _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Mon Dec 15 07:57:33 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06144 for ; Mon, 15 Dec 2003 07:57:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVsHX-0001re-Ra for xcon-archive@odin.ietf.org; Mon, 15 Dec 2003 07:57:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBFCv3EE007166 for xcon-archive@odin.ietf.org; Mon, 15 Dec 2003 07:57:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVsHW-0001qQ-Lq for xcon-web-archive@optimus.ietf.org; Mon, 15 Dec 2003 07:57:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06110 for ; Mon, 15 Dec 2003 07:57:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AVsHV-0003i0-00 for xcon-web-archive@ietf.org; Mon, 15 Dec 2003 07:57:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AVsHV-0003hx-00 for xcon-web-archive@ietf.org; Mon, 15 Dec 2003 07:57:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVsHV-0001oX-MD; Mon, 15 Dec 2003 07:57:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVsH4-0001o1-BL for xcon@optimus.ietf.org; Mon, 15 Dec 2003 07:56:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06104 for ; Mon, 15 Dec 2003 07:56:32 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AVsH3-0003ho-00 for xcon@ietf.org; Mon, 15 Dec 2003 07:56:33 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AVsH2-0003hl-00 for xcon@ietf.org; Mon, 15 Dec 2003 07:56:32 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hBFCuVH21197 for ; Mon, 15 Dec 2003 14:56:31 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 15 Dec 2003 14:56:31 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 15 Dec 2003 14:56:30 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 15 Dec 2003 14:56:30 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 15 Dec 2003 14:56:30 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB70118B140@esebe019.ntc.nokia.com> Thread-Topic: CPCP Requirement: Conference and Host Info Thread-Index: AcPDCtvMDWhuEleQTK+zRzOFyxPILQ== To: X-OriginalArrivalTime: 15 Dec 2003 12:56:30.0922 (UTC) FILETIME=[DC46C2A0:01C3C30A] Content-Transfer-Encoding: quoted-printable Subject: [XCON] CPCP Requirement: Conference and Host Info Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable This is in reference to requirements REQ-B1 to REG-B6, and REG-B10 in = http://www.ietf.org/internet-drafts/draft-ietf-xcon-cpcp-reqs-00.txt REQ-B1: It MUST be possible to set, modify and delete a conference Subject. REQ-B2: It MUST be possible to set, modify and delete conference URI display name. REQ-B3: It MUST be possible to set, modify and delete conference creator information. REQ-B4: It MUST be possible to set, modify and delete conference URI link for more information. REQ-B5: It MUST be possible to set, modify and delete conference host contact information. REQ-B6: It MUST be possible to set, modify and delete short conference session description. REQ-B10: It SHOULD be possible to set, modify and delete conference Keywords. (This may be useful e.g. for search engines). I think a conference subject and display name as well as conference = session description are useful. Perhaps the conference session = description can appear on a conference web sight. What about conference = host and creator information? I would like opinions on what people deem necessary information. Of = course, we can have all if needed. Regards, Hisham _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Mon Dec 15 07:57:33 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06158 for ; Mon, 15 Dec 2003 07:57:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVsHY-0001s2-Kz for xcon-archive@odin.ietf.org; Mon, 15 Dec 2003 07:57:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBFCv48i007184 for xcon-archive@odin.ietf.org; Mon, 15 Dec 2003 07:57:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVsHY-0001rn-AJ for xcon-web-archive@optimus.ietf.org; Mon, 15 Dec 2003 07:57:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06114 for ; Mon, 15 Dec 2003 07:57:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AVsHX-0003i7-00 for xcon-web-archive@ietf.org; Mon, 15 Dec 2003 07:57:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AVsHX-0003i4-00 for xcon-web-archive@ietf.org; Mon, 15 Dec 2003 07:57:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVsHW-0001pq-EY; Mon, 15 Dec 2003 07:57:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVsHM-0001oG-J6 for xcon@optimus.ietf.org; Mon, 15 Dec 2003 07:56:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06107 for ; Mon, 15 Dec 2003 07:56:51 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AVsHL-0003hu-00 for xcon@ietf.org; Mon, 15 Dec 2003 07:56:51 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AVsHL-0003hr-00 for xcon@ietf.org; Mon, 15 Dec 2003 07:56:51 -0500 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hBFCunn27541 for ; Mon, 15 Dec 2003 14:56:49 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 15 Dec 2003 14:56:49 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 15 Dec 2003 14:56:47 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 15 Dec 2003 14:56:47 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB70118B141@esebe019.ntc.nokia.com> Thread-Topic: CPCP Requirement: Max number of participants Thread-Index: AcPDCuXt+pCb8aZETpqQxWB91wJIAQ== To: X-OriginalArrivalTime: 15 Dec 2003 12:56:48.0070 (UTC) FILETIME=[E67F5660:01C3C30A] Content-Transfer-Encoding: quoted-printable Subject: [XCON] CPCP Requirement: Max number of participants Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable This is in reference to requirements REQ-B7 in = http://www.ietf.org/internet-drafts/draft-ietf-xcon-cpcp-reqs-00.txt REQ-B7: It SHOULD be possible to set, modify and delete the parameter for max number of conference participants. This defines how many users at max can be present at the same time. Should a conference policy, using CPCP, specify the max number of = participants in a conference? (This does not override a server policy, = but limits it, if the user does not want too many participants). It might be useful, but is it necessary? Regards, Hisham _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Mon Dec 15 07:58:32 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06201 for ; Mon, 15 Dec 2003 07:58:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVsIV-0001v0-6F for xcon-archive@odin.ietf.org; Mon, 15 Dec 2003 07:58:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBFCw3Zu007358 for xcon-archive@odin.ietf.org; Mon, 15 Dec 2003 07:58:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVsIU-0001uJ-MM for xcon-web-archive@optimus.ietf.org; Mon, 15 Dec 2003 07:58:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06184 for ; Mon, 15 Dec 2003 07:58:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AVsIT-0003jy-00 for xcon-web-archive@ietf.org; Mon, 15 Dec 2003 07:58:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AVsIT-0003jv-00 for xcon-web-archive@ietf.org; Mon, 15 Dec 2003 07:58:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVsIT-0001tN-Nf; Mon, 15 Dec 2003 07:58:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVsHz-0001sY-EZ for xcon@optimus.ietf.org; Mon, 15 Dec 2003 07:57:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06142 for ; Mon, 15 Dec 2003 07:57:30 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AVsHy-0003jd-00 for xcon@ietf.org; Mon, 15 Dec 2003 07:57:30 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AVsHy-0003ja-00 for xcon@ietf.org; Mon, 15 Dec 2003 07:57:30 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hBFCvSn28373 for ; Mon, 15 Dec 2003 14:57:29 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 15 Dec 2003 14:57:26 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 15 Dec 2003 14:57:26 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 15 Dec 2003 14:57:26 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 15 Dec 2003 14:57:25 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB70118B142@esebe019.ntc.nokia.com> Thread-Topic: CPCP Requirement: de-activating a conference Thread-Index: AcPDCvyxoTmV1LteThCd+fNLUpjc7g== To: X-OriginalArrivalTime: 15 Dec 2003 12:57:26.0185 (UTC) FILETIME=[FD373990:01C3C30A] Content-Transfer-Encoding: quoted-printable Subject: [XCON] CPCP Requirement: de-activating a conference Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable This is in reference to requirement REQ-B9 in = http://www.ietf.org/internet-drafts/draft-ietf-xcon-cpcp-reqs-00.txt REQ-B9: It MUST be possible to inactive a conference for defined period of time. There are start and stop times for a conference. A conference might live = for days, weeks or even months. Should a conference policy, using CPCP, = allow a privileged user to de-activate a conference for a period of time = within the start and stop times of a conference? Examples are = administrator is performing some maintenance. Regards, Hisham _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Mon Dec 15 07:58:32 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06206 for ; Mon, 15 Dec 2003 07:58:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVsIV-0001vN-Km for xcon-archive@odin.ietf.org; Mon, 15 Dec 2003 07:58:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBFCw3OO007391 for xcon-archive@odin.ietf.org; Mon, 15 Dec 2003 07:58:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVsIV-0001v4-9w for xcon-web-archive@optimus.ietf.org; Mon, 15 Dec 2003 07:58:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06187 for ; Mon, 15 Dec 2003 07:58:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AVsIU-0003k4-00 for xcon-web-archive@ietf.org; Mon, 15 Dec 2003 07:58:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AVsIU-0003k1-00 for xcon-web-archive@ietf.org; Mon, 15 Dec 2003 07:58:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVsIU-0001tz-73; Mon, 15 Dec 2003 07:58:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVsIB-0001si-Ox for xcon@optimus.ietf.org; Mon, 15 Dec 2003 07:57:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06175 for ; Mon, 15 Dec 2003 07:57:42 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AVsIA-0003jj-00 for xcon@ietf.org; Mon, 15 Dec 2003 07:57:42 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AVsIA-0003jg-00 for xcon@ietf.org; Mon, 15 Dec 2003 07:57:42 -0500 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hBFCven28588 for ; Mon, 15 Dec 2003 14:57:40 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 15 Dec 2003 14:57:40 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 15 Dec 2003 14:57:39 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 15 Dec 2003 14:57:39 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB70118B143@esebe019.ntc.nokia.com> Thread-Topic: CPCP Requirement: Media policy Thread-Index: AcPDCwSZ5fLRV7YBQXCHBvLisq+S8A== To: X-OriginalArrivalTime: 15 Dec 2003 12:57:39.0298 (UTC) FILETIME=[05081C20:01C3C30B] Content-Transfer-Encoding: quoted-printable Subject: [XCON] CPCP Requirement: Media policy Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable This is in reference to requirement REQ-D1 in = http://www.ietf.org/internet-drafts/draft-ietf-xcon-cpcp-reqs-00.txt REQ-D1: It MAY be possible to define media policy within conference policy. We all know that conference policy, as defined today, encapsulates media = policy. Should CPCP carry that media policy? At least for things like = media types (Audio, video, text, etc)? Regards, Hisham _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Mon Dec 15 07:58:34 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06231 for ; Mon, 15 Dec 2003 07:58:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVsIX-0001yP-1U for xcon-archive@odin.ietf.org; Mon, 15 Dec 2003 07:58:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBFCw4SH007409 for xcon-archive@odin.ietf.org; Mon, 15 Dec 2003 07:58:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVsIW-0001vQ-0G for xcon-web-archive@optimus.ietf.org; Mon, 15 Dec 2003 07:58:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06192 for ; Mon, 15 Dec 2003 07:58:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AVsIV-0003kA-00 for xcon-web-archive@ietf.org; Mon, 15 Dec 2003 07:58:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AVsIU-0003k7-00 for xcon-web-archive@ietf.org; Mon, 15 Dec 2003 07:58:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVsIU-0001ub-Px; Mon, 15 Dec 2003 07:58:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVsIP-0001su-Bo for xcon@optimus.ietf.org; Mon, 15 Dec 2003 07:57:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06178 for ; Mon, 15 Dec 2003 07:57:55 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AVsIO-0003jq-00 for xcon@ietf.org; Mon, 15 Dec 2003 07:57:56 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AVsIN-0003jn-00 for xcon@ietf.org; Mon, 15 Dec 2003 07:57:55 -0500 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hBFCvsn28785 for ; Mon, 15 Dec 2003 14:57:54 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 15 Dec 2003 14:57:54 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 15 Dec 2003 14:57:53 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 15 Dec 2003 14:57:53 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB70118B144@esebe019.ntc.nokia.com> Thread-Topic: CPCP Requirement: Floor Control Thread-Index: AcPDCw0/JJN19Np3S0WvAM2300oGHQ== To: X-OriginalArrivalTime: 15 Dec 2003 12:57:54.0013 (UTC) FILETIME=[0DCD70D0:01C3C30B] Content-Transfer-Encoding: quoted-printable Subject: [XCON] CPCP Requirement: Floor Control Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable There needs to be some floor control policy that is part of CPCP. = Requirements like: - Does the Conference have floor control or not - Is the conference floor control moderator-driven by human or First = come first serve by automata. - How many users can have the floor at one time. - If automata driven, how long is the maximum time a user can ask for = floor. Does anyone have objections to such requirements in CPCP requirements = document? Any other requirements for floor control policy? There is one requirement that appears in = http://www.ietf.org/internet-drafts/draft-ietf-xcon-cpcp-reqs-00.txt REQ-F1: It MUST be possible to assign and de-assign the users who are allowed to manipulate floor policy. Regards, Hisham _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Mon Dec 15 08:02:36 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06568 for ; Mon, 15 Dec 2003 08:02:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVsMR-00027J-H3 for xcon-archive@odin.ietf.org; Mon, 15 Dec 2003 08:02:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBFD27dX008131 for xcon-archive@odin.ietf.org; Mon, 15 Dec 2003 08:02:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVsMR-000274-6D for xcon-web-archive@optimus.ietf.org; Mon, 15 Dec 2003 08:02:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06494 for ; Mon, 15 Dec 2003 08:02:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AVsMQ-0003uR-00 for xcon-web-archive@ietf.org; Mon, 15 Dec 2003 08:02:06 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AVsMP-0003uO-00 for xcon-web-archive@ietf.org; Mon, 15 Dec 2003 08:02:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVsMQ-00026W-48; Mon, 15 Dec 2003 08:02:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVsMH-00024W-5U for xcon@optimus.ietf.org; Mon, 15 Dec 2003 08:01:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06453 for ; Mon, 15 Dec 2003 08:01:55 -0500 (EST) From: Jari.Mutikainen@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AVsMG-0003sj-00 for xcon@ietf.org; Mon, 15 Dec 2003 08:01:56 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AVsMF-0003sJ-00 for xcon@ietf.org; Mon, 15 Dec 2003 08:01:55 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hBFD1sH29417 for ; Mon, 15 Dec 2003 15:01:54 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 15 Dec 2003 15:01:53 +0200 Received: from esebe001.NOE.Nokia.com ([172.21.138.30]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 15 Dec 2003 15:01:49 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] CPCP Requirement: Conference package subscribers Date: Mon, 15 Dec 2003 15:01:30 +0200 Message-ID: <05DAF85DFD6A9940B7C90667D4624F0D012E58AC@esebe001> Thread-Topic: CPCP Requirement: Conference package subscribers Thread-Index: AcPDCqKXFQaTbjOoSKCVoG8EwWWp/wAAMiCA To: , X-OriginalArrivalTime: 15 Dec 2003 13:01:49.0777 (UTC) FILETIME=[9A542C10:01C3C30B] Content-Transfer-Encoding: quoted-printable Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable The address from where I subscribe the conference event might be = diffrent to the addres from where I'm joining to the conference. BR, Jari=20 > -----Original Message----- > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On Behalf Of ext > hisham.khartabil@nokia.com > Sent: 15 December, 2003 14:55 > To: xcon@ietf.org > Subject: [XCON] CPCP Requirement: Conference package subscribers >=20 >=20 > This is in reference to requirement REQ-H5 in=20 > http://www.ietf.org/internet-drafts/draft-ietf-xcon-cpcp-reqs-00.txt >=20 > REQ-H5: It SHOULD be possible to define users who are allowed to > subscribe to conference event package [4] >=20 > Should this be a separate list? or should a combination of=20 > Dial-out list, Dial-in list be sufficient? i.e. only=20 > participants and potential participants can subscribe to the=20 > conference event package (outside users not allowed)? >=20 > In any case, I think the requirement needs to stay, but needs=20 > rewording according to the conclusions we come up with that=20 > answer the above question. >=20 > Regards, > Hisham >=20 > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon >=20 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Mon Dec 15 08:07:31 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06881 for ; Mon, 15 Dec 2003 08:07:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVsRC-0002Fd-Cz for xcon-archive@odin.ietf.org; Mon, 15 Dec 2003 08:07:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBFD72ed008639 for xcon-archive@odin.ietf.org; Mon, 15 Dec 2003 08:07:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVsRB-0002FG-V3 for xcon-web-archive@optimus.ietf.org; Mon, 15 Dec 2003 08:07:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06824 for ; Mon, 15 Dec 2003 08:07:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AVsRB-00044K-00 for xcon-web-archive@ietf.org; Mon, 15 Dec 2003 08:07:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AVsRA-00044H-00 for xcon-web-archive@ietf.org; Mon, 15 Dec 2003 08:07:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVsRA-0002EL-Tm; Mon, 15 Dec 2003 08:07:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVsQs-0002Dj-12 for xcon@optimus.ietf.org; Mon, 15 Dec 2003 08:06:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06813 for ; Mon, 15 Dec 2003 08:06:40 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AVsQq-000440-00 for xcon@ietf.org; Mon, 15 Dec 2003 08:06:41 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AVsQq-00043w-00 for xcon@ietf.org; Mon, 15 Dec 2003 08:06:40 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hBFD6dn12020 for ; Mon, 15 Dec 2003 15:06:39 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 15 Dec 2003 15:06:29 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 15 Dec 2003 15:06:28 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] CPCP Requirement: Conference package subscribers Date: Mon, 15 Dec 2003 15:06:27 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB70179750F@esebe019.ntc.nokia.com> Thread-Topic: CPCP Requirement: Conference package subscribers Thread-Index: AcPDCqKXFQaTbjOoSKCVoG8EwWWp/wAAMiCAAAAch1A= To: , X-OriginalArrivalTime: 15 Dec 2003 13:06:28.0280 (UTC) FILETIME=[40545B80:01C3C30C] Content-Transfer-Encoding: quoted-printable Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Jari, You are right, if you use a non-sip protocol to join the conference. In any case, this is not related to the questions I ask that are related = who is allowed to subscribe to the conference state event package. Regards, Hisham > -----Original Message----- > From: Mutikainen Jari (NMP-MSW/Helsinki)=20 > Sent: 15.December.2003 15:02 > To: Khartabil Hisham (NMP-MSW/Helsinki); xcon@ietf.org > Subject: RE: [XCON] CPCP Requirement: Conference package subscribers >=20 >=20 > The address from where I subscribe the conference event might=20 > be diffrent to the addres from where I'm joining to the conference. >=20 > BR, > Jari=20 >=20 > > -----Original Message----- > > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On=20 > Behalf Of ext > > hisham.khartabil@nokia.com > > Sent: 15 December, 2003 14:55 > > To: xcon@ietf.org > > Subject: [XCON] CPCP Requirement: Conference package subscribers > >=20 > >=20 > > This is in reference to requirement REQ-H5 in=20 > > http://www.ietf.org/internet-drafts/draft-ietf-xcon-cpcp-reqs-00.txt > >=20 > > REQ-H5: It SHOULD be possible to define users who are allowed to > > subscribe to conference event package [4] > >=20 > > Should this be a separate list? or should a combination of=20 > > Dial-out list, Dial-in list be sufficient? i.e. only=20 > > participants and potential participants can subscribe to the=20 > > conference event package (outside users not allowed)? > >=20 > > In any case, I think the requirement needs to stay, but needs=20 > > rewording according to the conclusions we come up with that=20 > > answer the above question. > >=20 > > Regards, > > Hisham > >=20 > > _______________________________________________ > > XCON mailing list > > XCON@ietf.org > > https://www1.ietf.org/mailman/listinfo/xcon > >=20 >=20 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Mon Dec 15 08:42:56 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06049 for ; Mon, 15 Dec 2003 07:55:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVsFc-0001iI-SI for xcon-archive@odin.ietf.org; Mon, 15 Dec 2003 07:55:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBFCt4IF006574 for xcon-archive@odin.ietf.org; Mon, 15 Dec 2003 07:55:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVsFc-0001hw-Kt for xcon-web-archive@optimus.ietf.org; Mon, 15 Dec 2003 07:55:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06020 for ; Mon, 15 Dec 2003 07:55:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AVsFb-0003go-00 for xcon-web-archive@ietf.org; Mon, 15 Dec 2003 07:55:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AVsFb-0003gk-00 for xcon-web-archive@ietf.org; Mon, 15 Dec 2003 07:55:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVsFa-0001hA-Sl; Mon, 15 Dec 2003 07:55:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVsFB-0001gT-9S for xcon@optimus.ietf.org; Mon, 15 Dec 2003 07:54:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05988 for ; Mon, 15 Dec 2003 07:54:35 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AVsFA-0003fn-00 for xcon@ietf.org; Mon, 15 Dec 2003 07:54:36 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AVsF9-0003fk-00 for xcon@ietf.org; Mon, 15 Dec 2003 07:54:35 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hBFCsYn24760 for ; Mon, 15 Dec 2003 14:54:34 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 15 Dec 2003 14:54:28 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 15 Dec 2003 14:54:27 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 15 Dec 2003 14:54:27 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB70118B13E@esebe019.ntc.nokia.com> Thread-Topic: CPCP Requirement: Anonymous participants Thread-Index: AcPDCpIN8TGM7tvHSwi6IuBepLVKVQ== To: X-OriginalArrivalTime: 15 Dec 2003 12:54:27.0669 (UTC) FILETIME=[92CFD850:01C3C30A] Content-Transfer-Encoding: quoted-printable Subject: [XCON] CPCP Requirement: Anonymous participants Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable This is the first of a series of emails discussing Conference Policy = Requirements. Your engagement is appreciated. This is in reference to requirements REQ-A6 and REQ-E9 in = http://www.ietf.org/internet-drafts/draft-ietf-xcon-cpcp-reqs-00.txt REQ-A6: It SHOULD be possible to anonymously participate in a conference. REQ-E9: It MUST be possible to allow and disallow anonymous membership in a conference. Should a conference policy, using CPCP, specify if anonymous = participants are allowed to join a conference? Or should this be a local = policy at the server? There are 2 types of anonymous participants: 1. ones that joins a conference using a http digest username of = "anonymous" and no password 2. ones that join with a proper username and password, but hide their = identity using anonynous@somewhere.com in the From-header of a SIP = INVITE. The conference state package notifications shows them as = anonymous participants. I don't think we need to allow 1. Either a conference requires everyone = to know the username and password of the conference, or does not require = digest authentication at all. 2 can be provided, but we need consensus that this is a useful feature. Regards, Hisham _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Mon Dec 15 08:50:38 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08129 for ; Mon, 15 Dec 2003 08:50:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVt6v-00043w-3F for xcon-archive@odin.ietf.org; Mon, 15 Dec 2003 08:50:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBFDo83R015604 for xcon-archive@odin.ietf.org; Mon, 15 Dec 2003 08:50:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVt6s-00042W-Ay for xcon-web-archive@optimus.ietf.org; Mon, 15 Dec 2003 08:50:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08112 for ; Mon, 15 Dec 2003 08:50:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AVt6r-0004k1-00 for xcon-web-archive@ietf.org; Mon, 15 Dec 2003 08:50:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AVt6q-0004jx-00 for xcon-web-archive@ietf.org; Mon, 15 Dec 2003 08:50:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVt6q-00042C-3D; Mon, 15 Dec 2003 08:50:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVt5w-00040i-Bs for xcon@optimus.ietf.org; Mon, 15 Dec 2003 08:49:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08096 for ; Mon, 15 Dec 2003 08:49:06 -0500 (EST) From: Jari.Mutikainen@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AVt5u-0004jH-00 for xcon@ietf.org; Mon, 15 Dec 2003 08:49:06 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AVt5u-0004j6-00 for xcon@ietf.org; Mon, 15 Dec 2003 08:49:06 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hBFDn4H08279 for ; Mon, 15 Dec 2003 15:49:04 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 15 Dec 2003 15:49:04 +0200 Received: from esebe001.NOE.Nokia.com ([172.21.138.30]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 15 Dec 2003 15:49:03 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] CPCP Requirement: Conference package subscribers Date: Mon, 15 Dec 2003 15:49:03 +0200 Message-ID: <05DAF85DFD6A9940B7C90667D4624F0D012E58B1@esebe001> Thread-Topic: CPCP Requirement: Conference package subscribers Thread-Index: AcPDCqKXFQaTbjOoSKCVoG8EwWWp/wAAMiCAAAAch1AAAY48IA== To: , X-OriginalArrivalTime: 15 Dec 2003 13:49:03.0555 (UTC) FILETIME=[33646130:01C3C312] Content-Transfer-Encoding: quoted-printable Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable I might want to follow the conference status (and manage it if I'm the = host) from my PC client, and participate from a legacy mobile/PSTN = device. Even if I'm using a single device, I might have a device that = does not support VoIP but supports non-RT SIP, so I'm using my SIP = subscription and it's SIP URI to subscribe, but Tel URI to join.=20 Now, the only way to tie these is that we have a separate list for = participants that are allowed to subscribe? In dial-in case it could be = possible to put both URIs to the Dial-In list, but in Dial-out case it = is impossible, as the server tries to invite both, even they mean a = single participant? BR, Jari > -----Original Message----- > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On Behalf Of ext > hisham.khartabil@nokia.com > Sent: 15 December, 2003 15:06 > To: Mutikainen Jari (NMP-MSW/Helsinki); xcon@ietf.org > Subject: RE: [XCON] CPCP Requirement: Conference package subscribers >=20 >=20 > Jari, >=20 > You are right, if you use a non-sip protocol to join the conference. >=20 > In any case, this is not related to the questions I ask that=20 > are related who is allowed to subscribe to the conference=20 > state event package. >=20 > Regards, > Hisham >=20 > > -----Original Message----- > > From: Mutikainen Jari (NMP-MSW/Helsinki)=20 > > Sent: 15.December.2003 15:02 > > To: Khartabil Hisham (NMP-MSW/Helsinki); xcon@ietf.org > > Subject: RE: [XCON] CPCP Requirement: Conference package subscribers > >=20 > >=20 > > The address from where I subscribe the conference event might=20 > > be diffrent to the addres from where I'm joining to the conference. > >=20 > > BR, > > Jari=20 > >=20 > > > -----Original Message----- > > > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On=20 > > Behalf Of ext > > > hisham.khartabil@nokia.com > > > Sent: 15 December, 2003 14:55 > > > To: xcon@ietf.org > > > Subject: [XCON] CPCP Requirement: Conference package subscribers > > >=20 > > >=20 > > > This is in reference to requirement REQ-H5 in=20 > > >=20 http://www.ietf.org/internet-drafts/draft-ietf-xcon-cpcp-reqs-00.txt > >=20 > > REQ-H5: It SHOULD be possible to define users who are allowed to > > subscribe to conference event package [4] > >=20 > > Should this be a separate list? or should a combination of=20 > > Dial-out list, Dial-in list be sufficient? i.e. only=20 > > participants and potential participants can subscribe to the=20 > > conference event package (outside users not allowed)? > >=20 > > In any case, I think the requirement needs to stay, but needs=20 > > rewording according to the conclusions we come up with that=20 > > answer the above question. > >=20 > > Regards, > > Hisham > >=20 > > _______________________________________________ > > XCON mailing list > > XCON@ietf.org > > https://www1.ietf.org/mailman/listinfo/xcon > >=20 >=20 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Mon Dec 15 09:02:32 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08453 for ; Mon, 15 Dec 2003 09:02:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVtIR-0004Ol-Gg for xcon-archive@odin.ietf.org; Mon, 15 Dec 2003 09:02:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBFE23hj016901 for xcon-archive@odin.ietf.org; Mon, 15 Dec 2003 09:02:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVtIR-0004OW-0A for xcon-web-archive@optimus.ietf.org; Mon, 15 Dec 2003 09:02:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08446 for ; Mon, 15 Dec 2003 09:02:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AVtIP-0004wg-00 for xcon-web-archive@ietf.org; Mon, 15 Dec 2003 09:02:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AVtIP-0004wd-00 for xcon-web-archive@ietf.org; Mon, 15 Dec 2003 09:02:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVtIP-0004OG-S2; Mon, 15 Dec 2003 09:02:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVtHW-0004Nm-Tx for xcon@optimus.ietf.org; Mon, 15 Dec 2003 09:01:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08441 for ; Mon, 15 Dec 2003 09:01:04 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AVtHV-0004wM-00 for xcon@ietf.org; Mon, 15 Dec 2003 09:01:05 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AVtHU-0004wJ-00 for xcon@ietf.org; Mon, 15 Dec 2003 09:01:04 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hBFE12H25220 for ; Mon, 15 Dec 2003 16:01:02 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 15 Dec 2003 16:01:02 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 15 Dec 2003 16:01:02 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] CPCP Requirement: Conference package subscribers Date: Mon, 15 Dec 2003 16:01:01 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB70118B147@esebe019.ntc.nokia.com> Thread-Topic: CPCP Requirement: Conference package subscribers Thread-Index: AcPDCqKXFQaTbjOoSKCVoG8EwWWp/wAAMiCAAAAch1AAAY48IAAAFwDA To: , X-OriginalArrivalTime: 15 Dec 2003 14:01:02.0013 (UTC) FILETIME=[DFA05ED0:01C3C313] Content-Transfer-Encoding: quoted-printable Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable I think I understand what you're saying now: You are talking about the = participant having 2 different identities, one is a SIP URI and the = other is a TEL URI. I originally thought you are talking about the = conference focus itself having 2 URIs. If the dial-out list has your TEL URI, and we use the dial-out and = dial-in list as indicators to who is allowed to subscribe to a = conference package, then your question is: how does the focus know that = the SUBSCRIBE that carries your SIP URI is you when it only has your TEL = URI? I have 2 solutions: 1. Use your TEL URI in the SUBSCRIBE. Why would you use your SIP URI? = You certainly don't have to. 2. Have the dial-out list carry both your TEL and SIP URIs. I think option 1 is far more superior. My original question was: are there any scenarios where a conference = state subscriber may not be a potential participant?=20 Another question: Are there any scenarios where the participant is not = allowed to subscribe to the conference package. If the answer to the above 2 questions is yes, then we need a separate = privilege list for conference package subscribers. Regards, Hisham > -----Original Message----- > From: Mutikainen Jari (NMP-MSW/Helsinki)=20 > Sent: 15.December.2003 15:49 > To: Khartabil Hisham (NMP-MSW/Helsinki); xcon@ietf.org > Subject: RE: [XCON] CPCP Requirement: Conference package subscribers >=20 >=20 > I might want to follow the conference status (and manage it=20 > if I'm the host) from my PC client, and participate from a=20 > legacy mobile/PSTN device. Even if I'm using a single device,=20 > I might have a device that does not support VoIP but supports=20 > non-RT SIP, so I'm using my SIP subscription and it's SIP URI=20 > to subscribe, but Tel URI to join.=20 >=20 > Now, the only way to tie these is that we have a separate=20 > list for participants that are allowed to subscribe? In=20 > dial-in case it could be possible to put both URIs to the=20 > Dial-In list, but in Dial-out case it is impossible, as the=20 > server tries to invite both, even they mean a single participant? >=20 > BR, > Jari >=20 > > -----Original Message----- > > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On=20 > Behalf Of ext > > hisham.khartabil@nokia.com > > Sent: 15 December, 2003 15:06 > > To: Mutikainen Jari (NMP-MSW/Helsinki); xcon@ietf.org > > Subject: RE: [XCON] CPCP Requirement: Conference package subscribers > >=20 > >=20 > > Jari, > >=20 > > You are right, if you use a non-sip protocol to join the conference. > >=20 > > In any case, this is not related to the questions I ask that=20 > > are related who is allowed to subscribe to the conference=20 > > state event package. > >=20 > > Regards, > > Hisham > >=20 > > > -----Original Message----- > > > From: Mutikainen Jari (NMP-MSW/Helsinki)=20 > > > Sent: 15.December.2003 15:02 > > > To: Khartabil Hisham (NMP-MSW/Helsinki); xcon@ietf.org > > > Subject: RE: [XCON] CPCP Requirement: Conference package=20 > subscribers > > >=20 > > >=20 > > > The address from where I subscribe the conference event might=20 > > > be diffrent to the addres from where I'm joining to the=20 > conference. > > >=20 > > > BR, > > > Jari=20 > > >=20 > > > > -----Original Message----- > > > > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On=20 > > > Behalf Of ext > > > > hisham.khartabil@nokia.com > > > > Sent: 15 December, 2003 14:55 > > > > To: xcon@ietf.org > > > > Subject: [XCON] CPCP Requirement: Conference package subscribers > > > >=20 > > > >=20 > > > > This is in reference to requirement REQ-H5 in=20 > > > >=20 > http://www.ietf.org/internet-drafts/draft-ietf-xcon-cpcp-reqs-00.txt > > >=20 > > > REQ-H5: It SHOULD be possible to define users who are=20 > allowed to > > > subscribe to conference event package [4] > > >=20 > > > Should this be a separate list? or should a combination of=20 > > > Dial-out list, Dial-in list be sufficient? i.e. only=20 > > > participants and potential participants can subscribe to the=20 > > > conference event package (outside users not allowed)? > > >=20 > > > In any case, I think the requirement needs to stay, but needs=20 > > > rewording according to the conclusions we come up with that=20 > > > answer the above question. > > >=20 > > > Regards, > > > Hisham > > >=20 > > > _______________________________________________ > > > XCON mailing list > > > XCON@ietf.org > > > https://www1.ietf.org/mailman/listinfo/xcon > > >=20 > >=20 >=20 > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon >=20 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Mon Dec 15 09:10:35 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08583 for ; Mon, 15 Dec 2003 09:10:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVtQE-0004oR-Lm for xcon-archive@odin.ietf.org; Mon, 15 Dec 2003 09:10:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBFEA6OV018493 for xcon-archive@odin.ietf.org; Mon, 15 Dec 2003 09:10:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVtQE-0004oC-4a for xcon-web-archive@optimus.ietf.org; Mon, 15 Dec 2003 09:10:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08580 for ; Mon, 15 Dec 2003 09:10:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AVtQC-000546-00 for xcon-web-archive@ietf.org; Mon, 15 Dec 2003 09:10:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AVtQC-000543-00 for xcon-web-archive@ietf.org; Mon, 15 Dec 2003 09:10:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVtQA-0004mS-6X; Mon, 15 Dec 2003 09:10:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVtPT-0004lv-1b for xcon@optimus.ietf.org; Mon, 15 Dec 2003 09:09:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08569 for ; Mon, 15 Dec 2003 09:09:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AVtPR-000537-00 for xcon@ietf.org; Mon, 15 Dec 2003 09:09:17 -0500 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 1AVtPQ-00052g-00 for xcon@ietf.org; Mon, 15 Dec 2003 09:09:16 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA17454; Mon, 15 Dec 2003 09:08:42 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA05116; Mon, 15 Dec 2003 09:08:42 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Mon, 15 Dec 2003 09:08:42 -0500 Message-ID: <313680C9A886D511A06000204840E1CF070B61E7@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'hisham.khartabil@nokia.com'" , Jari.Mutikainen@nokia.com, xcon@ietf.org Subject: RE: [XCON] CPCP Requirement: Conference package subscribers Date: Mon, 15 Dec 2003 09:08:41 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , I didn't read Jari's answer the same way. I think you could easily have a PC app that was not a "participant", in that it never sends or receives media, but does: Read and Modify Conference Policy Read and Modify Media Policy Read and Modify whatever floor control mechanism there is This would be a PC app for a "dumb" phone. The phone is the "participant". It would have a dialog with the focus, and send/receive media. It would be conference un-aware. So, the PC app has to be able to subscribe to the conference package, but is neither a dial in, nor a dial out participant. Brian > -----Original Message----- > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > Sent: Monday, December 15, 2003 9:01 AM > To: Jari.Mutikainen@nokia.com; xcon@ietf.org > Subject: RE: [XCON] CPCP Requirement: Conference package subscribers > > > I think I understand what you're saying now: You are talking > about the participant having 2 different identities, one is a > SIP URI and the other is a TEL URI. I originally thought you > are talking about the conference focus itself having 2 URIs. > > If the dial-out list has your TEL URI, and we use the > dial-out and dial-in list as indicators to who is allowed to > subscribe to a conference package, then your question is: how > does the focus know that the SUBSCRIBE that carries your SIP > URI is you when it only has your TEL URI? > > I have 2 solutions: > > 1. Use your TEL URI in the SUBSCRIBE. Why would you use your > SIP URI? You certainly don't have to. > 2. Have the dial-out list carry both your TEL and SIP URIs. > > I think option 1 is far more superior. > > My original question was: are there any scenarios where a > conference state subscriber may not be a potential participant? > > Another question: Are there any scenarios where the > participant is not allowed to subscribe to the conference package. > > If the answer to the above 2 questions is yes, then we need a > separate privilege list for conference package subscribers. > > Regards, > Hisham > > > -----Original Message----- > > From: Mutikainen Jari (NMP-MSW/Helsinki) > > Sent: 15.December.2003 15:49 > > To: Khartabil Hisham (NMP-MSW/Helsinki); xcon@ietf.org > > Subject: RE: [XCON] CPCP Requirement: Conference package subscribers > > > > > > I might want to follow the conference status (and manage it > > if I'm the host) from my PC client, and participate from a > > legacy mobile/PSTN device. Even if I'm using a single device, > > I might have a device that does not support VoIP but supports > > non-RT SIP, so I'm using my SIP subscription and it's SIP URI > > to subscribe, but Tel URI to join. > > > > Now, the only way to tie these is that we have a separate > > list for participants that are allowed to subscribe? In > > dial-in case it could be possible to put both URIs to the > > Dial-In list, but in Dial-out case it is impossible, as the > > server tries to invite both, even they mean a single participant? > > > > BR, > > Jari > > > > > -----Original Message----- > > > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On > > Behalf Of ext > > > hisham.khartabil@nokia.com > > > Sent: 15 December, 2003 15:06 > > > To: Mutikainen Jari (NMP-MSW/Helsinki); xcon@ietf.org > > > Subject: RE: [XCON] CPCP Requirement: Conference package > subscribers > > > > > > > > > Jari, > > > > > > You are right, if you use a non-sip protocol to join the > conference. > > > > > > In any case, this is not related to the questions I ask that > > > are related who is allowed to subscribe to the conference > > > state event package. > > > > > > Regards, > > > Hisham > > > > > > > -----Original Message----- > > > > From: Mutikainen Jari (NMP-MSW/Helsinki) > > > > Sent: 15.December.2003 15:02 > > > > To: Khartabil Hisham (NMP-MSW/Helsinki); xcon@ietf.org > > > > Subject: RE: [XCON] CPCP Requirement: Conference package > > subscribers > > > > > > > > > > > > The address from where I subscribe the conference event might > > > > be diffrent to the addres from where I'm joining to the > > conference. > > > > > > > > BR, > > > > Jari > > > > > > > > > -----Original Message----- > > > > > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On > > > > Behalf Of ext > > > > > hisham.khartabil@nokia.com > > > > > Sent: 15 December, 2003 14:55 > > > > > To: xcon@ietf.org > > > > > Subject: [XCON] CPCP Requirement: Conference package > subscribers > > > > > > > > > > > > > > > This is in reference to requirement REQ-H5 in > > > > > > > http://www.ietf.org/internet-drafts/draft-ietf-xcon-cpcp-reqs-00.txt > > > > > > > > REQ-H5: It SHOULD be possible to define users who are > > allowed to > > > > subscribe to conference event package [4] > > > > > > > > Should this be a separate list? or should a combination of > > > > Dial-out list, Dial-in list be sufficient? i.e. only > > > > participants and potential participants can subscribe to the > > > > conference event package (outside users not allowed)? > > > > > > > > In any case, I think the requirement needs to stay, but needs > > > > rewording according to the conclusions we come up with that > > > > answer the above question. > > > > > > > > Regards, > > > > Hisham > > > > > > > > _______________________________________________ > > > > XCON mailing list > > > > XCON@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/xcon > > > > > > > > > > > _______________________________________________ > > XCON mailing list > > XCON@ietf.org > > https://www1.ietf.org/mailman/listinfo/xcon > > > > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon > _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Mon Dec 15 09:12:33 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08660 for ; Mon, 15 Dec 2003 09:12:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVtS8-0004sy-Rx for xcon-archive@odin.ietf.org; Mon, 15 Dec 2003 09:12:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBFEC4Yf018774 for xcon-archive@odin.ietf.org; Mon, 15 Dec 2003 09:12:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVtS8-0004sj-ES for xcon-web-archive@optimus.ietf.org; Mon, 15 Dec 2003 09:12:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08639 for ; Mon, 15 Dec 2003 09:12:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AVtS5-00055Q-00 for xcon-web-archive@ietf.org; Mon, 15 Dec 2003 09:12:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AVtS4-00055N-00 for xcon-web-archive@ietf.org; Mon, 15 Dec 2003 09:12:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVtS5-0004rU-NA; Mon, 15 Dec 2003 09:12:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVtS0-0004qw-Gb for xcon@optimus.ietf.org; Mon, 15 Dec 2003 09:11:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08632 for ; Mon, 15 Dec 2003 09:11:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AVtRy-00055E-00 for xcon@ietf.org; Mon, 15 Dec 2003 09:11:54 -0500 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 1AVtRx-00055B-00 for xcon@ietf.org; Mon, 15 Dec 2003 09:11:54 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA17504; Mon, 15 Dec 2003 09:11:07 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA05237; Mon, 15 Dec 2003 09:10:16 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Mon, 15 Dec 2003 09:10:16 -0500 Message-ID: <313680C9A886D511A06000204840E1CF070B61E8@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'hisham.khartabil@nokia.com'" , xcon@ietf.org Subject: RE: [XCON] CPCP Requirement: Anonymous participants Date: Mon, 15 Dec 2003 09:10:13 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , I agree (1) is not necessary. I think (2) is necessary to allow construction of a conference control app that is independent of a conference service implementation. Brian > -----Original Message----- > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > Sent: Monday, December 15, 2003 7:54 AM > To: xcon@ietf.org > Subject: [XCON] CPCP Requirement: Anonymous participants > > > This is the first of a series of emails discussing Conference > Policy Requirements. Your engagement is appreciated. > > This is in reference to requirements REQ-A6 and REQ-E9 in > http://www.ietf.org/internet-drafts/draft-ietf-xcon-cpcp-reqs-00.txt > > REQ-A6: It SHOULD be possible to anonymously participate in a > conference. > > REQ-E9: It MUST be possible to allow and disallow anonymous > membership in a conference. > > Should a conference policy, using CPCP, specify if anonymous > participants are allowed to join a conference? Or should this > be a local policy at the server? > > There are 2 types of anonymous participants: > > 1. ones that joins a conference using a http digest username > of "anonymous" and no password > 2. ones that join with a proper username and password, but > hide their identity using anonynous@somewhere.com in the > From-header of a SIP INVITE. The conference state package > notifications shows them as anonymous participants. > > I don't think we need to allow 1. Either a conference > requires everyone to know the username and password of the > conference, or does not require digest authentication at all. > > 2 can be provided, but we need consensus that this is a > useful feature. > > Regards, > Hisham > > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon > _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Mon Dec 15 09:14:31 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08745 for ; Mon, 15 Dec 2003 09:14:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVtU3-0004zC-7w for xcon-archive@odin.ietf.org; Mon, 15 Dec 2003 09:14:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBFEE2te019142 for xcon-archive@odin.ietf.org; Mon, 15 Dec 2003 09:14:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVtU2-0004yd-6u for xcon-web-archive@optimus.ietf.org; Mon, 15 Dec 2003 09:14:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08741 for ; Mon, 15 Dec 2003 09:13:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AVtU0-00057Z-00 for xcon-web-archive@ietf.org; Mon, 15 Dec 2003 09:14:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AVtTz-00057W-00 for xcon-web-archive@ietf.org; Mon, 15 Dec 2003 09:13:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVtU0-0004yM-MW; Mon, 15 Dec 2003 09:14:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVtTq-0004w4-GY for xcon@optimus.ietf.org; Mon, 15 Dec 2003 09:13:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08725 for ; Mon, 15 Dec 2003 09:13:48 -0500 (EST) From: Jari.Mutikainen@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AVtTo-00056f-00 for xcon@ietf.org; Mon, 15 Dec 2003 09:13:48 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AVtTo-00056c-00 for xcon@ietf.org; Mon, 15 Dec 2003 09:13:48 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hBFEDjH12828 for ; Mon, 15 Dec 2003 16:13:45 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 15 Dec 2003 16:13:44 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 15 Dec 2003 16:13:42 +0200 Received: from esebe001.NOE.Nokia.com ([172.21.138.30]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 15 Dec 2003 16:13:42 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] CPCP Requirement: Conference package subscribers Date: Mon, 15 Dec 2003 16:13:42 +0200 Message-ID: <05DAF85DFD6A9940B7C90667D4624F0D016929D5@esebe001> Thread-Topic: CPCP Requirement: Conference package subscribers Thread-Index: AcPDCqKXFQaTbjOoSKCVoG8EwWWp/wAAMiCAAAAch1AAAY48IAAAFwDAAACa5WA= To: , X-OriginalArrivalTime: 15 Dec 2003 14:13:42.0842 (UTC) FILETIME=[A51DA9A0:01C3C315] Content-Transfer-Encoding: quoted-printable Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Inline: > -----Original Message----- > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On Behalf Of ext > hisham.khartabil@nokia.com > Sent: 15 December, 2003 16:01 > To: Mutikainen Jari (NMP-MSW/Helsinki); xcon@ietf.org > Subject: RE: [XCON] CPCP Requirement: Conference package subscribers >=20 >=20 > I think I understand what you're saying now: You are talking=20 > about the participant having 2 different identities, one is a=20 > SIP URI and the other is a TEL URI. I originally thought you=20 > are talking about the conference focus itself having 2 URIs. >=20 > If the dial-out list has your TEL URI, and we use the=20 > dial-out and dial-in list as indicators to who is allowed to=20 > subscribe to a conference package, then your question is: how=20 > does the focus know that the SUBSCRIBE that carries your SIP=20 > URI is you when it only has your TEL URI? >=20 > I have 2 solutions: >=20 > 1. Use your TEL URI in the SUBSCRIBE. Why would you use your=20 > SIP URI? You certainly don't have to. At least in IMS this is impossible. I cannot take my grand ma's PSTN = phone, write down it's E.164 number, and register from my SIP client = using this E.164 number. In my understanding the IMS provider allows = registration only from tel URIs it has allocated to me. > 2. Have the dial-out list carry both your TEL and SIP URIs. And to which one the server dials? Both? BR, Jari >=20 > I think option 1 is far more superior. >=20 > My original question was: are there any scenarios where a=20 > conference state subscriber may not be a potential participant?=20 >=20 > Another question: Are there any scenarios where the=20 > participant is not allowed to subscribe to the conference package. >=20 > If the answer to the above 2 questions is yes, then we need a=20 > separate privilege list for conference package subscribers. >=20 > Regards, > Hisham >=20 > > -----Original Message----- > > From: Mutikainen Jari (NMP-MSW/Helsinki)=20 > > Sent: 15.December.2003 15:49 > > To: Khartabil Hisham (NMP-MSW/Helsinki); xcon@ietf.org > > Subject: RE: [XCON] CPCP Requirement: Conference package subscribers > >=20 > >=20 > > I might want to follow the conference status (and manage it=20 > > if I'm the host) from my PC client, and participate from a=20 > > legacy mobile/PSTN device. Even if I'm using a single device,=20 > > I might have a device that does not support VoIP but supports=20 > > non-RT SIP, so I'm using my SIP subscription and it's SIP URI=20 > > to subscribe, but Tel URI to join.=20 > >=20 > > Now, the only way to tie these is that we have a separate=20 > > list for participants that are allowed to subscribe? In=20 > > dial-in case it could be possible to put both URIs to the=20 > > Dial-In list, but in Dial-out case it is impossible, as the=20 > > server tries to invite both, even they mean a single participant? > >=20 > > BR, > > Jari > >=20 > > > -----Original Message----- > > > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On=20 > > Behalf Of ext > > > hisham.khartabil@nokia.com > > > Sent: 15 December, 2003 15:06 > > > To: Mutikainen Jari (NMP-MSW/Helsinki); xcon@ietf.org > > > Subject: RE: [XCON] CPCP Requirement: Conference package=20 > subscribers > > >=20 > > >=20 > > > Jari, > > >=20 > > > You are right, if you use a non-sip protocol to join the=20 > conference. > > >=20 > > > In any case, this is not related to the questions I ask that=20 > > > are related who is allowed to subscribe to the conference=20 > > > state event package. > > >=20 > > > Regards, > > > Hisham > > >=20 > > > > -----Original Message----- > > > > From: Mutikainen Jari (NMP-MSW/Helsinki)=20 > > > > Sent: 15.December.2003 15:02 > > > > To: Khartabil Hisham (NMP-MSW/Helsinki); xcon@ietf.org > > > > Subject: RE: [XCON] CPCP Requirement: Conference package=20 > > subscribers > > > >=20 > > > >=20 > > > > The address from where I subscribe the conference event might=20 > > > > be diffrent to the addres from where I'm joining to the=20 > > conference. > > > >=20 > > > > BR, > > > > Jari=20 > > > >=20 > > > > > -----Original Message----- > > > > > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On=20 > > > > Behalf Of ext > > > > > hisham.khartabil@nokia.com > > > > > Sent: 15 December, 2003 14:55 > > > > > To: xcon@ietf.org > > > > > Subject: [XCON] CPCP Requirement: Conference package=20 > subscribers > > > > >=20 > > > > >=20 > > > > > This is in reference to requirement REQ-H5 in=20 > > > > >=20 > > http://www.ietf.org/internet-drafts/draft-ietf-xcon-cpcp-reqs-00.txt > > > >=20 > > > > REQ-H5: It SHOULD be possible to define users who are=20 > > allowed to > > > > subscribe to conference event package [4] > > > >=20 > > > > Should this be a separate list? or should a combination of=20 > > > > Dial-out list, Dial-in list be sufficient? i.e. only=20 > > > > participants and potential participants can subscribe to the=20 > > > > conference event package (outside users not allowed)? > > > >=20 > > > > In any case, I think the requirement needs to stay, but needs=20 > > > > rewording according to the conclusions we come up with that=20 > > > > answer the above question. > > > >=20 > > > > Regards, > > > > Hisham > > > >=20 > > > > _______________________________________________ > > > > XCON mailing list > > > > XCON@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/xcon > > > >=20 > > >=20 > >=20 > > _______________________________________________ > > XCON mailing list > > XCON@ietf.org > > https://www1.ietf.org/mailman/listinfo/xcon > >=20 >=20 > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon >=20 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Mon Dec 15 09:20:37 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08876 for ; Mon, 15 Dec 2003 09:20:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVtZv-0005CR-W3 for xcon-archive@odin.ietf.org; Mon, 15 Dec 2003 09:20:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBFEK7c5019977 for xcon-archive@odin.ietf.org; Mon, 15 Dec 2003 09:20:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVtZt-0005Am-Jy for xcon-web-archive@optimus.ietf.org; Mon, 15 Dec 2003 09:20:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08853 for ; Mon, 15 Dec 2003 09:20:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AVtZr-0005CH-00 for xcon-web-archive@ietf.org; Mon, 15 Dec 2003 09:20:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AVtZr-0005CE-00 for xcon-web-archive@ietf.org; Mon, 15 Dec 2003 09:20:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVtZs-00059E-64; Mon, 15 Dec 2003 09:20:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVtZF-00056z-BG for xcon@optimus.ietf.org; Mon, 15 Dec 2003 09:19:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08805 for ; Mon, 15 Dec 2003 09:19:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AVtZC-00059n-00 for xcon@ietf.org; Mon, 15 Dec 2003 09:19:22 -0500 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 1AVtZ1-00059U-00 for xcon@ietf.org; Mon, 15 Dec 2003 09:19:11 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA17765; Mon, 15 Dec 2003 09:17:47 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA06236; Mon, 15 Dec 2003 09:17:10 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Mon, 15 Dec 2003 09:17:09 -0500 Message-ID: <313680C9A886D511A06000204840E1CF070B61E9@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'hisham.khartabil@nokia.com'" , xcon@ietf.org Subject: RE: [XCON] CPCP Requirement: Hidden Participants Date: Mon, 15 Dec 2003 09:17:08 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , I think that this capability could be deferred. I think it would be acceptable to allow a user to hide himself, and I think we need to allow one user to hide another (because of the PC app for a dumb phone problem). I think getting into permission issues is complicated. I'm puzzled by "the list of hidden users is manipulated by a privileged user..." I think that such a statement opens a large box of complication in specification. I would prefer, for now, to not have any specified behavior for anything like a privileged user. Brian > -----Original Message----- > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > Sent: Monday, December 15, 2003 7:55 AM > To: xcon@ietf.org > Subject: [XCON] CPCP Requirement: Hidden Participants > > > This is in reference to requirements REQ-A7 and REQ-E10 in > http://www.ietf.org/internet-drafts/draft-ietf-xcon-cpcp-reqs-00.txt > > REQ-A7: It SHOULD be possible to participate in a conference as a > hidden user. Hidden user is present in a conference, but > his presence > is not revealed. > > REQ-E10: It MUST be possible to allow and disallow hidden > membership > in a conference. > > Should a conference policy, using CPCP, specify if a user can > be hidden? This means that the conference state package does > not report the participation on the hidden user. CPCP is used > to identify which users are hidden. The list of hidden users > is only manipulated by a privileged user such as the moderator. > > Regards, > Hisham > > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon > _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Mon Dec 15 09:21:32 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08908 for ; Mon, 15 Dec 2003 09:21:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVtaq-0005Fb-PY for xcon-archive@odin.ietf.org; Mon, 15 Dec 2003 09:21:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBFEL4em020177 for xcon-archive@odin.ietf.org; Mon, 15 Dec 2003 09:21:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVtaq-0005FM-Ko for xcon-web-archive@optimus.ietf.org; Mon, 15 Dec 2003 09:21:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08905 for ; Mon, 15 Dec 2003 09:21:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AVtao-0005DE-00 for xcon-web-archive@ietf.org; Mon, 15 Dec 2003 09:21:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AVtao-0005DB-00 for xcon-web-archive@ietf.org; Mon, 15 Dec 2003 09:21:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVtao-0005Ds-Ex; Mon, 15 Dec 2003 09:21:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVtaJ-0005D5-3S for xcon@optimus.ietf.org; Mon, 15 Dec 2003 09:20:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08865 for ; Mon, 15 Dec 2003 09:20:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AVtaH-0005Cb-00 for xcon@ietf.org; Mon, 15 Dec 2003 09:20:29 -0500 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 1AVtaG-0005C5-00 for xcon@ietf.org; Mon, 15 Dec 2003 09:20:28 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA17858; Mon, 15 Dec 2003 09:19:39 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA06636; Mon, 15 Dec 2003 09:19:33 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Mon, 15 Dec 2003 09:19:33 -0500 Message-ID: <313680C9A886D511A06000204840E1CF070B61EA@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'hisham.khartabil@nokia.com'" , xcon@ietf.org Subject: RE: [XCON] CPCP Requirement: Conference and Host Info Date: Mon, 15 Dec 2003 09:19:32 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , I think its simple to have these. If we were prioritizing, I'd leave the last two off, but I don't see any reason to not implement them. Brian > -----Original Message----- > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > Sent: Monday, December 15, 2003 7:57 AM > To: xcon@ietf.org > Subject: [XCON] CPCP Requirement: Conference and Host Info > > > This is in reference to requirements REQ-B1 to REG-B6, and > REG-B10 in > http://www.ietf.org/internet-drafts/draft-ietf-xcon-cpcp-reqs-00.txt > > REQ-B1: It MUST be possible to set, modify and delete a conference > Subject. > > REQ-B2: It MUST be possible to set, modify and delete > conference URI > display name. > > REQ-B3: It MUST be possible to set, modify and delete conference > creator information. > > REQ-B4: It MUST be possible to set, modify and delete > conference URI > link for more information. > > REQ-B5: It MUST be possible to set, modify and delete > conference host > contact information. > > REQ-B6: It MUST be possible to set, modify and delete short > conference session description. > > REQ-B10: It SHOULD be possible to set, modify and delete conference > Keywords. (This may be useful e.g. for search engines). > > I think a conference subject and display name as well as > conference session description are useful. Perhaps the > conference session description can appear on a conference web > sight. What about conference host and creator information? > > I would like opinions on what people deem necessary > information. Of course, we can have all if needed. > > Regards, > Hisham > > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon > _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Mon Dec 15 09:23:31 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08971 for ; Mon, 15 Dec 2003 09:23:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVtck-0005JQ-Jw for xcon-archive@odin.ietf.org; Mon, 15 Dec 2003 09:23:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBFEN2bb020414 for xcon-archive@odin.ietf.org; Mon, 15 Dec 2003 09:23:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVtck-0005JB-EU for xcon-web-archive@optimus.ietf.org; Mon, 15 Dec 2003 09:23:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08964 for ; Mon, 15 Dec 2003 09:22:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AVtci-0005Fx-00 for xcon-web-archive@ietf.org; Mon, 15 Dec 2003 09:23:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AVtch-0005Fr-00 for xcon-web-archive@ietf.org; Mon, 15 Dec 2003 09:22:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVtci-0005Hy-SK; Mon, 15 Dec 2003 09:23:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVtcZ-0005HP-9S for xcon@optimus.ietf.org; Mon, 15 Dec 2003 09:22:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08954 for ; Mon, 15 Dec 2003 09:22:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AVtcX-0005EN-00 for xcon@ietf.org; Mon, 15 Dec 2003 09:22:49 -0500 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 1AVtcW-0005Dp-00 for xcon@ietf.org; Mon, 15 Dec 2003 09:22:49 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA17978; Mon, 15 Dec 2003 09:22:15 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA07017; Mon, 15 Dec 2003 09:22:14 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Mon, 15 Dec 2003 09:22:14 -0500 Message-ID: <313680C9A886D511A06000204840E1CF070B61EB@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'hisham.khartabil@nokia.com'" , xcon@ietf.org Subject: RE: [XCON] CPCP Requirement: Max number of participants Date: Mon, 15 Dec 2003 09:22:13 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , I think this is necessary. We just had a discussion of resource reservation. This is the primary metric for any kind of resource calculation (number of "ports" needed). It's clearly complicated to compute actual resources needed on most implementations without knowing codecs, VAD, ..., every simple algorithm is based on port count. Brian > -----Original Message----- > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > Sent: Monday, December 15, 2003 7:57 AM > To: xcon@ietf.org > Subject: [XCON] CPCP Requirement: Max number of participants > > > This is in reference to requirements REQ-B7 in > http://www.ietf.org/internet-drafts/draft-ietf-xcon-cpcp-reqs-00.txt > > REQ-B7: It SHOULD be possible to set, modify and delete > the parameter > for max number of conference participants. This defines how many > users at max can be present at the same time. > > Should a conference policy, using CPCP, specify the max > number of participants in a conference? (This does not > override a server policy, but limits it, if the user does not > want too many participants). > > It might be useful, but is it necessary? > > Regards, > Hisham > > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon > _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Mon Dec 15 09:26:34 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09133 for ; Mon, 15 Dec 2003 09:26:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVtfi-0005Se-IZ for xcon-archive@odin.ietf.org; Mon, 15 Dec 2003 09:26:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBFEQ6Za020986 for xcon-archive@odin.ietf.org; Mon, 15 Dec 2003 09:26:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVtfg-0005RE-W3 for xcon-web-archive@optimus.ietf.org; Mon, 15 Dec 2003 09:26:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09072 for ; Mon, 15 Dec 2003 09:26:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AVtfe-0005J7-00 for xcon-web-archive@ietf.org; Mon, 15 Dec 2003 09:26:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AVtfe-0005J4-00 for xcon-web-archive@ietf.org; Mon, 15 Dec 2003 09:26:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVtfe-0005Qe-6u; Mon, 15 Dec 2003 09:26:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVtfA-0005PM-SE for xcon@optimus.ietf.org; Mon, 15 Dec 2003 09:25:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09003 for ; Mon, 15 Dec 2003 09:25:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AVtf9-0005HK-00 for xcon@ietf.org; Mon, 15 Dec 2003 09:25:31 -0500 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 1AVtf8-0005H3-00 for xcon@ietf.org; Mon, 15 Dec 2003 09:25:30 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA18075; Mon, 15 Dec 2003 09:24:57 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA07399; Mon, 15 Dec 2003 09:24:56 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Mon, 15 Dec 2003 09:24:56 -0500 Message-ID: <313680C9A886D511A06000204840E1CF070B61EC@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'hisham.khartabil@nokia.com'" , xcon@ietf.org Subject: RE: [XCON] CPCP Requirement: de-activating a conference Date: Mon, 15 Dec 2003 09:24:55 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , Again, I'm worried about "privileged users". I think we need to finish some discussions we started a while ago that essentially are semantics. What is an "inactivated" conference, and how does it differ from a conference that can be re-instantiated (a weekly meeting for example)? Brian > -----Original Message----- > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > Sent: Monday, December 15, 2003 7:57 AM > To: xcon@ietf.org > Subject: [XCON] CPCP Requirement: de-activating a conference > > > This is in reference to requirement REQ-B9 in > http://www.ietf.org/internet-drafts/draft-ietf-xcon-cpcp-reqs-00.txt > > REQ-B9: It MUST be possible to inactive a conference for defined > period of time. > > There are start and stop times for a conference. A conference > might live for days, weeks or even months. Should a > conference policy, using CPCP, allow a privileged user to > de-activate a conference for a period of time within the > start and stop times of a conference? Examples are > administrator is performing some maintenance. > > Regards, > Hisham > > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon > _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Mon Dec 15 09:46:32 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10125 for ; Mon, 15 Dec 2003 09:46:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVtz2-0006jr-LZ for xcon-archive@odin.ietf.org; Mon, 15 Dec 2003 09:46:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBFEk4Kr025897 for xcon-archive@odin.ietf.org; Mon, 15 Dec 2003 09:46:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVtz2-0006jc-6O for xcon-web-archive@optimus.ietf.org; Mon, 15 Dec 2003 09:46:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10119 for ; Mon, 15 Dec 2003 09:46:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AVtz0-0005mp-00 for xcon-web-archive@ietf.org; Mon, 15 Dec 2003 09:46:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AVtz0-0005mm-00 for xcon-web-archive@ietf.org; Mon, 15 Dec 2003 09:46:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVtz0-0006in-Q8; Mon, 15 Dec 2003 09:46:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVtyk-0006i4-7K for xcon@optimus.ietf.org; Mon, 15 Dec 2003 09:45:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10113 for ; Mon, 15 Dec 2003 09:45:43 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AVtyi-0005m0-00 for xcon@ietf.org; Mon, 15 Dec 2003 09:45:44 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AVtyh-0005lw-00 for xcon@ietf.org; Mon, 15 Dec 2003 09:45:43 -0500 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hBFEjgn28144 for ; Mon, 15 Dec 2003 16:45:42 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 15 Dec 2003 16:45:42 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 15 Dec 2003 16:45:42 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] CPCP Requirement: Hidden Participants Date: Mon, 15 Dec 2003 16:45:41 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797516@esebe019.ntc.nokia.com> Thread-Topic: [XCON] CPCP Requirement: Hidden Participants Thread-Index: AcPDFm2SzC2Tw1ecR2a7HVjRAzLDKQAA1Vzg To: , X-OriginalArrivalTime: 15 Dec 2003 14:45:42.0194 (UTC) FILETIME=[1D238920:01C3C31A] Content-Transfer-Encoding: quoted-printable Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ext Rosen, Brian [mailto:Brian.Rosen@marconi.com] > Sent: 15.December.2003 16:17 > To: Khartabil Hisham (NMP-MSW/Helsinki); xcon@ietf.org > Subject: RE: [XCON] CPCP Requirement: Hidden Participants >=20 >=20 > I think that this capability could be deferred. Noted. > I think it would be acceptable to allow a user > to hide himself, and I think we need to allow > one user to hide another (because of the PC app > for a dumb phone problem). I think getting into > permission issues is complicated. >=20 > I'm puzzled by "the list of hidden users is > manipulated by a privileged user..." I think that > such a statement opens a large box of complication > in specification. I would prefer, for now, to > not have any specified behavior for anything > like a privileged user. =20 You can't have everyone manipulating the policy. We can define a = privileged user to be the moderator for now. /Hisham >=20 > Brian >=20 > > -----Original Message----- > > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > > Sent: Monday, December 15, 2003 7:55 AM > > To: xcon@ietf.org > > Subject: [XCON] CPCP Requirement: Hidden Participants > >=20 > >=20 > > This is in reference to requirements REQ-A7 and REQ-E10 in=20 > > http://www.ietf.org/internet-drafts/draft-ietf-xcon-cpcp-reqs-00.txt > >=20 > > REQ-A7: It SHOULD be possible to participate in a conference as a > > hidden user. Hidden user is present in a conference, but=20 > > his presence > > is not revealed. > >=20 > > REQ-E10: It MUST be possible to allow and disallow hidden=20 > > membership > > in a conference. > >=20 > > Should a conference policy, using CPCP, specify if a user can=20 > > be hidden? This means that the conference state package does=20 > > not report the participation on the hidden user. CPCP is used=20 > > to identify which users are hidden. The list of hidden users=20 > > is only manipulated by a privileged user such as the moderator. > >=20 > > Regards, > > Hisham > >=20 > > _______________________________________________ > > XCON mailing list > > XCON@ietf.org > > https://www1.ietf.org/mailman/listinfo/xcon > >=20 >=20 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Mon Dec 15 09:57:30 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10919 for ; Mon, 15 Dec 2003 09:57:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVu9e-00072J-Nt for xcon-archive@odin.ietf.org; Mon, 15 Dec 2003 09:57:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBFEv2kl027041 for xcon-archive@odin.ietf.org; Mon, 15 Dec 2003 09:57:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVu9e-000724-8a for xcon-web-archive@optimus.ietf.org; Mon, 15 Dec 2003 09:57:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10915 for ; Mon, 15 Dec 2003 09:56:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AVu9b-00069H-00 for xcon-web-archive@ietf.org; Mon, 15 Dec 2003 09:57:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AVu9b-00069E-00 for xcon-web-archive@ietf.org; Mon, 15 Dec 2003 09:56:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVu9c-00071s-N4; Mon, 15 Dec 2003 09:57:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVu9O-00071H-L5 for xcon@optimus.ietf.org; Mon, 15 Dec 2003 09:56:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10908 for ; Mon, 15 Dec 2003 09:56:43 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AVu9M-000699-00 for xcon@ietf.org; Mon, 15 Dec 2003 09:56:44 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AVu9L-000696-00 for xcon@ietf.org; Mon, 15 Dec 2003 09:56:43 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hBFEuen11298 for ; Mon, 15 Dec 2003 16:56:40 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 15 Dec 2003 16:56:39 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 15 Dec 2003 16:56:39 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 15 Dec 2003 16:56:39 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 15 Dec 2003 16:56:38 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797517@esebe019.ntc.nokia.com> Thread-Topic: CPCP Requirement: Repeat times Thread-Index: AcPDG6RweOPS3cmHRrevqnde2yWT2g== To: X-OriginalArrivalTime: 15 Dec 2003 14:56:39.0272 (UTC) FILETIME=[A4C9AE80:01C3C31B] Content-Transfer-Encoding: quoted-printable Subject: [XCON] CPCP Requirement: Repeat times Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable A conference has start and stop times. Although the current proposed = solution has repeat times (eg: meeting repeats weekly), there is no = requirement for such. Do we see a need for such capability using CPCP? If so, then we need to = add a requirement. Regards, Hisham _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Mon Dec 15 10:12:57 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08877 for ; Mon, 15 Dec 2003 09:20:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVtZx-0005Ck-3Y for xcon-archive@odin.ietf.org; Mon, 15 Dec 2003 09:20:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBFEK8cE019997 for xcon-archive@odin.ietf.org; Mon, 15 Dec 2003 09:20:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVtZw-0005CS-Au for xcon-web-archive@optimus.ietf.org; Mon, 15 Dec 2003 09:20:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08856 for ; Mon, 15 Dec 2003 09:20:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AVtZu-0005CN-00 for xcon-web-archive@ietf.org; Mon, 15 Dec 2003 09:20:06 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AVtZu-0005CK-00 for xcon-web-archive@ietf.org; Mon, 15 Dec 2003 09:20:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVtZu-0005Au-7g; Mon, 15 Dec 2003 09:20:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVtZS-00057S-8z for xcon@optimus.ietf.org; Mon, 15 Dec 2003 09:19:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08829 for ; Mon, 15 Dec 2003 09:19:35 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AVtZQ-0005Ao-00 for xcon@ietf.org; Mon, 15 Dec 2003 09:19:36 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AVtZP-0005Ah-00 for xcon@ietf.org; Mon, 15 Dec 2003 09:19:35 -0500 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hBFEJUn22397 for ; Mon, 15 Dec 2003 16:19:31 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 15 Dec 2003 16:19:28 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 15 Dec 2003 16:19:28 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] CPCP Requirement: Conference package subscribers Date: Mon, 15 Dec 2003 16:19:28 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB70118B148@esebe019.ntc.nokia.com> Thread-Topic: CPCP Requirement: Conference package subscribers Thread-Index: AcPDCqKXFQaTbjOoSKCVoG8EwWWp/wAAMiCAAAAch1AAAY48IAAAFwDAAACa5WAAAD9a4A== To: , X-OriginalArrivalTime: 15 Dec 2003 14:19:28.0661 (UTC) FILETIME=[733D7450:01C3C316] Content-Transfer-Encoding: quoted-printable Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Mutikainen Jari (NMP-MSW/Helsinki)=20 > Sent: 15.December.2003 16:14 > To: Khartabil Hisham (NMP-MSW/Helsinki); xcon@ietf.org > Subject: RE: [XCON] CPCP Requirement: Conference package subscribers >=20 >=20 > Inline: >=20 > > -----Original Message----- > > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On=20 > Behalf Of ext > > hisham.khartabil@nokia.com > > Sent: 15 December, 2003 16:01 > > To: Mutikainen Jari (NMP-MSW/Helsinki); xcon@ietf.org > > Subject: RE: [XCON] CPCP Requirement: Conference package subscribers > >=20 > >=20 > > I think I understand what you're saying now: You are talking=20 > > about the participant having 2 different identities, one is a=20 > > SIP URI and the other is a TEL URI. I originally thought you=20 > > are talking about the conference focus itself having 2 URIs. > >=20 > > If the dial-out list has your TEL URI, and we use the=20 > > dial-out and dial-in list as indicators to who is allowed to=20 > > subscribe to a conference package, then your question is: how=20 > > does the focus know that the SUBSCRIBE that carries your SIP=20 > > URI is you when it only has your TEL URI? > >=20 > > I have 2 solutions: > >=20 > > 1. Use your TEL URI in the SUBSCRIBE. Why would you use your=20 > > SIP URI? You certainly don't have to. >=20 > At least in IMS this is impossible. I cannot take my grand=20 > ma's PSTN phone, write down it's E.164 number, and register=20 > from my SIP client using this E.164 number. In my=20 > understanding the IMS provider allows registration only from=20 > tel URIs it has allocated to me. You and your grand mother are 2 different people with 2 different = identities, so you're grandmother's TEL URI needs to be on the dial-x = list. In this case, I see there is a need to have a conference package = subscriber list that is different that the dial-x lists since you are = not on those lists but want to subscribe to the package. >=20 > > 2. Have the dial-out list carry both your TEL and SIP URIs. >=20 > And to which one the server dials? Both? no, it picks one. Anyway, I agree we need a separate list. /Hisham >=20 > BR, > Jari >=20 > >=20 > > I think option 1 is far more superior. > >=20 > > My original question was: are there any scenarios where a=20 > > conference state subscriber may not be a potential participant?=20 > >=20 > > Another question: Are there any scenarios where the=20 > > participant is not allowed to subscribe to the conference package. > >=20 > > If the answer to the above 2 questions is yes, then we need a=20 > > separate privilege list for conference package subscribers. > >=20 > > Regards, > > Hisham > >=20 > > > -----Original Message----- > > > From: Mutikainen Jari (NMP-MSW/Helsinki)=20 > > > Sent: 15.December.2003 15:49 > > > To: Khartabil Hisham (NMP-MSW/Helsinki); xcon@ietf.org > > > Subject: RE: [XCON] CPCP Requirement: Conference package=20 > subscribers > > >=20 > > >=20 > > > I might want to follow the conference status (and manage it=20 > > > if I'm the host) from my PC client, and participate from a=20 > > > legacy mobile/PSTN device. Even if I'm using a single device,=20 > > > I might have a device that does not support VoIP but supports=20 > > > non-RT SIP, so I'm using my SIP subscription and it's SIP URI=20 > > > to subscribe, but Tel URI to join.=20 > > >=20 > > > Now, the only way to tie these is that we have a separate=20 > > > list for participants that are allowed to subscribe? In=20 > > > dial-in case it could be possible to put both URIs to the=20 > > > Dial-In list, but in Dial-out case it is impossible, as the=20 > > > server tries to invite both, even they mean a single participant? > > >=20 > > > BR, > > > Jari > > >=20 > > > > -----Original Message----- > > > > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On=20 > > > Behalf Of ext > > > > hisham.khartabil@nokia.com > > > > Sent: 15 December, 2003 15:06 > > > > To: Mutikainen Jari (NMP-MSW/Helsinki); xcon@ietf.org > > > > Subject: RE: [XCON] CPCP Requirement: Conference package=20 > > subscribers > > > >=20 > > > >=20 > > > > Jari, > > > >=20 > > > > You are right, if you use a non-sip protocol to join the=20 > > conference. > > > >=20 > > > > In any case, this is not related to the questions I ask that=20 > > > > are related who is allowed to subscribe to the conference=20 > > > > state event package. > > > >=20 > > > > Regards, > > > > Hisham > > > >=20 > > > > > -----Original Message----- > > > > > From: Mutikainen Jari (NMP-MSW/Helsinki)=20 > > > > > Sent: 15.December.2003 15:02 > > > > > To: Khartabil Hisham (NMP-MSW/Helsinki); xcon@ietf.org > > > > > Subject: RE: [XCON] CPCP Requirement: Conference package=20 > > > subscribers > > > > >=20 > > > > >=20 > > > > > The address from where I subscribe the conference event might=20 > > > > > be diffrent to the addres from where I'm joining to the=20 > > > conference. > > > > >=20 > > > > > BR, > > > > > Jari=20 > > > > >=20 > > > > > > -----Original Message----- > > > > > > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On=20 > > > > > Behalf Of ext > > > > > > hisham.khartabil@nokia.com > > > > > > Sent: 15 December, 2003 14:55 > > > > > > To: xcon@ietf.org > > > > > > Subject: [XCON] CPCP Requirement: Conference package=20 > > subscribers > > > > > >=20 > > > > > >=20 > > > > > > This is in reference to requirement REQ-H5 in=20 > > > > > >=20 > > >=20 http://www.ietf.org/internet-drafts/draft-ietf-xcon-cpcp-reqs-00.txt > > > >=20 > > > > REQ-H5: It SHOULD be possible to define users who are=20 > > allowed to > > > > subscribe to conference event package [4] > > > >=20 > > > > Should this be a separate list? or should a combination of=20 > > > > Dial-out list, Dial-in list be sufficient? i.e. only=20 > > > > participants and potential participants can subscribe to the=20 > > > > conference event package (outside users not allowed)? > > > >=20 > > > > In any case, I think the requirement needs to stay, but needs=20 > > > > rewording according to the conclusions we come up with that=20 > > > > answer the above question. > > > >=20 > > > > Regards, > > > > Hisham > > > >=20 > > > > _______________________________________________ > > > > XCON mailing list > > > > XCON@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/xcon > > > >=20 > > >=20 > >=20 > > _______________________________________________ > > XCON mailing list > > XCON@ietf.org > > https://www1.ietf.org/mailman/listinfo/xcon > >=20 >=20 > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon >=20 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Mon Dec 15 10:22:30 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13371 for ; Mon, 15 Dec 2003 10:22:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVuXr-0007vl-2X for xcon-archive@odin.ietf.org; Mon, 15 Dec 2003 10:22:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBFFM3sn030479 for xcon-archive@odin.ietf.org; Mon, 15 Dec 2003 10:22:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVuXq-0007vW-Th for xcon-web-archive@optimus.ietf.org; Mon, 15 Dec 2003 10:22:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13314 for ; Mon, 15 Dec 2003 10:21:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AVuXo-0006r9-00 for xcon-web-archive@ietf.org; Mon, 15 Dec 2003 10:22:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AVuXo-0006r6-00 for xcon-web-archive@ietf.org; Mon, 15 Dec 2003 10:22:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVuXp-0007vG-SI; Mon, 15 Dec 2003 10:22:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVuXK-0007sc-Ku for xcon@optimus.ietf.org; Mon, 15 Dec 2003 10:21:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13260 for ; Mon, 15 Dec 2003 10:21:27 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AVuXI-0006qk-00 for xcon@ietf.org; Mon, 15 Dec 2003 10:21:28 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AVuXH-0006qh-00 for xcon@ietf.org; Mon, 15 Dec 2003 10:21:27 -0500 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hBFFLQn11811 for ; Mon, 15 Dec 2003 17:21:26 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 15 Dec 2003 17:21:26 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 15 Dec 2003 17:21:25 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 15 Dec 2003 17:21:25 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] CPCP Requirement: de-activating a conference Date: Mon, 15 Dec 2003 17:21:24 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB70118B149@esebe019.ntc.nokia.com> Thread-Topic: [XCON] CPCP Requirement: de-activating a conference Thread-Index: AcPDF01AFj3nutCNQ1e4SVj29sUk2AABj9Jw To: , X-OriginalArrivalTime: 15 Dec 2003 15:21:25.0071 (UTC) FILETIME=[1A649DF0:01C3C31F] Content-Transfer-Encoding: quoted-printable Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ext Rosen, Brian [mailto:Brian.Rosen@marconi.com] > Sent: 15.December.2003 16:25 > To: Khartabil Hisham (NMP-MSW/Helsinki); xcon@ietf.org > Subject: RE: [XCON] CPCP Requirement: de-activating a conference >=20 >=20 > Again, I'm worried about "privileged users". I think we need=20 > to finish > some discussions we started a while ago that essentially are=20 > semantics. We can assume it is the moderator for now. > What is an "inactivated" conference, and how does it differ from a > conference that can be re-instantiated (a weekly meeting for example)? A long lived conference is one that runs for months (chat sessions on = the internet seem to run for that long). They are not repeated, but = instead are constantly running. An administrator, for maintenance reasons, might want to de-activate a = conference for a short period of time. Of course the administrator can kick everyone out by sending them BYE = requests and redefining the conference start time. But it has the = disadvantage that the inactivity time for maintenance cannot be = scheduled. Do we want to be able to schedule such event for long lived = conferences? Regards, Hisham >=20 > Brian >=20 > > -----Original Message----- > > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > > Sent: Monday, December 15, 2003 7:57 AM > > To: xcon@ietf.org > > Subject: [XCON] CPCP Requirement: de-activating a conference > >=20 > >=20 > > This is in reference to requirement REQ-B9 in=20 > > http://www.ietf.org/internet-drafts/draft-ietf-xcon-cpcp-reqs-00.txt > >=20 > > REQ-B9: It MUST be possible to inactive a conference for defined > > period of time. > >=20 > > There are start and stop times for a conference. A conference=20 > > might live for days, weeks or even months. Should a=20 > > conference policy, using CPCP, allow a privileged user to=20 > > de-activate a conference for a period of time within the=20 > > start and stop times of a conference? Examples are=20 > > administrator is performing some maintenance. > >=20 > > Regards, > > Hisham > >=20 > > _______________________________________________ > > XCON mailing list > > XCON@ietf.org > > https://www1.ietf.org/mailman/listinfo/xcon > >=20 >=20 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Mon Dec 15 11:09:29 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15085 for ; Mon, 15 Dec 2003 11:09:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVvHK-0001aQ-O7 for xcon-archive@odin.ietf.org; Mon, 15 Dec 2003 11:09:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBFG92Ua006091 for xcon-archive@odin.ietf.org; Mon, 15 Dec 2003 11:09:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVvHK-0001aA-HJ for xcon-web-archive@optimus.ietf.org; Mon, 15 Dec 2003 11:09:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15074 for ; Mon, 15 Dec 2003 11:08:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AVvHH-0007dz-00 for xcon-web-archive@ietf.org; Mon, 15 Dec 2003 11:08:59 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AVvHH-0007dv-00 for xcon-web-archive@ietf.org; Mon, 15 Dec 2003 11:08:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVvHJ-0001Zo-DI; Mon, 15 Dec 2003 11:09:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVvGo-0001ZE-VH for xcon@optimus.ietf.org; Mon, 15 Dec 2003 11:08:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15067 for ; Mon, 15 Dec 2003 11:08:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AVvGm-0007di-00 for xcon@ietf.org; Mon, 15 Dec 2003 11:08:28 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1AVvGl-0007bH-00 for xcon@ietf.org; Mon, 15 Dec 2003 11:08:27 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by sj-iport-5.cisco.com with ESMTP; 15 Dec 2003 16:08:44 +0000 Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hBFG7rDM008306; Mon, 15 Dec 2003 11:07:54 -0500 (EST) Received: from mhammer-w2k03.cisco.com (dhcp-hrn-64-100-229-166.cisco.com [64.100.229.166]) by fruitpie.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AVQ65604; Mon, 15 Dec 2003 08:07:52 -0800 (PST) Message-Id: <4.3.2.7.2.20031215110306.00b252c0@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 15 Dec 2003 11:07:52 -0500 To: "Rosen, Brian" From: Michael Hammer Subject: RE: [XCON] CPCP Requirement: Conference package subscribers Cc: "'hisham.khartabil@nokia.com'" , Jari.Mutikainen@nokia.com, xcon@ietf.org In-Reply-To: <313680C9A886D511A06000204840E1CF070B61E7@whq-msgusr-02.pit .comms.marconi.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , The terms "dial-in" and "dial-out" seem very media-specific, or at least connection-oriented-specific. Is it necessary to have this coupling? If so, then you would need to not only include details of the identity of the participant, but the nature of what they are enabled to do: connection-oriented media type (in/out) connectionless media control links, ... Perhaps this should be more of a single list of "participants" of any type, with added attributes about what they are permitted to do, who initiates communication. But, that is jumping to conclusions in the requirements. So, perhaps the requirement needs to be split apart. Mike At 09:08 AM 12/15/2003 -0500, Rosen, Brian wrote: >I didn't read Jari's answer the same way. > >I think you could easily have a PC app that was not a "participant", >in that it never sends or receives media, but does: > Read and Modify Conference Policy > Read and Modify Media Policy > Read and Modify whatever floor control mechanism there is > >This would be a PC app for a "dumb" phone. The phone is the "participant". >It would have a dialog with the focus, and send/receive media. It >would be conference un-aware. > >So, the PC app has to be able to subscribe to the conference package, >but is neither a dial in, nor a dial out participant. > >Brian > > > -----Original Message----- > > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > > Sent: Monday, December 15, 2003 9:01 AM > > To: Jari.Mutikainen@nokia.com; xcon@ietf.org > > Subject: RE: [XCON] CPCP Requirement: Conference package subscribers > > > > > > I think I understand what you're saying now: You are talking > > about the participant having 2 different identities, one is a > > SIP URI and the other is a TEL URI. I originally thought you > > are talking about the conference focus itself having 2 URIs. > > > > If the dial-out list has your TEL URI, and we use the > > dial-out and dial-in list as indicators to who is allowed to > > subscribe to a conference package, then your question is: how > > does the focus know that the SUBSCRIBE that carries your SIP > > URI is you when it only has your TEL URI? > > > > I have 2 solutions: > > > > 1. Use your TEL URI in the SUBSCRIBE. Why would you use your > > SIP URI? You certainly don't have to. > > 2. Have the dial-out list carry both your TEL and SIP URIs. > > > > I think option 1 is far more superior. > > > > My original question was: are there any scenarios where a > > conference state subscriber may not be a potential participant? > > > > Another question: Are there any scenarios where the > > participant is not allowed to subscribe to the conference package. > > > > If the answer to the above 2 questions is yes, then we need a > > separate privilege list for conference package subscribers. > > > > Regards, > > Hisham > > > > > -----Original Message----- > > > From: Mutikainen Jari (NMP-MSW/Helsinki) > > > Sent: 15.December.2003 15:49 > > > To: Khartabil Hisham (NMP-MSW/Helsinki); xcon@ietf.org > > > Subject: RE: [XCON] CPCP Requirement: Conference package subscribers > > > > > > > > > I might want to follow the conference status (and manage it > > > if I'm the host) from my PC client, and participate from a > > > legacy mobile/PSTN device. Even if I'm using a single device, > > > I might have a device that does not support VoIP but supports > > > non-RT SIP, so I'm using my SIP subscription and it's SIP URI > > > to subscribe, but Tel URI to join. > > > > > > Now, the only way to tie these is that we have a separate > > > list for participants that are allowed to subscribe? In > > > dial-in case it could be possible to put both URIs to the > > > Dial-In list, but in Dial-out case it is impossible, as the > > > server tries to invite both, even they mean a single participant? > > > > > > BR, > > > Jari > > > > > > > -----Original Message----- > > > > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On > > > Behalf Of ext > > > > hisham.khartabil@nokia.com > > > > Sent: 15 December, 2003 15:06 > > > > To: Mutikainen Jari (NMP-MSW/Helsinki); xcon@ietf.org > > > > Subject: RE: [XCON] CPCP Requirement: Conference package > > subscribers > > > > > > > > > > > > Jari, > > > > > > > > You are right, if you use a non-sip protocol to join the > > conference. > > > > > > > > In any case, this is not related to the questions I ask that > > > > are related who is allowed to subscribe to the conference > > > > state event package. > > > > > > > > Regards, > > > > Hisham > > > > > > > > > -----Original Message----- > > > > > From: Mutikainen Jari (NMP-MSW/Helsinki) > > > > > Sent: 15.December.2003 15:02 > > > > > To: Khartabil Hisham (NMP-MSW/Helsinki); xcon@ietf.org > > > > > Subject: RE: [XCON] CPCP Requirement: Conference package > > > subscribers > > > > > > > > > > > > > > > The address from where I subscribe the conference event might > > > > > be diffrent to the addres from where I'm joining to the > > > conference. > > > > > > > > > > BR, > > > > > Jari > > > > > > > > > > > -----Original Message----- > > > > > > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On > > > > > Behalf Of ext > > > > > > hisham.khartabil@nokia.com > > > > > > Sent: 15 December, 2003 14:55 > > > > > > To: xcon@ietf.org > > > > > > Subject: [XCON] CPCP Requirement: Conference package > > subscribers > > > > > > > > > > > > > > > > > > This is in reference to requirement REQ-H5 in > > > > > > > > > http://www.ietf.org/internet-drafts/draft-ietf-xcon-cpcp-reqs-00.txt > > > > > > > > > > REQ-H5: It SHOULD be possible to define users who are > > > allowed to > > > > > subscribe to conference event package [4] > > > > > > > > > > Should this be a separate list? or should a combination of > > > > > Dial-out list, Dial-in list be sufficient? i.e. only > > > > > participants and potential participants can subscribe to the > > > > > conference event package (outside users not allowed)? > > > > > > > > > > In any case, I think the requirement needs to stay, but needs > > > > > rewording according to the conclusions we come up with that > > > > > answer the above question. > > > > > > > > > > Regards, > > > > > Hisham > > > > > > > > > > _______________________________________________ > > > > > XCON mailing list > > > > > XCON@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/xcon > > > > > > > > > > > > > > > _______________________________________________ > > > XCON mailing list > > > XCON@ietf.org > > > https://www1.ietf.org/mailman/listinfo/xcon > > > > > > > _______________________________________________ > > XCON mailing list > > XCON@ietf.org > > https://www1.ietf.org/mailman/listinfo/xcon > > > >_______________________________________________ >XCON mailing list >XCON@ietf.org >https://www1.ietf.org/mailman/listinfo/xcon _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Mon Dec 15 11:19:30 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15349 for ; Mon, 15 Dec 2003 11:19:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVvR0-0001re-K4 for xcon-archive@odin.ietf.org; Mon, 15 Dec 2003 11:19:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBFGJ2pt007160 for xcon-archive@odin.ietf.org; Mon, 15 Dec 2003 11:19:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVvR0-0001rP-Ej for xcon-web-archive@optimus.ietf.org; Mon, 15 Dec 2003 11:19:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15322 for ; Mon, 15 Dec 2003 11:19:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AVvQz-0007nL-00 for xcon-web-archive@ietf.org; Mon, 15 Dec 2003 11:19:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AVvQz-0007nI-00 for xcon-web-archive@ietf.org; Mon, 15 Dec 2003 11:19:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVvQz-0001r6-DG; Mon, 15 Dec 2003 11:19:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVvQR-0001qm-Ib for xcon@optimus.ietf.org; Mon, 15 Dec 2003 11:18:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15313 for ; Mon, 15 Dec 2003 11:18:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AVvQI-0007mn-00 for xcon@ietf.org; Mon, 15 Dec 2003 11:18:19 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1AVvPt-0007ly-00 for xcon@ietf.org; Mon, 15 Dec 2003 11:17:53 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by sj-iport-5.cisco.com with ESMTP; 15 Dec 2003 16:18:01 +0000 Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hBFGHAxg000294; Mon, 15 Dec 2003 11:17:10 -0500 (EST) Received: from mhammer-w2k03.cisco.com (dhcp-hrn-64-100-229-166.cisco.com [64.100.229.166]) by fruitpie.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AVQ66542; Mon, 15 Dec 2003 08:17:00 -0800 (PST) Message-Id: <4.3.2.7.2.20031215111257.02ab11b0@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 15 Dec 2003 11:16:59 -0500 To: hisham.khartabil@nokia.com From: Michael Hammer Subject: Re: [XCON] CPCP Requirement: Hidden Participants Cc: In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB70118B13F@esebe019.ntc.noki a.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , Related to this is there a requirement that, while not revealing the identity of a hidden user, the conference policy contains state indication about either the presence of hidden users, or the possibility/preclusion that such hidden users may be present? I am anticipating that: 1) Laws may exist that require notification of such. 2) In some conferences, participants may want technical assurance that hidden users are not possible before they speak. Mike At 02:55 PM 12/15/2003 +0200, hisham.khartabil@nokia.com wrote: >This is in reference to requirements REQ-A7 and REQ-E10 in >http://www.ietf.org/internet-drafts/draft-ietf-xcon-cpcp-reqs-00.txt > > REQ-A7: It SHOULD be possible to participate in a conference as a > hidden user. Hidden user is present in a conference, but his presence > is not revealed. > > REQ-E10: It MUST be possible to allow and disallow hidden membership > in a conference. > >Should a conference policy, using CPCP, specify if a user can be hidden? >This means that the conference state package does not report the >participation on the hidden user. CPCP is used to identify which users are >hidden. The list of hidden users is only manipulated by a privileged user >such as the moderator. > >Regards, >Hisham > >_______________________________________________ >XCON mailing list >XCON@ietf.org >https://www1.ietf.org/mailman/listinfo/xcon _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Mon Dec 15 11:25:32 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15557 for ; Mon, 15 Dec 2003 11:25:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVvWp-00027N-Qd for xcon-archive@odin.ietf.org; Mon, 15 Dec 2003 11:25:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBFGP3iM008132 for xcon-archive@odin.ietf.org; Mon, 15 Dec 2003 11:25:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVvWp-000275-K9 for xcon-web-archive@optimus.ietf.org; Mon, 15 Dec 2003 11:25:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15531 for ; Mon, 15 Dec 2003 11:25:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AVvWo-00009P-00 for xcon-web-archive@ietf.org; Mon, 15 Dec 2003 11:25:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AVvWo-00009M-00 for xcon-web-archive@ietf.org; Mon, 15 Dec 2003 11:25:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVvWo-00026o-MW; Mon, 15 Dec 2003 11:25:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVvW2-00025R-VD for xcon@optimus.ietf.org; Mon, 15 Dec 2003 11:24:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15511 for ; Mon, 15 Dec 2003 11:24:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AVvW2-00008v-00 for xcon@ietf.org; Mon, 15 Dec 2003 11:24:14 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1AVvW1-00007o-00 for xcon@ietf.org; Mon, 15 Dec 2003 11:24:13 -0500 Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hBFGNdxg002117; Mon, 15 Dec 2003 11:23:39 -0500 (EST) Received: from mhammer-w2k03.cisco.com (dhcp-hrn-64-100-229-166.cisco.com [64.100.229.166]) by fruitpie.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AVQ67137; Mon, 15 Dec 2003 08:23:38 -0800 (PST) Message-Id: <4.3.2.7.2.20031215112111.00b2e8f8@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 15 Dec 2003 11:23:38 -0500 To: hisham.khartabil@nokia.com From: Michael Hammer Subject: RE: [XCON] CPCP Requirement: Hidden Participants Cc: , In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB701797516@esebe019.ntc.noki a.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , At 04:45 PM 12/15/2003 +0200, hisham.khartabil@nokia.com wrote: > > -----Original Message----- > > From: ext Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > Sent: 15.December.2003 16:17 > > To: Khartabil Hisham (NMP-MSW/Helsinki); xcon@ietf.org > > Subject: RE: [XCON] CPCP Requirement: Hidden Participants > > > > > > I think that this capability could be deferred. > >Noted. > > > I think it would be acceptable to allow a user > > to hide himself, and I think we need to allow > > one user to hide another (because of the PC app > > for a dumb phone problem). I think getting into > > permission issues is complicated. > > > > I'm puzzled by "the list of hidden users is > > manipulated by a privileged user..." I think that > > such a statement opens a large box of complication > > in specification. I would prefer, for now, to > > not have any specified behavior for anything > > like a privileged user. > >You can't have everyone manipulating the policy. We can define a >privileged user to be the moderator for now. But, you should be able to pass the baton on who is the moderator to another participant. I am taking that the conference creator might not be the conference moderator. I looked in the privileges section and am not sure whether being the moderator is considered a privilege. Is a requirement needed along the lines of: It must be possible to set, modify, delete the assignment of a moderator to the conference. ?? Mike >/Hisham > > > > > Brian > > > > > -----Original Message----- > > > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > > > Sent: Monday, December 15, 2003 7:55 AM > > > To: xcon@ietf.org > > > Subject: [XCON] CPCP Requirement: Hidden Participants > > > > > > > > > This is in reference to requirements REQ-A7 and REQ-E10 in > > > http://www.ietf.org/internet-drafts/draft-ietf-xcon-cpcp-reqs-00.txt > > > > > > REQ-A7: It SHOULD be possible to participate in a conference as a > > > hidden user. Hidden user is present in a conference, but > > > his presence > > > is not revealed. > > > > > > REQ-E10: It MUST be possible to allow and disallow hidden > > > membership > > > in a conference. > > > > > > Should a conference policy, using CPCP, specify if a user can > > > be hidden? This means that the conference state package does > > > not report the participation on the hidden user. CPCP is used > > > to identify which users are hidden. The list of hidden users > > > is only manipulated by a privileged user such as the moderator. > > > > > > Regards, > > > Hisham > > > > > > _______________________________________________ > > > XCON mailing list > > > XCON@ietf.org > > > https://www1.ietf.org/mailman/listinfo/xcon > > > > > > >_______________________________________________ >XCON mailing list >XCON@ietf.org >https://www1.ietf.org/mailman/listinfo/xcon _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Mon Dec 15 11:30:30 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15752 for ; Mon, 15 Dec 2003 11:30:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVvbe-0002TO-TT for xcon-archive@odin.ietf.org; Mon, 15 Dec 2003 11:30:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBFGU23E009500 for xcon-archive@odin.ietf.org; Mon, 15 Dec 2003 11:30:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVvbe-0002T9-Et for xcon-web-archive@optimus.ietf.org; Mon, 15 Dec 2003 11:30:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15746 for ; Mon, 15 Dec 2003 11:29:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AVvbd-0000Fy-00 for xcon-web-archive@ietf.org; Mon, 15 Dec 2003 11:30:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AVvbc-0000Fv-00 for xcon-web-archive@ietf.org; Mon, 15 Dec 2003 11:30:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVvbc-0002RR-I3; Mon, 15 Dec 2003 11:30:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVvat-0002MR-4q for xcon@optimus.ietf.org; Mon, 15 Dec 2003 11:29:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15719 for ; Mon, 15 Dec 2003 11:29:12 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AVvas-0000FV-00 for xcon@ietf.org; Mon, 15 Dec 2003 11:29:14 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AVvar-0000FS-00 for xcon@ietf.org; Mon, 15 Dec 2003 11:29:13 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hBFGTCn04185 for ; Mon, 15 Dec 2003 18:29:12 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 15 Dec 2003 18:29:12 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 15 Dec 2003 18:29:10 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] CPCP Requirement: Hidden Participants Date: Mon, 15 Dec 2003 18:29:10 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB70179751A@esebe019.ntc.nokia.com> Thread-Topic: [XCON] CPCP Requirement: Hidden Participants Thread-Index: AcPDJudClAdaKpqHSoi+jTdcDGpi4gAATf+w To: Cc: X-OriginalArrivalTime: 15 Dec 2003 16:29:10.0618 (UTC) FILETIME=[91A5DBA0:01C3C328] Content-Transfer-Encoding: quoted-printable Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ext Michael Hammer [mailto:mhammer@cisco.com] > Sent: 15.December.2003 18:17 > To: Khartabil Hisham (NMP-MSW/Helsinki) > Cc: xcon@ietf.org > Subject: Re: [XCON] CPCP Requirement: Hidden Participants >=20 >=20 > Related to this is there a requirement that, while not revealing the=20 > identity of a hidden user, the conference policy contains=20 > state indication=20 > about either the presence of hidden users, or the=20 > possibility/preclusion=20 > that such hidden users may be present? >=20 > I am anticipating that: > 1) Laws may exist that require notification of such. That's a good point. This might require changes to the conference event = package to indicate if there are hidden participants or not, and if so, = how many. The question remain: is there a need for such a feature (to hide = users?)? Regards, Hisham > 2) In some conferences, participants may want technical=20 > assurance that=20 > hidden users are not possible before they speak. >=20 > Mike >=20 >=20 > At 02:55 PM 12/15/2003 +0200, hisham.khartabil@nokia.com wrote: > >This is in reference to requirements REQ-A7 and REQ-E10 in=20 > >http://www.ietf.org/internet-drafts/draft-ietf-xcon-cpcp-reqs-00.txt > > > > REQ-A7: It SHOULD be possible to participate in a conference as a > > hidden user. Hidden user is present in a conference, but=20 > his presence > > is not revealed. > > > > REQ-E10: It MUST be possible to allow and disallow=20 > hidden membership > > in a conference. > > > >Should a conference policy, using CPCP, specify if a user=20 > can be hidden?=20 > >This means that the conference state package does not report the=20 > >participation on the hidden user. CPCP is used to identify=20 > which users are=20 > >hidden. The list of hidden users is only manipulated by a=20 > privileged user=20 > >such as the moderator. > > > >Regards, > >Hisham > > > >_______________________________________________ > >XCON mailing list > >XCON@ietf.org > >https://www1.ietf.org/mailman/listinfo/xcon >=20 >=20 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Mon Dec 15 11:53:32 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16459 for ; Mon, 15 Dec 2003 11:53:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVvxw-0003UD-1D for xcon-archive@odin.ietf.org; Mon, 15 Dec 2003 11:53:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBFGr3DQ013395 for xcon-archive@odin.ietf.org; Mon, 15 Dec 2003 11:53:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVvxv-0003Ty-Ln for xcon-web-archive@optimus.ietf.org; Mon, 15 Dec 2003 11:53:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16452 for ; Mon, 15 Dec 2003 11:53:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AVvxu-0000do-00 for xcon-web-archive@ietf.org; Mon, 15 Dec 2003 11:53:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AVvxu-0000dl-00 for xcon-web-archive@ietf.org; Mon, 15 Dec 2003 11:53:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVvxt-0003TR-Ry; Mon, 15 Dec 2003 11:53:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVvxg-0003T8-Aa for xcon@optimus.ietf.org; Mon, 15 Dec 2003 11:52:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16436 for ; Mon, 15 Dec 2003 11:52:45 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AVvxf-0000bt-00 for xcon@ietf.org; Mon, 15 Dec 2003 11:52:47 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AVvxd-0000bq-00 for xcon@ietf.org; Mon, 15 Dec 2003 11:52:46 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hBFGqhn00857 for ; Mon, 15 Dec 2003 18:52:43 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 15 Dec 2003 18:52:42 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 15 Dec 2003 18:52:42 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 15 Dec 2003 18:52:42 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] CPCP Requirement: Hidden Participants Date: Mon, 15 Dec 2003 18:52:41 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB70118B14A@esebe019.ntc.nokia.com> Thread-Topic: [XCON] CPCP Requirement: Hidden Participants Thread-Index: AcPDJ9D4ZqwYwxFyRpCzvpY3rI5QmAAAM08w To: Cc: , X-OriginalArrivalTime: 15 Dec 2003 16:52:42.0252 (UTC) FILETIME=[DB0C1CC0:01C3C32B] Content-Transfer-Encoding: quoted-printable Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ext Michael Hammer [mailto:mhammer@cisco.com] > Sent: 15.December.2003 18:24 > To: Khartabil Hisham (NMP-MSW/Helsinki) > Cc: Brian.Rosen@marconi.com; xcon@ietf.org > Subject: RE: [XCON] CPCP Requirement: Hidden Participants >=20 >=20 > At 04:45 PM 12/15/2003 +0200, hisham.khartabil@nokia.com wrote: >=20 >=20 > > > -----Original Message----- > > > From: ext Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > > Sent: 15.December.2003 16:17 > > > To: Khartabil Hisham (NMP-MSW/Helsinki); xcon@ietf.org > > > Subject: RE: [XCON] CPCP Requirement: Hidden Participants > > > > > > > > > I think that this capability could be deferred. > > > >Noted. > > > > > I think it would be acceptable to allow a user > > > to hide himself, and I think we need to allow > > > one user to hide another (because of the PC app > > > for a dumb phone problem). I think getting into > > > permission issues is complicated. > > > > > > I'm puzzled by "the list of hidden users is > > > manipulated by a privileged user..." I think that > > > such a statement opens a large box of complication > > > in specification. I would prefer, for now, to > > > not have any specified behavior for anything > > > like a privileged user. > > > >You can't have everyone manipulating the policy. We can define a=20 > >privileged user to be the moderator for now. >=20 > But, you should be able to pass the baton on who is the moderator to=20 > another participant. I am taking that the conference creator=20 > might not be=20 > the conference moderator. I looked in the privileges section=20 > and am not=20 > sure whether being the moderator is considered a privilege. Is a=20 > requirement needed along the lines of: >=20 > It must be possible to set, modify, delete the assignment of=20 > a moderator to=20 > the conference. > ?? At the moment it is assumed that the creator is the moderator. = Moderating a conference involves manipulating the policy. They might be = different levels of moderators, depending on what the creator assigns to = different users as privileges. Examples of privileges include who can = manipulate dial-out list, who can manipulate dial-in list, who can = manipulate conference info, who can expel users, who can manipulate = floor control policy, etc. As Brian noted a couple of times, we don't want to get into privileges = at the moment due to complexity. Regards, Hisham >=20 > Mike >=20 >=20 > >/Hisham > > > > > > > > Brian > > > > > > > -----Original Message----- > > > > From: hisham.khartabil@nokia.com=20 [mailto:hisham.khartabil@nokia.com] > > > Sent: Monday, December 15, 2003 7:55 AM > > > To: xcon@ietf.org > > > Subject: [XCON] CPCP Requirement: Hidden Participants > > > > > > > > > This is in reference to requirements REQ-A7 and REQ-E10 in > > > = http://www.ietf.org/internet-drafts/draft-ietf-xcon-cpcp-reqs-00.txt > > > > > > REQ-A7: It SHOULD be possible to participate in a conference as = a > > > hidden user. Hidden user is present in a conference, but > > > his presence > > > is not revealed. > > > > > > REQ-E10: It MUST be possible to allow and disallow hidden > > > membership > > > in a conference. > > > > > > Should a conference policy, using CPCP, specify if a user can > > > be hidden? This means that the conference state package does > > > not report the participation on the hidden user. CPCP is used > > > to identify which users are hidden. The list of hidden users > > > is only manipulated by a privileged user such as the moderator. > > > > > > Regards, > > > Hisham > > > > > > _______________________________________________ > > > XCON mailing list > > > XCON@ietf.org > > > https://www1.ietf.org/mailman/listinfo/xcon > > > > > > >_______________________________________________ >XCON mailing list >XCON@ietf.org >https://www1.ietf.org/mailman/listinfo/xcon _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Mon Dec 15 12:07:30 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16886 for ; Mon, 15 Dec 2003 12:07:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVwBS-0004gI-38 for xcon-archive@odin.ietf.org; Mon, 15 Dec 2003 12:07:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBFH72PR017993 for xcon-archive@odin.ietf.org; Mon, 15 Dec 2003 12:07:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVwBR-0004fj-J0 for xcon-web-archive@optimus.ietf.org; Mon, 15 Dec 2003 12:07:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16871 for ; Mon, 15 Dec 2003 12:06:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AVwBQ-0000pz-00 for xcon-web-archive@ietf.org; Mon, 15 Dec 2003 12:07:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AVwBP-0000pw-00 for xcon-web-archive@ietf.org; Mon, 15 Dec 2003 12:06:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVwBQ-0004fD-DL; Mon, 15 Dec 2003 12:07:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVwAn-0004cn-Cn for xcon@optimus.ietf.org; Mon, 15 Dec 2003 12:06:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16848 for ; Mon, 15 Dec 2003 12:06:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AVwAm-0000p9-00 for xcon@ietf.org; Mon, 15 Dec 2003 12:06:20 -0500 Received: from goalie.snowshore.com ([216.57.133.4] helo=webshield.office.snowshore.com) by ietf-mx with smtp (Exim 4.12) id 1AVwAl-0000oD-00 for xcon@ietf.org; Mon, 15 Dec 2003 12:06:19 -0500 Received: from zoe.office.snowshore.com(192.168.1.172) by webshield.office.snowshore.com via csmap id 6328; Mon, 15 Dec 2003 12:10:35 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] CPCP requirements to support IMS Date: Mon, 15 Dec 2003 12:05:46 -0500 Message-ID: <4A3384433CE2AB46A63468CB207E209D8427CF@zoe.office.snowshore.com> Thread-Topic: [XCON] CPCP requirements to support IMS Thread-Index: AcPAL38YEqFS9+kZRk2MQEOFch7dywAjIM9QAAsjMNAAfgFHkAATOYSv From: "Eric Burger" To: , Content-Transfer-Encoding: quoted-printable Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable I suppose if the policy is "this conference can accept [one or more of = {audio, video, text, application}]", then that works. Note that does not prevent a "(audio, video)" conference from accepting = a "(audio)"-only participant. Or does it? I would vote "no." -----Original Message----- From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] Sent: Mon 12/15/2003 2:54 AM To: Eric Burger; xcon@ietf.org Cc:=09 Subject: RE: [XCON] CPCP requirements to support IMS Are you suggesting that that creator of a conference has no say in what = media the conference will offer? /Hisham > -----Original Message----- > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On Behalf Of ext > Eric Burger > Sent: 12.December.2003 22:31 > To: Khartabil Hisham (NMP-MSW/Helsinki); xcon@ietf.org > Subject: RE: [XCON] CPCP requirements to support IMS >=20 >=20 > Why do we need an explicit policy at all? >=20 > Wouldn't the bridge, by its nature, accept or reject the=20 > different media types? >=20 > > -----Original Message----- > > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > > Sent: Fri, December 12, 2003 9:32 AM > > To: adam@dynamicsoft.com; petri.koskelainen@nokia.com; xcon@ietf.org > > Subject: RE: [XCON] CPCP requirements to support IMS > >=20 > >=20 > > The issue I have is that we at least need to know the media=20 > > to be used in the conference (audio, video, text), to enable=20 > > the server to reserve resources and to enable the focus to=20 > > include/exclude certain media from the INVITEs SDP it sends=20 > > out to the dial-out list, and also enables the focus to=20 > > reject the media streams in the SDP of INVITE request coming=20 > > from dial-in participants. > >=20 > > I don't think in the basic media policy needs to define what=20 > > the codecs to be used are, this can be a normal offer answer=20 > > exchange between the client and the server. > >=20 > > This is a basic requirement and enables CPCP to work without=20 > > the complicated media policy. If the people working on the=20 > > media policy could work on a basic one like this, it would be=20 > > great. We can then work on an advanced media policy as a=20 > second step. > >=20 > > Regards, > > Hisham > >=20 > > > -----Original Message----- > > > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On=20 > > Behalf Of ext > > > Adam Roach > > > Sent: 11.December.2003 23:40 > > > To: Koskelainen Petri (NRC/Tampere); xcon@ietf.org > > > Subject: RE: [XCON] CPCP requirements to support IMS > > >=20 > > >=20 > > > [as chair] > > >=20 > > > petri.koskelainen@nokia.com=20 > > > [mailto:petri.koskelainen@nokia.com] wrote: > > >=20 > > > > I'm a bit worried about media policy-CPCP integration=20 > > > > and WG schedule regarding it. > > > >=20 > > > > Currently the charter says the following: > > > > May 04 Submit Membership Manipulation Protocol for=20 > > > publication as PS=20 > > > > Jul 04 Submit Protocol for Media Topology Control for=20 > publication > > > >=20 > > > > What I would like to have by May 04 is CPCP with the ability=20 > > > > to set up typical real-life conference, e.g. with audio=20 > > codec X and > > > > centralized mixer.=20 > > > ... > > > > Current media policy seems to be extremely complex and=20 > > the RFC goal=20 > > > > is not until July. > > > >=20 > > > > Georg can probably comment on 3GPP schedules but in any case,=20 > > > > should we adopt simple media definition in CPCP itself=20 > (or divide > > > > media policy into basic and advanced parts so basic=20 > media policy=20 > > > > could be ready by May 04)? > > >=20 > > > Media policy was pushed to July precisely because it is=20 > more complex > > > and (at this point, at least) more contentious. > > >=20 > > > I fear that diverting resources to getting a bare-bones=20 > media policy > > > out the door early will only cause significant delays to not just > > > advanced media policy, but to all of our deliverables. That seems > > > a steep price to pay for a two-month advance on publication. > > >=20 > > > Hopefully, by the time the membership manipulation=20 > document is ready > > > for publication, the media policy draft will be stable=20 > > enough to give > > > you a basis to start implementation. > > >=20 > > > What is important to keep in mind is that we are not=20 > > performing these > > > tasks serially. The documents should develop pretty much in=20 > > parallel. > > >=20 > > > /a > > >=20 > > > _______________________________________________ > > > XCON mailing list > > > XCON@ietf.org > > > https://www1.ietf.org/mailman/listinfo/xcon > > >=20 > >=20 > > _______________________________________________ > > XCON mailing list > > XCON@ietf.org > > https://www1.ietf.org/mailman/listinfo/xcon > >=20 > >=20 >=20 >=20 > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon >=20 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Mon Dec 15 12:16:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17110 for ; Mon, 15 Dec 2003 12:16:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVwK5-0005Hx-Oy for xcon-archive@odin.ietf.org; Mon, 15 Dec 2003 12:15:58 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBFHFvhp020323 for xcon-archive@odin.ietf.org; Mon, 15 Dec 2003 12:15:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVwK5-0005Hi-Aw for xcon-web-archive@optimus.ietf.org; Mon, 15 Dec 2003 12:15:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17103 for ; Mon, 15 Dec 2003 12:15:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AVwJy-0000vr-00 for xcon-web-archive@ietf.org; Mon, 15 Dec 2003 12:15:50 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AVwJZ-0000vm-00 for xcon-web-archive@ietf.org; Mon, 15 Dec 2003 12:15:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVwJE-0005Fw-V5; Mon, 15 Dec 2003 12:15:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVwIh-0005Ew-QD for xcon@optimus.ietf.org; Mon, 15 Dec 2003 12:14:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17090 for ; Mon, 15 Dec 2003 12:14:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AVwIg-0000vP-00 for xcon@ietf.org; Mon, 15 Dec 2003 12:14:30 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1AVwIg-0000v8-00 for xcon@ietf.org; Mon, 15 Dec 2003 12:14:30 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by sj-iport-5.cisco.com with ESMTP; 15 Dec 2003 17:14:48 +0000 Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hBFHDvxg016371; Mon, 15 Dec 2003 12:13:57 -0500 (EST) Received: from mhammer-w2k03.cisco.com (dhcp-hrn-64-100-229-166.cisco.com [64.100.229.166]) by fruitpie.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AVQ71564; Mon, 15 Dec 2003 09:13:55 -0800 (PST) Message-Id: <4.3.2.7.2.20031215121323.02af3aa8@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 15 Dec 2003 12:13:55 -0500 To: From: Michael Hammer Subject: RE: [XCON] CPCP Requirement: Hidden Participants Cc: , In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB70118B14A@esebe019.ntc.noki a.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , At 06:52 PM 12/15/2003 +0200, hisham.khartabil@nokia.com wrote: > > -----Original Message----- > > From: ext Michael Hammer [mailto:mhammer@cisco.com] > > Sent: 15.December.2003 18:24 > > To: Khartabil Hisham (NMP-MSW/Helsinki) > > Cc: Brian.Rosen@marconi.com; xcon@ietf.org > > Subject: RE: [XCON] CPCP Requirement: Hidden Participants > > > > > > At 04:45 PM 12/15/2003 +0200, hisham.khartabil@nokia.com wrote: > > > > > > > > -----Original Message----- > > > > From: ext Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > > > Sent: 15.December.2003 16:17 > > > > To: Khartabil Hisham (NMP-MSW/Helsinki); xcon@ietf.org > > > > Subject: RE: [XCON] CPCP Requirement: Hidden Participants > > > > > > > > > > > > I think that this capability could be deferred. > > > > > >Noted. > > > > > > > I think it would be acceptable to allow a user > > > > to hide himself, and I think we need to allow > > > > one user to hide another (because of the PC app > > > > for a dumb phone problem). I think getting into > > > > permission issues is complicated. > > > > > > > > I'm puzzled by "the list of hidden users is > > > > manipulated by a privileged user..." I think that > > > > such a statement opens a large box of complication > > > > in specification. I would prefer, for now, to > > > > not have any specified behavior for anything > > > > like a privileged user. > > > > > >You can't have everyone manipulating the policy. We can define a > > >privileged user to be the moderator for now. > > > > But, you should be able to pass the baton on who is the moderator to > > another participant. I am taking that the conference creator > > might not be > > the conference moderator. I looked in the privileges section > > and am not > > sure whether being the moderator is considered a privilege. Is a > > requirement needed along the lines of: > > > > It must be possible to set, modify, delete the assignment of > > a moderator to > > the conference. > > ?? > >At the moment it is assumed that the creator is the moderator. Moderating >a conference involves manipulating the policy. They might be different >levels of moderators, depending on what the creator assigns to different >users as privileges. Examples of privileges include who can manipulate >dial-out list, who can manipulate dial-in list, who can manipulate >conference info, who can expel users, who can manipulate floor control >policy, etc. > >As Brian noted a couple of times, we don't want to get into privileges at >the moment due to complexity. So if moderator is a privilege, then I take it there will be no mention of moderators. Mike >Regards, >Hisham > > > > > Mike > > > > > > >/Hisham > > > > > > > > > > > Brian > > > > > > > > > -----Original Message----- > > > > > From: hisham.khartabil@nokia.com >[mailto:hisham.khartabil@nokia.com] > > > > Sent: Monday, December 15, 2003 7:55 AM > > > > To: xcon@ietf.org > > > > Subject: [XCON] CPCP Requirement: Hidden Participants > > > > > > > > > > > > This is in reference to requirements REQ-A7 and REQ-E10 in > > > > http://www.ietf.org/internet-drafts/draft-ietf-xcon-cpcp-reqs-00.txt > > > > > > > > REQ-A7: It SHOULD be possible to participate in a conference as a > > > > hidden user. Hidden user is present in a conference, but > > > > his presence > > > > is not revealed. > > > > > > > > REQ-E10: It MUST be possible to allow and disallow hidden > > > > membership > > > > in a conference. > > > > > > > > Should a conference policy, using CPCP, specify if a user can > > > > be hidden? This means that the conference state package does > > > > not report the participation on the hidden user. CPCP is used > > > > to identify which users are hidden. The list of hidden users > > > > is only manipulated by a privileged user such as the moderator. > > > > > > > > Regards, > > > > Hisham > > > > > > > > _______________________________________________ > > > > XCON mailing list > > > > XCON@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/xcon > > > > > > > > > > >_______________________________________________ > >XCON mailing list > >XCON@ietf.org > >https://www1.ietf.org/mailman/listinfo/xcon _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Mon Dec 15 18:33:40 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06112 for ; Mon, 15 Dec 2003 18:33:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AW2DC-0004eF-HQ for xcon-archive@odin.ietf.org; Mon, 15 Dec 2003 18:33:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBFNXEXu017861 for xcon-archive@odin.ietf.org; Mon, 15 Dec 2003 18:33:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AW2DC-0004e0-DO for xcon-web-archive@optimus.ietf.org; Mon, 15 Dec 2003 18:33:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06099 for ; Mon, 15 Dec 2003 18:33:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AW2D9-0005TH-00 for xcon-web-archive@ietf.org; Mon, 15 Dec 2003 18:33:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AW2Cx-0005T3-00 for xcon-web-archive@ietf.org; Mon, 15 Dec 2003 18:33:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AW2Cx-0005Sz-00 for xcon-web-archive@ietf.org; Mon, 15 Dec 2003 18:32:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AW2Cz-0004cS-8R; Mon, 15 Dec 2003 18:33:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AW2CL-0004c9-NO for xcon@optimus.ietf.org; Mon, 15 Dec 2003 18:32:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06057 for ; Mon, 15 Dec 2003 18:32:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AW2CI-0005RN-00 for xcon@ietf.org; Mon, 15 Dec 2003 18:32:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AW2CH-0005RG-00 for xcon@ietf.org; Mon, 15 Dec 2003 18:32:18 -0500 Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx with esmtp (Exim 4.12) id 1AW2CH-0005Qn-00 for xcon@ietf.org; Mon, 15 Dec 2003 18:32:17 -0500 Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1041); Mon, 15 Dec 2003 15:31:23 -0800 Received: from 157.54.5.25 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 15 Dec 2003 15:31:47 -0800 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by inet-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 15 Dec 2003 15:32:08 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] CPCP and Conference URIs - there are more than one! Date: Mon, 15 Dec 2003 15:31:43 -0800 Message-ID: Thread-Topic: [XCON] CPCP and Conference URIs - there are more than one! Thread-Index: AcO7WMndAt1QJz/iQRC7zCRfA18SoQEuaDZgADCpWCAAMEU2sABzO3Dw From: "Orit Levin" To: Cc: X-OriginalArrivalTime: 15 Dec 2003 23:32:08.0349 (UTC) FILETIME=[A7F44CD0:01C3C363] Content-Transfer-Encoding: quoted-printable Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Good example! I am convinced now. Will add to the conference package. Thanks, Orit.=20 -----Original Message----- From: aki.niemi@nokia.com [mailto:aki.niemi@nokia.com]=20 Sent: Saturday, December 13, 2003 8:37 AM To: Orit Levin Cc: xcon@ietf.org Subject: RE: [XCON] CPCP and Conference URIs - there are more than one! Orit wrote: > Should the conference package include different kinds of "Conference > URIs" - is a more difficult question. Let's say we do, how are they > going to be used by the recipient of the event information? In theory at least, the recipient might want to subscibe to the conference package, but join the conference by some other means than a SIP URI.=20 For example, the client might have a high latency, low bandwidth IP pipe -- good enough for SIP subscriptions but not good enough for voice. It might also have a trusty old circuit switched telephony application that would be perfect for voice. Cheers, Aki _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Tue Dec 16 03:42:50 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04616 for ; Tue, 16 Dec 2003 03:42:49 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWAma-0007FR-42 for xcon-archive@odin.ietf.org; Tue, 16 Dec 2003 03:42:20 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBG8gI9V027855 for xcon-archive@odin.ietf.org; Tue, 16 Dec 2003 03:42:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWAmV-0007Er-M5 for xcon-web-archive@optimus.ietf.org; Tue, 16 Dec 2003 03:42:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04599 for ; Tue, 16 Dec 2003 03:42:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWAmT-0005RO-00 for xcon-web-archive@ietf.org; Tue, 16 Dec 2003 03:42:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWAmS-0005RH-00 for xcon-web-archive@ietf.org; Tue, 16 Dec 2003 03:42:12 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWAmS-0005RE-00 for xcon-web-archive@ietf.org; Tue, 16 Dec 2003 03:42:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWAmR-0007Eb-Mj; Tue, 16 Dec 2003 03:42:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWAlk-0007Cy-52 for xcon@optimus.ietf.org; Tue, 16 Dec 2003 03:41:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04582 for ; Tue, 16 Dec 2003 03:41:26 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWAlh-0005Pt-00 for xcon@ietf.org; Tue, 16 Dec 2003 03:41:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWAlg-0005Pm-00 for xcon@ietf.org; Tue, 16 Dec 2003 03:41:25 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AWAlg-0005Pj-00 for xcon@ietf.org; Tue, 16 Dec 2003 03:41:24 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hBG8fOH19087 for ; Tue, 16 Dec 2003 10:41:24 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 16 Dec 2003 10:41:21 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 16 Dec 2003 10:41:20 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] CPCP Requirement: Hidden Participants Date: Tue, 16 Dec 2003 10:41:20 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB70179751F@esebe019.ntc.nokia.com> Thread-Topic: [XCON] CPCP Requirement: Hidden Participants Thread-Index: AcPDLtXGYnB/wFM7RoWqtCyidfKPigAgV5jg To: Cc: , X-OriginalArrivalTime: 16 Dec 2003 08:41:20.0708 (UTC) FILETIME=[61174040:01C3C3B0] Content-Transfer-Encoding: quoted-printable Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ext Michael Hammer [mailto:mhammer@cisco.com] > Sent: 15.December.2003 19:14 > To: Khartabil Hisham (NMP-MSW/Helsinki) > Cc: Brian.Rosen@marconi.com; xcon@ietf.org > Subject: RE: [XCON] CPCP Requirement: Hidden Participants >=20 >=20 > >At the moment it is assumed that the creator is the=20 > moderator. Moderating=20 > >a conference involves manipulating the policy. They might be=20 > different=20 > >levels of moderators, depending on what the creator assigns=20 > to different=20 > >users as privileges. Examples of privileges include who can=20 > manipulate=20 > >dial-out list, who can manipulate dial-in list, who can manipulate=20 > >conference info, who can expel users, who can manipulate=20 > floor control=20 > >policy, etc. > > > >As Brian noted a couple of times, we don't want to get into=20 > privileges at=20 > >the moment due to complexity. >=20 > So if moderator is a privilege, then I take it there will be=20 > no mention of=20 > moderators. If there is, it would mean creator (until we make progress on the = privileges stuff). /Hisham _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Tue Dec 16 03:55:35 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04792 for ; Tue, 16 Dec 2003 03:55:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWAyv-0007U2-Ra for xcon-archive@odin.ietf.org; Tue, 16 Dec 2003 03:55:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBG8t524028766 for xcon-archive@odin.ietf.org; Tue, 16 Dec 2003 03:55:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWAyv-0007Tt-2v for xcon-web-archive@optimus.ietf.org; Tue, 16 Dec 2003 03:55:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04789 for ; Tue, 16 Dec 2003 03:55:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWAys-0005eg-00 for xcon-web-archive@ietf.org; Tue, 16 Dec 2003 03:55:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWAyr-0005eZ-00 for xcon-web-archive@ietf.org; Tue, 16 Dec 2003 03:55:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWAyr-0005eW-00 for xcon-web-archive@ietf.org; Tue, 16 Dec 2003 03:55:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWAys-0007TI-KR; Tue, 16 Dec 2003 03:55:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWAyo-0007Sp-Pa for xcon@optimus.ietf.org; Tue, 16 Dec 2003 03:54:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04786 for ; Tue, 16 Dec 2003 03:54:56 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWAym-0005eT-00 for xcon@ietf.org; Tue, 16 Dec 2003 03:54:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWAyk-0005eM-00 for xcon@ietf.org; Tue, 16 Dec 2003 03:54:55 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AWAyk-0005eJ-00 for xcon@ietf.org; Tue, 16 Dec 2003 03:54:54 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hBG8stH09071 for ; Tue, 16 Dec 2003 10:54:55 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 16 Dec 2003 10:54:54 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 16 Dec 2003 10:54:54 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Subject: Basic Media Policy (was: RE: [XCON] CPCP requirements to support IMS) Date: Tue, 16 Dec 2003 10:54:53 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB70118B14C@esebe019.ntc.nokia.com> Thread-Topic: [XCON] CPCP requirements to support IMS Thread-Index: AcPAL38YEqFS9+kZRk2MQEOFch7dywAjIM9QAAsjMNAAfgFHkAATOYSvACEGfmA= To: , X-OriginalArrivalTime: 16 Dec 2003 08:54:54.0135 (UTC) FILETIME=[45EE5C70:01C3C3B2] Content-Transfer-Encoding: quoted-printable Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ext Eric Burger [mailto:eburger@snowshore.com] > Sent: 15.December.2003 19:06 > To: Khartabil Hisham (NMP-MSW/Helsinki); xcon@ietf.org > Subject: RE: [XCON] CPCP requirements to support IMS >=20 >=20 > I suppose if the policy is "this conference can accept [one=20 > or more of {audio, video, text, application}]", then that works. >=20 > Note that does not prevent a "(audio, video)" conference from=20 > accepting a "(audio)"-only participant. Or does it? I would=20 > vote "no." I agree. So back to my ogiginal question: Should we define a basic media policy as a first step in CPCP (for media = types only)? Regards, Hisham >=20 >=20 > -----Original Message----- > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > Sent: Mon 12/15/2003 2:54 AM > To: Eric Burger; xcon@ietf.org > Cc:=09 > Subject: RE: [XCON] CPCP requirements to support IMS > Are you suggesting that that creator of a conference has no=20 > say in what media the conference will offer? >=20 > /Hisham >=20 > > -----Original Message----- > > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On=20 > Behalf Of ext > > Eric Burger > > Sent: 12.December.2003 22:31 > > To: Khartabil Hisham (NMP-MSW/Helsinki); xcon@ietf.org > > Subject: RE: [XCON] CPCP requirements to support IMS > >=20 > >=20 > > Why do we need an explicit policy at all? > >=20 > > Wouldn't the bridge, by its nature, accept or reject the=20 > > different media types? > >=20 > > > -----Original Message----- > > > From: hisham.khartabil@nokia.com=20 > [mailto:hisham.khartabil@nokia.com] > > > Sent: Fri, December 12, 2003 9:32 AM > > > To: adam@dynamicsoft.com; petri.koskelainen@nokia.com;=20 > xcon@ietf.org > > > Subject: RE: [XCON] CPCP requirements to support IMS > > >=20 > > >=20 > > > The issue I have is that we at least need to know the media=20 > > > to be used in the conference (audio, video, text), to enable=20 > > > the server to reserve resources and to enable the focus to=20 > > > include/exclude certain media from the INVITEs SDP it sends=20 > > > out to the dial-out list, and also enables the focus to=20 > > > reject the media streams in the SDP of INVITE request coming=20 > > > from dial-in participants. > > >=20 > > > I don't think in the basic media policy needs to define what=20 > > > the codecs to be used are, this can be a normal offer answer=20 > > > exchange between the client and the server. > > >=20 > > > This is a basic requirement and enables CPCP to work without=20 > > > the complicated media policy. If the people working on the=20 > > > media policy could work on a basic one like this, it would be=20 > > > great. We can then work on an advanced media policy as a=20 > > second step. > > >=20 > > > Regards, > > > Hisham > > >=20 > > > > -----Original Message----- > > > > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On=20 > > > Behalf Of ext > > > > Adam Roach > > > > Sent: 11.December.2003 23:40 > > > > To: Koskelainen Petri (NRC/Tampere); xcon@ietf.org > > > > Subject: RE: [XCON] CPCP requirements to support IMS > > > >=20 > > > >=20 > > > > [as chair] > > > >=20 > > > > petri.koskelainen@nokia.com=20 > > > > [mailto:petri.koskelainen@nokia.com] wrote: > > > >=20 > > > > > I'm a bit worried about media policy-CPCP integration=20 > > > > > and WG schedule regarding it. > > > > >=20 > > > > > Currently the charter says the following: > > > > > May 04 Submit Membership Manipulation Protocol for=20 > > > > publication as PS=20 > > > > > Jul 04 Submit Protocol for Media Topology Control for=20 > > publication > > > > >=20 > > > > > What I would like to have by May 04 is CPCP with the ability=20 > > > > > to set up typical real-life conference, e.g. with audio=20 > > > codec X and > > > > > centralized mixer.=20 > > > > ... > > > > > Current media policy seems to be extremely complex and=20 > > > the RFC goal=20 > > > > > is not until July. > > > > >=20 > > > > > Georg can probably comment on 3GPP schedules but in any case,=20 > > > > > should we adopt simple media definition in CPCP itself=20 > > (or divide > > > > > media policy into basic and advanced parts so basic=20 > > media policy=20 > > > > > could be ready by May 04)? > > > >=20 > > > > Media policy was pushed to July precisely because it is=20 > > more complex > > > > and (at this point, at least) more contentious. > > > >=20 > > > > I fear that diverting resources to getting a bare-bones=20 > > media policy > > > > out the door early will only cause significant delays=20 > to not just > > > > advanced media policy, but to all of our deliverables.=20 > That seems > > > > a steep price to pay for a two-month advance on publication. > > > >=20 > > > > Hopefully, by the time the membership manipulation=20 > > document is ready > > > > for publication, the media policy draft will be stable=20 > > > enough to give > > > > you a basis to start implementation. > > > >=20 > > > > What is important to keep in mind is that we are not=20 > > > performing these > > > > tasks serially. The documents should develop pretty much in=20 > > > parallel. > > > >=20 > > > > /a > > > >=20 > > > > _______________________________________________ > > > > XCON mailing list > > > > XCON@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/xcon > > > >=20 > > >=20 > > > _______________________________________________ > > > XCON mailing list > > > XCON@ietf.org > > > https://www1.ietf.org/mailman/listinfo/xcon > > >=20 > > >=20 > >=20 > >=20 > > _______________________________________________ > > XCON mailing list > > XCON@ietf.org > > https://www1.ietf.org/mailman/listinfo/xcon > >=20 >=20 >=20 >=20 >=20 >=20 >=20 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Tue Dec 16 12:14:32 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24054 for ; Tue, 16 Dec 2003 12:14:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWIlp-0003xd-D5 for xcon-archive@odin.ietf.org; Tue, 16 Dec 2003 12:14:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBGHE5iP015219 for xcon-archive@odin.ietf.org; Tue, 16 Dec 2003 12:14:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWIlo-0003xO-FO for xcon-web-archive@optimus.ietf.org; Tue, 16 Dec 2003 12:14:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24045 for ; Tue, 16 Dec 2003 12:14:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWIln-0002oB-00 for xcon-web-archive@ietf.org; Tue, 16 Dec 2003 12:14:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWIlm-0002o3-00 for xcon-web-archive@ietf.org; Tue, 16 Dec 2003 12:14:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWIlm-0002o0-00 for xcon-web-archive@ietf.org; Tue, 16 Dec 2003 12:14:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWIll-0003wr-PL; Tue, 16 Dec 2003 12:14:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWIle-0003wH-5X for xcon@optimus.ietf.org; Tue, 16 Dec 2003 12:13:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24031 for ; Tue, 16 Dec 2003 12:13:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWIlc-0002nR-00 for xcon@ietf.org; Tue, 16 Dec 2003 12:13:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWIlb-0002nK-00 for xcon@ietf.org; Tue, 16 Dec 2003 12:13:52 -0500 Received: from hoemail1.lucent.com ([192.11.226.161] helo=hoemail1.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1AWIlb-0002md-00 for xcon@ietf.org; Tue, 16 Dec 2003 12:13:51 -0500 Received: from uk0006exch001h.wins.lucent.com (h135-86-145-57.lucent.com [135.86.145.57]) by hoemail1.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id hBGHCmE14207 for ; Tue, 16 Dec 2003 11:13:05 -0600 (CST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Tue, 16 Dec 2003 15:53:45 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB00439EF72@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "'xcon@ietf.org'" Date: Tue, 16 Dec 2003 15:53:44 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Subject: [XCON] Floor control? Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 At IETF 58, I though we were promised fairly imminently a new version of http://www.ietf.org/internet-drafts/draft-koskelainen-xcon-floor-control-req-00.txt which would be the IETF working group draft. Anybody have any idea when we will see it? regards Keith Keith Drage Lucent Technologies drage@lucent.com tel: +44 1793 776249 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Tue Dec 16 15:11:32 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00836 for ; Tue, 16 Dec 2003 15:11:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWLX6-00030r-VD for xcon-archive@odin.ietf.org; Tue, 16 Dec 2003 15:11:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBGKB4fG011571 for xcon-archive@odin.ietf.org; Tue, 16 Dec 2003 15:11:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWLX6-00030W-0x for xcon-web-archive@optimus.ietf.org; Tue, 16 Dec 2003 15:11:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00766 for ; Tue, 16 Dec 2003 15:11:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWLX2-0000ke-00 for xcon-web-archive@ietf.org; Tue, 16 Dec 2003 15:11:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWLX1-0000kV-00 for xcon-web-archive@ietf.org; Tue, 16 Dec 2003 15:11:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWLX1-0000kQ-00 for xcon-web-archive@ietf.org; Tue, 16 Dec 2003 15:10:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWLX4-00030C-0D; Tue, 16 Dec 2003 15:11:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWLWz-0002zY-O8 for xcon@optimus.ietf.org; Tue, 16 Dec 2003 15:10:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00753 for ; Tue, 16 Dec 2003 15:10:53 -0500 (EST) From: petri.koskelainen@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWLWw-0000k6-00 for xcon@ietf.org; Tue, 16 Dec 2003 15:10:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWLWv-0000jz-00 for xcon@ietf.org; Tue, 16 Dec 2003 15:10:54 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AWLWv-0000jw-00 for xcon@ietf.org; Tue, 16 Dec 2003 15:10:53 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hBGKAmJ19648 for ; Tue, 16 Dec 2003 22:10:49 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 16 Dec 2003 22:10:48 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 16 Dec 2003 22:10:48 +0200 Received: from trebe004.NOE.Nokia.com ([172.22.232.177]) by esebe019.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 16 Dec 2003 22:10:47 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] Floor control? Date: Tue, 16 Dec 2003 22:10:47 +0200 Message-ID: <481D6FFB3BD60E4CB590F39C59098400023E0BFD@trebe004.europe.nokia.com> Thread-Topic: [XCON] Floor control? Thread-Index: AcPD+AeaNsS222lzSqK5L5fWthnGHAAFtbTw To: , X-OriginalArrivalTime: 16 Dec 2003 20:10:47.0925 (UTC) FILETIME=[B1DFA250:01C3C410] Content-Transfer-Encoding: quoted-printable Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi, New version should be available early next week (including some things from brunner draft). Petri > -----Original Message----- > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On Behalf Of ext > Drage, Keith (Keith) > Sent: 16 December, 2003 17:54 > To: 'xcon@ietf.org' > Subject: [XCON] Floor control? >=20 >=20 > At IETF 58, I though we were promised fairly imminently a new=20 > version of=20 >=20 > http://www.ietf.org/internet-drafts/draft-koskelainen-xcon-flo > or-control-req-00.txt >=20 > which would be the IETF working group draft. Anybody have any=20 > idea when we will see it? >=20 > regards >=20 > Keith >=20 > Keith Drage > Lucent Technologies > drage@lucent.com > tel: +44 1793 776249 >=20 > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon >=20 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Thu Dec 18 15:30:17 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14986 for ; Thu, 18 Dec 2003 15:30:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX4mK-0006Ai-AV for xcon-archive@odin.ietf.org; Thu, 18 Dec 2003 15:29:48 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBIKTm0Q023718 for xcon-archive@odin.ietf.org; Thu, 18 Dec 2003 15:29:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX4mK-0006AT-6s for xcon-web-archive@optimus.ietf.org; Thu, 18 Dec 2003 15:29:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14916 for ; Thu, 18 Dec 2003 15:29:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AX4mD-0005uE-00 for xcon-web-archive@ietf.org; Thu, 18 Dec 2003 15:29:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AX4ln-0005tq-00 for xcon-web-archive@ietf.org; Thu, 18 Dec 2003 15:29:16 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AX4ln-0005tZ-00 for xcon-web-archive@ietf.org; Thu, 18 Dec 2003 15:29:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX4lZ-00061v-DS; Thu, 18 Dec 2003 15:29:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX4lU-00061c-Pf for xcon@optimus.ietf.org; Thu, 18 Dec 2003 15:28:56 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14755; Thu, 18 Dec 2003 15:28:54 -0500 (EST) Message-Id: <200312182028.PAA14755@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: xcon@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Thu, 18 Dec 2003 15:28:54 -0500 Subject: [XCON] I-D ACTION:draft-ietf-xcon-conference-scenarios-00.txt Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Centralized Conferencing Working Group of the IETF. Title : Conferencing Scenarios Author(s) : R. Even Filename : draft-ietf-xcon-conference-scenarios-00.txt Pages : 15 Date : 2003-12-18 This document describes SIP conferencing scenarios. It will describe basic and advance conferencing scenarios. These conferencing scenarios will help with definition and evaluation of the requirements for SIP conferencing framework and the protocol associated with the framework. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-xcon-conference-scenarios-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-xcon-conference-scenarios-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-xcon-conference-scenarios-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-12-18142457.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-xcon-conference-scenarios-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-xcon-conference-scenarios-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-12-18142457.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Thu Dec 18 16:07:34 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18957 for ; Thu, 18 Dec 2003 16:07:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX5MQ-0000EM-9B for xcon-archive@odin.ietf.org; Thu, 18 Dec 2003 16:07:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBIL76oK000869 for xcon-archive@odin.ietf.org; Thu, 18 Dec 2003 16:07:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX5MP-0000Dk-Ks for xcon-web-archive@optimus.ietf.org; Thu, 18 Dec 2003 16:07:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18911 for ; Thu, 18 Dec 2003 16:07:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AX5MO-00012C-00 for xcon-web-archive@ietf.org; Thu, 18 Dec 2003 16:07:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AX5MK-000118-00 for xcon-web-archive@ietf.org; Thu, 18 Dec 2003 16:07:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AX5MJ-000115-00 for xcon-web-archive@ietf.org; Thu, 18 Dec 2003 16:06:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX5MK-0000Aj-T8; Thu, 18 Dec 2003 16:07:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX5Lg-00009y-5f for xcon@optimus.ietf.org; Thu, 18 Dec 2003 16:06:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18871 for ; Thu, 18 Dec 2003 16:06:17 -0500 (EST) From: Umesh.Chandra@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AX5Le-0000zx-00 for xcon@ietf.org; Thu, 18 Dec 2003 16:06:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AX5Ld-0000zq-00 for xcon@ietf.org; Thu, 18 Dec 2003 16:06:18 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AX5Lc-0000zn-00 for xcon@ietf.org; Thu, 18 Dec 2003 16:06:16 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hBIL6Ft14615 for ; Thu, 18 Dec 2003 23:06:16 +0200 (EET) Received: from daebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 18 Dec 2003 23:06:15 +0200 Received: from daebe010.NOE.Nokia.com ([10.241.35.110]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 18 Dec 2003 15:06:02 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] I-D ACTION:draft-ietf-xcon-conference-scenarios-00.txt Date: Thu, 18 Dec 2003 15:06:01 -0600 Message-ID: <9DF4601B5A454946B4D6F1D3AF70A5881E41DC@daebe010.americas.nokia.com> Thread-Topic: [XCON] I-D ACTION:draft-ietf-xcon-conference-scenarios-00.txt Thread-Index: AcPFpdFtPu9Ty3ufT8efVONZ0PgnNAABATkg To: X-OriginalArrivalTime: 18 Dec 2003 21:06:02.0463 (UTC) FILETIME=[BE517EF0:01C3C5AA] Content-Transfer-Encoding: quoted-printable Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hello, In section 4.1 of the draft ( Video mixing scenarios ), it says " For = video the user selects one of a set of pre-defined video presentations = offered by the server". Does it mean that end user in the conference = knows what all streams the server can offer? Does this pre-defined video = list changes dynamically ?...For example Particpant A is getting video = of particpant B, but decides to watch a mosaic of participant B and C, = it should be able to do so...The server should be able to mix the = streams of B and C and send one stream to A... Umesh -----Original Message----- From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On Behalf Of ext Internet-Drafts@ietf.org Sent: Thursday, December 18, 2003 2:29 PM Cc: xcon@ietf.org Subject: [XCON] I-D ACTION:draft-ietf-xcon-conference-scenarios-00.txt A New Internet-Draft is available from the on-line Internet-Drafts = directories. This draft is a work item of the Centralized Conferencing Working Group = of the IETF. Title : Conferencing Scenarios Author(s) : R. Even Filename : draft-ietf-xcon-conference-scenarios-00.txt Pages : 15 Date : 2003-12-18 =09 This document describes SIP conferencing scenarios. It will describe basic and advance conferencing scenarios. These conferencing scenarios will help with definition and evaluation of the requirements for SIP conferencing framework and the protocol associated with the framework. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-xcon-conference-scenarios-= 00.txt To remove yourself from the IETF Announcement list, send a message to=20 ietf-announce-request with the word unsubscribe in the body of the = message. Internet-Drafts are also available by anonymous FTP. Login with the = username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-xcon-conference-scenarios-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-xcon-conference-scenarios-00.txt". =09 NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. =09 =09 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Thu Dec 18 16:13:01 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19430 for ; Thu, 18 Dec 2003 16:13:01 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX5Rh-0000kB-Ff for xcon-archive@odin.ietf.org; Thu, 18 Dec 2003 16:12:33 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBILCXVF002853 for xcon-archive@odin.ietf.org; Thu, 18 Dec 2003 16:12:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX5Rh-0000jw-Aj for xcon-web-archive@optimus.ietf.org; Thu, 18 Dec 2003 16:12:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19271 for ; Thu, 18 Dec 2003 16:12:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AX5Rf-0001JN-00 for xcon-web-archive@ietf.org; Thu, 18 Dec 2003 16:12:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AX5Re-0001JG-00 for xcon-web-archive@ietf.org; Thu, 18 Dec 2003 16:12:31 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AX5MP-000115-02 for xcon-web-archive@ietf.org; Thu, 18 Dec 2003 16:07:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX5KP-000050-LT; Thu, 18 Dec 2003 16:05:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX5KD-0008Vz-28 for xcon@optimus.ietf.org; Thu, 18 Dec 2003 16:04:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18814 for ; Thu, 18 Dec 2003 16:04:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AX5KB-0000w6-00 for xcon@ietf.org; Thu, 18 Dec 2003 16:04:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AX5KA-0000vz-00 for xcon@ietf.org; Thu, 18 Dec 2003 16:04:46 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AX5K9-0000vt-00 for xcon@ietf.org; Thu, 18 Dec 2003 16:04:45 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hBIL4UnG064914; Thu, 18 Dec 2003 15:04:37 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FE21651.8000701@dynamicsoft.com> Date: Thu, 18 Dec 2003 15:04:17 -0600 From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: xcon@ietf.org Subject: Re: [XCON] CPCP Requirement: Anonymous participants References: <2038BCC78B1AD641891A0D1AE133DBB70118B13E@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB70118B13E@esebe019.ntc.nokia.com> X-Enigmail-Version: 0.81.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit hisham.khartabil@nokia.com wrote: > This is the first of a series of emails discussing Conference Policy Requirements. Your engagement is appreciated. > > This is in reference to requirements REQ-A6 and REQ-E9 in http://www.ietf.org/internet-drafts/draft-ietf-xcon-cpcp-reqs-00.txt > > REQ-A6: It SHOULD be possible to anonymously participate in a > conference. > > REQ-E9: It MUST be possible to allow and disallow anonymous > membership in a conference. > > Should a conference policy, using CPCP, specify if anonymous participants are allowed to join a conference? Or should this be a local policy at the server? > > There are 2 types of anonymous participants: > > 1. ones that joins a conference using a http digest username of "anonymous" and no password > 2. ones that join with a proper username and password, but hide their identity using anonynous@somewhere.com in the From-header of a SIP INVITE. The conference state package notifications shows them as anonymous participants. > > I don't think we need to allow 1. Either a conference requires everyone to know the username and password of the conference, or does not require digest authentication at all. Will you ever want to distinguish between the priviledges of an anonymous partitipant and those of non-anonymous participants? > > 2 can be provided, but we need consensus that this is a useful feature. > > Regards, > Hisham > > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Fri Dec 19 03:59:35 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29604 for ; Fri, 19 Dec 2003 03:59:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXGTS-0007PD-7S for xcon-archive@odin.ietf.org; Fri, 19 Dec 2003 03:59:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBJ8x60j028463 for xcon-archive@odin.ietf.org; Fri, 19 Dec 2003 03:59:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXGTP-0007P0-NA for xcon-web-archive@optimus.ietf.org; Fri, 19 Dec 2003 03:59:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29598 for ; Fri, 19 Dec 2003 03:59:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AXGTN-0002KU-00 for xcon-web-archive@ietf.org; Fri, 19 Dec 2003 03:59:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AXGTM-0002KN-00 for xcon-web-archive@ietf.org; Fri, 19 Dec 2003 03:59:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AXGTM-0002KK-00 for xcon-web-archive@ietf.org; Fri, 19 Dec 2003 03:59:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXGTN-0007Oj-6s; Fri, 19 Dec 2003 03:59:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXGSQ-0007IG-QI for xcon@optimus.ietf.org; Fri, 19 Dec 2003 03:58:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29592 for ; Fri, 19 Dec 2003 03:58:01 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AXGSO-0002K4-00 for xcon@ietf.org; Fri, 19 Dec 2003 03:58:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AXGSN-0002Jx-00 for xcon@ietf.org; Fri, 19 Dec 2003 03:57:59 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AXGSM-0002Ju-00 for xcon@ietf.org; Fri, 19 Dec 2003 03:57:59 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hBJ8vxt17708 for ; Fri, 19 Dec 2003 10:57:59 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 19 Dec 2003 10:57:59 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 19 Dec 2003 10:57:59 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 19 Dec 2003 10:57:58 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] CPCP Requirement: Anonymous participants Date: Fri, 19 Dec 2003 10:57:57 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797542@esebe019.ntc.nokia.com> Thread-Topic: [XCON] CPCP Requirement: Anonymous participants Thread-Index: AcPFqpnm+jLwBk1NR6yEvSWa9tRPIAAY3A/Q To: Cc: X-OriginalArrivalTime: 19 Dec 2003 08:57:58.0974 (UTC) FILETIME=[3357CDE0:01C3C60E] Content-Transfer-Encoding: quoted-printable Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] > Sent: 18.December.2003 23:04 > To: Khartabil Hisham (NMP-MSW/Helsinki) > Cc: xcon@ietf.org > Subject: Re: [XCON] CPCP Requirement: Anonymous participants >=20 >=20 > hisham.khartabil@nokia.com wrote: >=20 > > This is the first of a series of emails discussing=20 > Conference Policy Requirements. Your engagement is appreciated. > >=20 > > This is in reference to requirements REQ-A6 and REQ-E9 in=20 > http://www.ietf.org/internet-drafts/draft-ietf-xcon-cpcp-reqs-00.txt > >=20 > > REQ-A6: It SHOULD be possible to anonymously participate in a > > conference. > >=20 > > REQ-E9: It MUST be possible to allow and disallow anonymous > > membership in a conference. > >=20 > > Should a conference policy, using CPCP, specify if=20 > anonymous participants are allowed to join a conference? Or=20 > should this be a local policy at the server? > >=20 > > There are 2 types of anonymous participants: > >=20 > > 1. ones that joins a conference using a http digest=20 > username of "anonymous" and no password > > 2. ones that join with a proper username and password, but=20 > hide their identity using anonynous@somewhere.com in the=20 > From-header of a SIP INVITE. The conference state package=20 > notifications shows them as anonymous participants. > >=20 > > I don't think we need to allow 1. Either a conference=20 > requires everyone to know the username and password of the=20 > conference, or does not require digest authentication at all. >=20 > Will you ever want to distinguish between the priviledges of an=20 > anonymous partitipant and those of non-anonymous participants? If we go with (2) only, then I don't see the need to do so. /Hisham >=20 > >=20 > > 2 can be provided, but we need consensus that this is a=20 > useful feature. > >=20 > > Regards, > > Hisham > >=20 > > _______________________________________________ > > XCON mailing list > > XCON@ietf.org > > https://www1.ietf.org/mailman/listinfo/xcon >=20 >=20 >=20 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Fri Dec 19 06:15:35 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03939 for ; Fri, 19 Dec 2003 06:15:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXIb6-0003Zz-9m for xcon-archive@odin.ietf.org; Fri, 19 Dec 2003 06:15:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBJBF8ol013756 for xcon-archive@odin.ietf.org; Fri, 19 Dec 2003 06:15:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXIb6-0003Zn-2U for xcon-web-archive@optimus.ietf.org; Fri, 19 Dec 2003 06:15:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03905 for ; Fri, 19 Dec 2003 06:15:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AXIb2-0006LC-00 for xcon-web-archive@ietf.org; Fri, 19 Dec 2003 06:15:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AXIaz-0006KT-00 for xcon-web-archive@ietf.org; Fri, 19 Dec 2003 06:15:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AXIaz-0006KO-00 for xcon-web-archive@ietf.org; Fri, 19 Dec 2003 06:15:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXIb1-0003Xl-Fa; Fri, 19 Dec 2003 06:15:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXIah-0003WS-M2 for xcon@optimus.ietf.org; Fri, 19 Dec 2003 06:14:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03869 for ; Fri, 19 Dec 2003 06:14:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AXIad-0006Ix-00 for xcon@ietf.org; Fri, 19 Dec 2003 06:14:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AXIac-0006Iq-00 for xcon@ietf.org; Fri, 19 Dec 2003 06:14:39 -0500 Received: from ihemail2.lucent.com ([192.11.222.163] helo=ihemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1AXIaX-0006I6-00 for xcon@ietf.org; Fri, 19 Dec 2003 06:14:38 -0500 Received: from uk0006exch001h.wins.lucent.com (h135-86-145-57.lucent.com [135.86.145.57]) by ihemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id hBJBE1716754 for ; Fri, 19 Dec 2003 05:14:02 -0600 (CST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Fri, 19 Dec 2003 11:14:00 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB00AA77D19@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: hisham.khartabil@nokia.com, xcon@ietf.org Subject: RE: [XCON] CPCP Requirement: Anonymous participants Date: Fri, 19 Dec 2003 11:13:59 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 In answer to the questions below: If we are going to allow anonymous users, then CPCP should be allowed to set whether they are allowed for a particular conference or not. I see no mileage in a default. As regards the type of anonymous user, I see no point in 1), but 2) should be allowed. Note that anonymity of identity is more than the From header, in that you also need to cover the interrelation with RFC 3325 identities and the sip-identity draft, and/or a specification of privacy of various kinds according to RFC 3323 (header privacy should kill the From header). In respect of both these, we need to clearly indicate who can see, and who cannot see these identities. I assume that primarily the requirement applies to other participants - but are there special rights for the conference owner - the one able to do the CPCP. regards Keith Keith Drage Lucent Technologies drage@lucent.com tel: +44 1793 776249 > -----Original Message----- > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > Sent: 15 December 2003 12:54 > To: xcon@ietf.org > Subject: [XCON] CPCP Requirement: Anonymous participants > > > This is the first of a series of emails discussing Conference > Policy Requirements. Your engagement is appreciated. > > This is in reference to requirements REQ-A6 and REQ-E9 in > http://www.ietf.org/internet-drafts/draft-ietf-xcon-cpcp-reqs-00.txt > > REQ-A6: It SHOULD be possible to anonymously participate in a > conference. > > REQ-E9: It MUST be possible to allow and disallow anonymous > membership in a conference. > > Should a conference policy, using CPCP, specify if anonymous > participants are allowed to join a conference? Or should this > be a local policy at the server? > > There are 2 types of anonymous participants: > > 1. ones that joins a conference using a http digest username > of "anonymous" and no password > 2. ones that join with a proper username and password, but > hide their identity using anonynous@somewhere.com in the > From-header of a SIP INVITE. The conference state package > notifications shows them as anonymous participants. > > I don't think we need to allow 1. Either a conference > requires everyone to know the username and password of the > conference, or does not require digest authentication at all. > > 2 can be provided, but we need consensus that this is a > useful feature. > > Regards, > Hisham > > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon > _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Fri Dec 19 06:15:36 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03948 for ; Fri, 19 Dec 2003 06:15:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXIb7-0003bz-4s for xcon-archive@odin.ietf.org; Fri, 19 Dec 2003 06:15:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBJBF9v6013877 for xcon-archive@odin.ietf.org; Fri, 19 Dec 2003 06:15:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXIb7-0003bk-0d for xcon-web-archive@optimus.ietf.org; Fri, 19 Dec 2003 06:15:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03909 for ; Fri, 19 Dec 2003 06:15:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AXIb3-0006LH-00 for xcon-web-archive@ietf.org; Fri, 19 Dec 2003 06:15:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AXIaz-0006KY-00 for xcon-web-archive@ietf.org; Fri, 19 Dec 2003 06:15:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AXIaz-0006KP-00 for xcon-web-archive@ietf.org; Fri, 19 Dec 2003 06:15:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXIb1-0003Xv-Rq; Fri, 19 Dec 2003 06:15:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXIaj-0003WX-UY for xcon@optimus.ietf.org; Fri, 19 Dec 2003 06:14:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03872 for ; Fri, 19 Dec 2003 06:14:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AXIag-0006JG-00 for xcon@ietf.org; Fri, 19 Dec 2003 06:14:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AXIaf-0006J9-00 for xcon@ietf.org; Fri, 19 Dec 2003 06:14:41 -0500 Received: from ihemail2.lucent.com ([192.11.222.163] helo=ihemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1AXIae-0006I7-00 for xcon@ietf.org; Fri, 19 Dec 2003 06:14:40 -0500 Received: from uk0006exch001h.wins.lucent.com (h135-86-145-57.lucent.com [135.86.145.57]) by ihemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id hBJBE4716800 for ; Fri, 19 Dec 2003 05:14:05 -0600 (CST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Fri, 19 Dec 2003 11:14:03 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB00AA77D1B@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: Jari.Mutikainen@nokia.com, hisham.khartabil@nokia.com, xcon@ietf.org Subject: RE: [XCON] CPCP Requirement: Conference package subscribers Date: Fri, 19 Dec 2003 11:14:00 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 See below > -----Original Message----- > From: Jari.Mutikainen@nokia.com [mailto:Jari.Mutikainen@nokia.com] > Sent: 15 December 2003 14:14 > To: hisham.khartabil@nokia.com; xcon@ietf.org > Subject: RE: [XCON] CPCP Requirement: Conference package subscribers > heavily snipped > > > > > 1. Use your TEL URI in the SUBSCRIBE. Why would you use your > > SIP URI? You certainly don't have to. > > At least in IMS this is impossible. I cannot take my grand > ma's PSTN phone, write down it's E.164 number, and register > from my SIP client using this E.164 number. In my > understanding the IMS provider allows registration only from > tel URIs it has allocated to me. > This comes as part of release 6 for IMS. The it is possible to associate the same public user identity with two private user identities. and therefore register the same public user identity from two different devices (they must however have the appropriate USIM or ISIM application to hold the private user identity etc). regards Keith _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Fri Dec 19 06:15:37 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03969 for ; Fri, 19 Dec 2003 06:15:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXIb8-0003ce-Se for xcon-archive@odin.ietf.org; Fri, 19 Dec 2003 06:15:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBJBFAmj013912 for xcon-archive@odin.ietf.org; Fri, 19 Dec 2003 06:15:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXIb8-0003cI-NI for xcon-web-archive@optimus.ietf.org; Fri, 19 Dec 2003 06:15:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03917 for ; Fri, 19 Dec 2003 06:15:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AXIb4-0006LP-00 for xcon-web-archive@ietf.org; Fri, 19 Dec 2003 06:15:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AXIb0-0006Kn-00 for xcon-web-archive@ietf.org; Fri, 19 Dec 2003 06:15:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AXIaz-0006Ki-00 for xcon-web-archive@ietf.org; Fri, 19 Dec 2003 06:15:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXIb2-0003Yq-LO; Fri, 19 Dec 2003 06:15:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXIar-0003Wv-5O for xcon@optimus.ietf.org; Fri, 19 Dec 2003 06:14:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03878 for ; Fri, 19 Dec 2003 06:14:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AXIan-0006Jf-00 for xcon@ietf.org; Fri, 19 Dec 2003 06:14:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AXIal-0006JY-00 for xcon@ietf.org; Fri, 19 Dec 2003 06:14:48 -0500 Received: from ihemail2.lucent.com ([192.11.222.163] helo=ihemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1AXIal-0006I9-00 for xcon@ietf.org; Fri, 19 Dec 2003 06:14:47 -0500 Received: from uk0006exch001h.wins.lucent.com (h135-86-145-57.lucent.com [135.86.145.57]) by ihemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id hBJBEB716879 for ; Fri, 19 Dec 2003 05:14:12 -0600 (CST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Fri, 19 Dec 2003 11:14:03 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB00AA77D1C@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: hisham.khartabil@nokia.com, xcon@ietf.org Subject: RE: [XCON] CPCP Requirement: Conference package subscribers Date: Fri, 19 Dec 2003 11:14:00 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 The only additional client I could think of for this information was a presence server, but presumably that should be a PUBLISH type operation rather than a SUBSCRIBE to the conference event package. However it does raise a question of whether there should be an additional conference policy requirement relating to PUBLISH of conference information from the conference server and who to. regards Keith > -----Original Message----- > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > Sent: 15 December 2003 12:55 > To: xcon@ietf.org > Subject: [XCON] CPCP Requirement: Conference package subscribers > > > This is in reference to requirement REQ-H5 in > http://www.ietf.org/internet-drafts/draft-ietf-xcon-cpcp-reqs-00.txt > > REQ-H5: It SHOULD be possible to define users who are allowed to > subscribe to conference event package [4] > > Should this be a separate list? or should a combination of > Dial-out list, Dial-in list be sufficient? i.e. only > participants and potential participants can subscribe to the > conference event package (outside users not allowed)? > > In any case, I think the requirement needs to stay, but needs > rewording according to the conclusions we come up with that > answer the above question. > > Regards, > Hisham > > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon > _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Fri Dec 19 06:15:38 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03970 for ; Fri, 19 Dec 2003 06:15:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXIb8-0003cp-V5 for xcon-archive@odin.ietf.org; Fri, 19 Dec 2003 06:15:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBJBFAvh013926 for xcon-archive@odin.ietf.org; Fri, 19 Dec 2003 06:15:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXIb8-0003cJ-Nx for xcon-web-archive@optimus.ietf.org; Fri, 19 Dec 2003 06:15:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03918 for ; Fri, 19 Dec 2003 06:15:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AXIb4-0006LS-00 for xcon-web-archive@ietf.org; Fri, 19 Dec 2003 06:15:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AXIb0-0006Kt-00 for xcon-web-archive@ietf.org; Fri, 19 Dec 2003 06:15:06 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AXIaz-0006Ko-00 for xcon-web-archive@ietf.org; Fri, 19 Dec 2003 06:15:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXIb2-0003ZA-UR; Fri, 19 Dec 2003 06:15:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXIar-0003Wz-8f for xcon@optimus.ietf.org; Fri, 19 Dec 2003 06:14:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03880 for ; Fri, 19 Dec 2003 06:14:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AXIan-0006Ji-00 for xcon@ietf.org; Fri, 19 Dec 2003 06:14:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AXIal-0006JR-00 for xcon@ietf.org; Fri, 19 Dec 2003 06:14:48 -0500 Received: from ihemail2.lucent.com ([192.11.222.163] helo=ihemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1AXIal-0006IA-00 for xcon@ietf.org; Fri, 19 Dec 2003 06:14:47 -0500 Received: from uk0006exch001h.wins.lucent.com (h135-86-145-57.lucent.com [135.86.145.57]) by ihemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id hBJBEF716898 for ; Fri, 19 Dec 2003 05:14:15 -0600 (CST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Fri, 19 Dec 2003 11:14:03 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB00AA77D1E@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: hisham.khartabil@nokia.com, xcon@ietf.org Subject: RE: [XCON] CPCP Requirement: Floor Control Date: Fri, 19 Dec 2003 11:14:01 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 See below > -----Original Message----- > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > Sent: 15 December 2003 12:58 > To: xcon@ietf.org > Subject: [XCON] CPCP Requirement: Floor Control > > > There needs to be some floor control policy that is part of > CPCP. Requirements like: > > - Does the Conference have floor control or not OK > - Is the conference floor control moderator-driven by human > or First come first serve by automata. I am not sure this is the right pair of settings. First of all, the discussion in Minneapolis was of the opinion that there could be a number of algorithms. I am not sure whether these are configurable using CPCP, but first come first served is only one of the automatic ones. It is even conceivable that one of the actions of the moderator is to regulate the order in the queue (or "set" as we discussed in Minneapolis). Secondly, I have assumed that for floor control, there will always be a moderator, and therefore there will always be moderator control, it is just a matter of whether the floor can be automatically be granted elsewhere in the absence of a moderator instruction when the floor becomes vacant. > - How many users can have the floor at one time. OK > - If automata driven, how long is the maximum time a user can > ask for floor. Not sure automatic timeouts are useful in a conference. This to me would be moderator action. If people want it, then it must be settable to infinity. > > Does anyone have objections to such requirements in CPCP > requirements document? Any other requirements for floor > control policy? > Additionally I would add: - Assignment / removal / replacement of the moderator to the floor - Is it possible to have more than one floor in a conference, e.g. in relation to multiple media streams. The moderator for message chat may be different from the moderator controlling the audio-visual, but they could well be in the same conference. > There is one requirement that appears in > http://www.ietf.org/internet-drafts/draft-ietf-xcon-cpcp-reqs-00.txt > > REQ-F1: It MUST be possible to assign and de-assign the > users who are > allowed to manipulate floor policy. > > Regards, > Hisham > > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon > _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Fri Dec 19 06:15:38 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03995 for ; Fri, 19 Dec 2003 06:15:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXIb9-0003d7-Ix for xcon-archive@odin.ietf.org; Fri, 19 Dec 2003 06:15:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBJBFBTa013947 for xcon-archive@odin.ietf.org; Fri, 19 Dec 2003 06:15:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXIb9-0003cs-Di for xcon-web-archive@optimus.ietf.org; Fri, 19 Dec 2003 06:15:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03924 for ; Fri, 19 Dec 2003 06:15:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AXIb5-0006Lb-00 for xcon-web-archive@ietf.org; Fri, 19 Dec 2003 06:15:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AXIb0-0006L0-00 for xcon-web-archive@ietf.org; Fri, 19 Dec 2003 06:15:07 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AXIb0-0006Ku-00 for xcon-web-archive@ietf.org; Fri, 19 Dec 2003 06:15:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXIb3-0003ZU-8v; Fri, 19 Dec 2003 06:15:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXIat-0003X6-IP for xcon@optimus.ietf.org; Fri, 19 Dec 2003 06:14:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03884 for ; Fri, 19 Dec 2003 06:14:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AXIap-0006Jw-00 for xcon@ietf.org; Fri, 19 Dec 2003 06:14:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AXIao-0006Jp-00 for xcon@ietf.org; Fri, 19 Dec 2003 06:14:51 -0500 Received: from ihemail2.lucent.com ([192.11.222.163] helo=ihemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1AXIao-0006IB-00 for xcon@ietf.org; Fri, 19 Dec 2003 06:14:50 -0500 Received: from uk0006exch001h.wins.lucent.com (h135-86-145-57.lucent.com [135.86.145.57]) by ihemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id hBJBEI716938 for ; Fri, 19 Dec 2003 05:14:19 -0600 (CST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Fri, 19 Dec 2003 11:14:03 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB00AA77D20@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: hisham.khartabil@nokia.com, mhammer@cisco.com Cc: xcon@ietf.org Subject: RE: [XCON] CPCP Requirement: Hidden Participants Date: Fri, 19 Dec 2003 11:14:02 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 I believe hidden users are appropriate. I do not believe that this adds complexity to the specifications (particularly to the specification of CPCP), so I see no need to make it a DEFER as far as the specifications are concerned. It may add complexity to the implementation, so I am quite happy to see it a MAY in the requirements, so that it is optional to implement. As regards the legal implications of hidden users, then yes, there may be priveleged users that are able to request the identity of hidden users (along with an indication that they are hidden). This of course requires the enabling of such a privileged user in the first place. Secondly, it may not be necessary to identify hidden users, but merely that there are hidden users in the conference (in addition to any that may have made themselves visible). Some countries require some form of tone or announcement on voice conferences when someone else is listening in. They also require an announcement or other indication in the call is being recorded. regards Keith Keith Drage Lucent Technologies drage@lucent.com tel: +44 1793 776249 > -----Original Message----- > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > Sent: 15 December 2003 16:29 > To: mhammer@cisco.com > Cc: xcon@ietf.org > Subject: RE: [XCON] CPCP Requirement: Hidden Participants > > > > > > -----Original Message----- > > From: ext Michael Hammer [mailto:mhammer@cisco.com] > > Sent: 15.December.2003 18:17 > > To: Khartabil Hisham (NMP-MSW/Helsinki) > > Cc: xcon@ietf.org > > Subject: Re: [XCON] CPCP Requirement: Hidden Participants > > > > > > Related to this is there a requirement that, while not > revealing the > > identity of a hidden user, the conference policy contains > > state indication > > about either the presence of hidden users, or the > > possibility/preclusion > > that such hidden users may be present? > > > > I am anticipating that: > > 1) Laws may exist that require notification of such. > > That's a good point. This might require changes to the > conference event package to indicate if there are hidden > participants or not, and if so, how many. > > The question remain: is there a need for such a feature (to > hide users?)? > > Regards, > Hisham > > > 2) In some conferences, participants may want technical > > assurance that > > hidden users are not possible before they speak. > > > > Mike > > > > > > At 02:55 PM 12/15/2003 +0200, hisham.khartabil@nokia.com wrote: > > >This is in reference to requirements REQ-A7 and REQ-E10 in > > >http://www.ietf.org/internet-drafts/draft-ietf-xcon-cpcp-reqs-00.txt > > > > REQ-A7: It SHOULD be possible to participate in a conference as a > > hidden user. Hidden user is present in a conference, but > his presence > > is not revealed. > > > > REQ-E10: It MUST be possible to allow and disallow > hidden membership > > in a conference. > > > >Should a conference policy, using CPCP, specify if a user > can be hidden? > >This means that the conference state package does not report the > >participation on the hidden user. CPCP is used to identify > which users are > >hidden. The list of hidden users is only manipulated by a > privileged user > >such as the moderator. > > > >Regards, > >Hisham > > > >_______________________________________________ > >XCON mailing list > >XCON@ietf.org > >https://www1.ietf.org/mailman/listinfo/xcon > > _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Fri Dec 19 06:16:31 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04058 for ; Fri, 19 Dec 2003 06:16:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXIc0-0003nP-8o for xcon-archive@odin.ietf.org; Fri, 19 Dec 2003 06:16:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBJBG4VJ014585 for xcon-archive@odin.ietf.org; Fri, 19 Dec 2003 06:16:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXIc0-0003nA-3l for xcon-web-archive@optimus.ietf.org; Fri, 19 Dec 2003 06:16:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04043 for ; Fri, 19 Dec 2003 06:16:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AXIbw-0006OR-00 for xcon-web-archive@ietf.org; Fri, 19 Dec 2003 06:16:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AXIbv-0006OE-00 for xcon-web-archive@ietf.org; Fri, 19 Dec 2003 06:15:59 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AXIbu-0006OA-00 for xcon-web-archive@ietf.org; Fri, 19 Dec 2003 06:15:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXIby-0003js-22; Fri, 19 Dec 2003 06:16:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXIb1-0003Xy-V7 for xcon@optimus.ietf.org; Fri, 19 Dec 2003 06:15:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03902 for ; Fri, 19 Dec 2003 06:15:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AXIay-0006KK-00 for xcon@ietf.org; Fri, 19 Dec 2003 06:15:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AXIax-0006KB-00 for xcon@ietf.org; Fri, 19 Dec 2003 06:14:59 -0500 Received: from ihemail2.lucent.com ([192.11.222.163] helo=ihemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1AXIaw-0006Ic-00 for xcon@ietf.org; Fri, 19 Dec 2003 06:14:58 -0500 Received: from uk0006exch001h.wins.lucent.com (h135-86-145-57.lucent.com [135.86.145.57]) by ihemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id hBJBEP717035 for ; Fri, 19 Dec 2003 05:14:26 -0600 (CST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Fri, 19 Dec 2003 11:14:03 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB00AA77D1F@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: hisham.khartabil@nokia.com, mhammer@cisco.com Cc: Brian.Rosen@marconi.com, xcon@ietf.org Subject: RE: [XCON] CPCP Requirement: Hidden Participants Date: Fri, 19 Dec 2003 11:14:01 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 I do not agree where this going. At least as far as floor control is concerned, it should be possible for the setter of the conference policy to set the moderator for floor control, and change it. The setter of the conference policy may not even be a participant in the conference, thus making it impossible to moderate the floor. I accept that we do not want this to get too complex, but the conference policy should define who is the moderator for floor control. regards Keith > -----Original Message----- > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > Sent: 16 December 2003 08:41 > To: mhammer@cisco.com > Cc: Brian.Rosen@marconi.com; xcon@ietf.org > Subject: RE: [XCON] CPCP Requirement: Hidden Participants > > > > > > -----Original Message----- > > From: ext Michael Hammer [mailto:mhammer@cisco.com] > > Sent: 15.December.2003 19:14 > > To: Khartabil Hisham (NMP-MSW/Helsinki) > > Cc: Brian.Rosen@marconi.com; xcon@ietf.org > > Subject: RE: [XCON] CPCP Requirement: Hidden Participants > > > > > > > >At the moment it is assumed that the creator is the > > moderator. Moderating > > >a conference involves manipulating the policy. They might be > > different > > >levels of moderators, depending on what the creator assigns > > to different > > >users as privileges. Examples of privileges include who can > > manipulate > > >dial-out list, who can manipulate dial-in list, who can manipulate > > >conference info, who can expel users, who can manipulate > > floor control > > >policy, etc. > > > > > >As Brian noted a couple of times, we don't want to get into > > privileges at > > >the moment due to complexity. > > > > So if moderator is a privilege, then I take it there will be > > no mention of > > moderators. > > If there is, it would mean creator (until we make progress on > the privileges stuff). > > /Hisham > > > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon > _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Fri Dec 19 06:16:33 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04073 for ; Fri, 19 Dec 2003 06:16:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXIc2-0003no-RX for xcon-archive@odin.ietf.org; Fri, 19 Dec 2003 06:16:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBJBG6Tp014610 for xcon-archive@odin.ietf.org; Fri, 19 Dec 2003 06:16:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXIc2-0003nZ-Mf for xcon-web-archive@optimus.ietf.org; Fri, 19 Dec 2003 06:16:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04054 for ; Fri, 19 Dec 2003 06:16:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AXIby-0006Oz-00 for xcon-web-archive@ietf.org; Fri, 19 Dec 2003 06:16:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AXIbw-0006Ob-00 for xcon-web-archive@ietf.org; Fri, 19 Dec 2003 06:16:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AXIbw-0006OY-00 for xcon-web-archive@ietf.org; Fri, 19 Dec 2003 06:16:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXIbz-0003lw-FP; Fri, 19 Dec 2003 06:16:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXIb0-0003XY-V6 for xcon@optimus.ietf.org; Fri, 19 Dec 2003 06:15:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03899 for ; Fri, 19 Dec 2003 06:14:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AXIax-0006K8-00 for xcon@ietf.org; Fri, 19 Dec 2003 06:14:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AXIav-0006K1-00 for xcon@ietf.org; Fri, 19 Dec 2003 06:14:58 -0500 Received: from ihemail2.lucent.com ([192.11.222.163] helo=ihemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1AXIav-0006Ib-00 for xcon@ietf.org; Fri, 19 Dec 2003 06:14:57 -0500 Received: from uk0006exch001h.wins.lucent.com (h135-86-145-57.lucent.com [135.86.145.57]) by ihemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id hBJBEM716975 for ; Fri, 19 Dec 2003 05:14:22 -0600 (CST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Fri, 19 Dec 2003 11:14:03 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB00AA77D1D@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: hisham.khartabil@nokia.com, Brian.Rosen@marconi.com, xcon@ietf.org Subject: RE: [XCON] CPCP Requirement: de-activating a conference Date: Fri, 19 Dec 2003 11:14:01 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 You seem to be ending defining an inactivated conference due to a lack of flexbility over start and stop times. What is to stop you having multiple start and stop times that are completely independent of regular scheduling? If the conference them has a stop specified sometime in the middle, and a subsequent restart, how is that different from an inactivated conference? regards KeithKeith Drage Lucent Technologies drage@lucent.com tel: +44 1793 776249 > -----Original Message----- > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > Sent: 15 December 2003 15:21 > To: Brian.Rosen@marconi.com; xcon@ietf.org > Subject: RE: [XCON] CPCP Requirement: de-activating a conference > > > > > > -----Original Message----- > > From: ext Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > Sent: 15.December.2003 16:25 > > To: Khartabil Hisham (NMP-MSW/Helsinki); xcon@ietf.org > > Subject: RE: [XCON] CPCP Requirement: de-activating a conference > > > > > > Again, I'm worried about "privileged users". I think we need > > to finish > > some discussions we started a while ago that essentially are > > semantics. > > We can assume it is the moderator for now. > > > What is an "inactivated" conference, and how does it differ from a > > conference that can be re-instantiated (a weekly meeting > for example)? > > > A long lived conference is one that runs for months (chat > sessions on the internet seem to run for that long). They are > not repeated, but instead are constantly running. > > An administrator, for maintenance reasons, might want to > de-activate a conference for a short period of time. > > Of course the administrator can kick everyone out by sending > them BYE requests and redefining the conference start time. > But it has the disadvantage that the inactivity time for > maintenance cannot be scheduled. Do we want to be able to > schedule such event for long lived conferences? > > Regards, > Hisham > > > > > Brian > > > > > -----Original Message----- > > > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > > Sent: Monday, December 15, 2003 7:57 AM > > To: xcon@ietf.org > > Subject: [XCON] CPCP Requirement: de-activating a conference > > > > > > This is in reference to requirement REQ-B9 in > > http://www.ietf.org/internet-drafts/draft-ietf-xcon-cpcp-reqs-00.txt > > > > REQ-B9: It MUST be possible to inactive a conference for defined > > period of time. > > > > There are start and stop times for a conference. A conference > > might live for days, weeks or even months. Should a > > conference policy, using CPCP, allow a privileged user to > > de-activate a conference for a period of time within the > > start and stop times of a conference? Examples are > > administrator is performing some maintenance. > > > > Regards, > > Hisham > > > > _______________________________________________ > > XCON mailing list > > XCON@ietf.org > > https://www1.ietf.org/mailman/listinfo/xcon > > > _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Fri Dec 19 07:03:37 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03997 for ; Fri, 19 Dec 2003 06:15:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXIb8-0003cH-Lr for xcon-archive@odin.ietf.org; Fri, 19 Dec 2003 06:15:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBJBFA0r013895 for xcon-archive@odin.ietf.org; Fri, 19 Dec 2003 06:15:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXIb8-0003c2-DN for xcon-web-archive@optimus.ietf.org; Fri, 19 Dec 2003 06:15:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03913 for ; Fri, 19 Dec 2003 06:15:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AXIb4-0006LM-00 for xcon-web-archive@ietf.org; Fri, 19 Dec 2003 06:15:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AXIaz-0006Ke-00 for xcon-web-archive@ietf.org; Fri, 19 Dec 2003 06:15:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AXIaz-0006KR-00 for xcon-web-archive@ietf.org; Fri, 19 Dec 2003 06:15:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXIb2-0003Y7-4W; Fri, 19 Dec 2003 06:15:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXIak-0003Wc-8o for xcon@optimus.ietf.org; Fri, 19 Dec 2003 06:14:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03875 for ; Fri, 19 Dec 2003 06:14:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AXIag-0006JJ-00 for xcon@ietf.org; Fri, 19 Dec 2003 06:14:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AXIae-0006J2-00 for xcon@ietf.org; Fri, 19 Dec 2003 06:14:42 -0500 Received: from ihemail2.lucent.com ([192.11.222.163] helo=ihemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1AXIae-0006I8-00 for xcon@ietf.org; Fri, 19 Dec 2003 06:14:40 -0500 Received: from uk0006exch001h.wins.lucent.com (h135-86-145-57.lucent.com [135.86.145.57]) by ihemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id hBJBE8716841 for ; Fri, 19 Dec 2003 05:14:08 -0600 (CST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Fri, 19 Dec 2003 11:14:03 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB00AA77D1A@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "Rosen, Brian" , "'hisham.khartabil@nokia.com'" , xcon@ietf.org Subject: RE: [XCON] CPCP Requirement: Conference and Host Info Date: Fri, 19 Dec 2003 11:14:00 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Dont these all tend to be "look and feel" type attributes, where different vendors might want to offer different sets of information. Is to not possible just to compress these into generic requirements whereby the conference vendor MAY define a number of attributes for a conference, which CPCP has the ability to set, modify or delete for a particular conference - then put an e.g. list of things that this may cover. I dont see any reason for a MUST on any of these in particular, but I see no reason not to have any of them. regards Keith Keith Drage Lucent Technologies drage@lucent.com tel: +44 1793 776249 > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > Sent: 15 December 2003 14:20 > To: 'hisham.khartabil@nokia.com'; xcon@ietf.org > Subject: RE: [XCON] CPCP Requirement: Conference and Host Info > > > I think its simple to have these. If we were prioritizing, I'd > leave the last two off, but I don't see any reason to not > implement them. > > Brian > > > -----Original Message----- > > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > > Sent: Monday, December 15, 2003 7:57 AM > > To: xcon@ietf.org > > Subject: [XCON] CPCP Requirement: Conference and Host Info > > > > > > This is in reference to requirements REQ-B1 to REG-B6, and > > REG-B10 in > > http://www.ietf.org/internet-drafts/draft-ietf-xcon-cpcp-reqs-00.txt > > > > REQ-B1: It MUST be possible to set, modify and delete a > conference > > Subject. > > > > REQ-B2: It MUST be possible to set, modify and delete > > conference URI > > display name. > > > > REQ-B3: It MUST be possible to set, modify and delete conference > > creator information. > > > > REQ-B4: It MUST be possible to set, modify and delete > > conference URI > > link for more information. > > > > REQ-B5: It MUST be possible to set, modify and delete > > conference host > > contact information. > > > > REQ-B6: It MUST be possible to set, modify and delete short > > conference session description. > > > > REQ-B10: It SHOULD be possible to set, modify and delete > conference > > Keywords. (This may be useful e.g. for search engines). > > > > I think a conference subject and display name as well as > > conference session description are useful. Perhaps the > > conference session description can appear on a conference web > > sight. What about conference host and creator information? > > > > I would like opinions on what people deem necessary > > information. Of course, we can have all if needed. > > > > Regards, > > Hisham > > > > _______________________________________________ > > XCON mailing list > > XCON@ietf.org > > https://www1.ietf.org/mailman/listinfo/xcon > > > > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon > _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Fri Dec 19 08:39:36 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08735 for ; Fri, 19 Dec 2003 08:39:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXKqR-0000gi-0o for xcon-archive@odin.ietf.org; Fri, 19 Dec 2003 08:39:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBJDd6rX002638 for xcon-archive@odin.ietf.org; Fri, 19 Dec 2003 08:39:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXKqQ-0000gS-Qq for xcon-web-archive@optimus.ietf.org; Fri, 19 Dec 2003 08:39:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08715 for ; Fri, 19 Dec 2003 08:39:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AXKqO-0003D2-00 for xcon-web-archive@ietf.org; Fri, 19 Dec 2003 08:39:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AXKqM-0003Cu-00 for xcon-web-archive@ietf.org; Fri, 19 Dec 2003 08:39:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AXKqM-0003Cr-00 for xcon-web-archive@ietf.org; Fri, 19 Dec 2003 08:39:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXKqK-0000g0-VA; Fri, 19 Dec 2003 08:39:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXKqA-0000fT-8h for xcon@optimus.ietf.org; Fri, 19 Dec 2003 08:38:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08691 for ; Fri, 19 Dec 2003 08:38:48 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AXKq8-0003B1-00 for xcon@ietf.org; Fri, 19 Dec 2003 08:38:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AXKpu-0003Ai-00 for xcon@ietf.org; Fri, 19 Dec 2003 08:38:35 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AXKpt-0003AN-00 for xcon@ietf.org; Fri, 19 Dec 2003 08:38:33 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hBJDcK020990 for ; Fri, 19 Dec 2003 15:38:20 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 19 Dec 2003 15:38:15 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 19 Dec 2003 15:38:14 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] CPCP Requirement: Anonymous participants Date: Fri, 19 Dec 2003 15:38:14 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB70118B15B@esebe019.ntc.nokia.com> Thread-Topic: [XCON] CPCP Requirement: Anonymous participants Thread-Index: AcPGIWdOOLTh0ox+TUOV5H5uMuZlvwAEwQUA To: , X-OriginalArrivalTime: 19 Dec 2003 13:38:14.0420 (UTC) FILETIME=[5A213D40:01C3C635] Content-Transfer-Encoding: quoted-printable Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ext Drage, Keith (Keith) [mailto:drage@lucent.com] > Sent: 19.December.2003 13:14 > To: Khartabil Hisham (NMP-MSW/Helsinki); xcon@ietf.org > Subject: RE: [XCON] CPCP Requirement: Anonymous participants >=20 >=20 > In answer to the questions below: >=20 > If we are going to allow anonymous users, then CPCP should be=20 > allowed to set whether they are allowed for a particular=20 > conference or not. I see no mileage in a default. >=20 > As regards the type of anonymous user, I see no point in 1),=20 > but 2) should be allowed. Note that anonymity of identity is=20 > more than the From header, in that you also need to cover the=20 > interrelation with RFC 3325 identities and the sip-identity=20 > draft, and/or a specification of privacy of various kinds=20 > according to RFC 3323 (header privacy should kill the From header). >=20 > In respect of both these, we need to clearly indicate who can=20 > see, and who cannot see these identities. I assume that=20 > primarily the requirement applies to other participants - but=20 > are there special rights for the conference owner - the one=20 > able to do the CPCP. I think it should be one or the other. Either complete anonymity from = users, including moderator, or excluding moderator. For the sake of simplicity (and not to start the privileges discussion = again), I would choose complete anonymity, including anonymity from = moderators. /Hisham >=20 > regards >=20 > Keith >=20 > Keith Drage > Lucent Technologies > drage@lucent.com > tel: +44 1793 776249 >=20 >=20 > > -----Original Message----- > > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > > Sent: 15 December 2003 12:54 > > To: xcon@ietf.org > > Subject: [XCON] CPCP Requirement: Anonymous participants > >=20 > >=20 > > This is the first of a series of emails discussing Conference=20 > > Policy Requirements. Your engagement is appreciated. > >=20 > > This is in reference to requirements REQ-A6 and REQ-E9 in=20 > > http://www.ietf.org/internet-drafts/draft-ietf-xcon-cpcp-reqs-00.txt > >=20 > > REQ-A6: It SHOULD be possible to anonymously participate in a > > conference. > >=20 > > REQ-E9: It MUST be possible to allow and disallow anonymous > > membership in a conference. > >=20 > > Should a conference policy, using CPCP, specify if anonymous=20 > > participants are allowed to join a conference? Or should this=20 > > be a local policy at the server? > >=20 > > There are 2 types of anonymous participants: > >=20 > > 1. ones that joins a conference using a http digest username=20 > > of "anonymous" and no password > > 2. ones that join with a proper username and password, but=20 > > hide their identity using anonynous@somewhere.com in the=20 > > From-header of a SIP INVITE. The conference state package=20 > > notifications shows them as anonymous participants. > >=20 > > I don't think we need to allow 1. Either a conference=20 > > requires everyone to know the username and password of the=20 > > conference, or does not require digest authentication at all. > >=20 > > 2 can be provided, but we need consensus that this is a=20 > > useful feature. > >=20 > > Regards, > > Hisham > >=20 > > _______________________________________________ > > XCON mailing list > > XCON@ietf.org > > https://www1.ietf.org/mailman/listinfo/xcon > >=20 >=20 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Fri Dec 19 09:02:36 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09389 for ; Fri, 19 Dec 2003 09:02:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXLCh-0001G9-70 for xcon-archive@odin.ietf.org; Fri, 19 Dec 2003 09:02:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBJE27Vc004835 for xcon-archive@odin.ietf.org; Fri, 19 Dec 2003 09:02:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXLCh-0001Fu-1Q for xcon-web-archive@optimus.ietf.org; Fri, 19 Dec 2003 09:02:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09318 for ; Fri, 19 Dec 2003 09:02:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AXLCf-0003o7-00 for xcon-web-archive@ietf.org; Fri, 19 Dec 2003 09:02:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AXLCb-0003nX-00 for xcon-web-archive@ietf.org; Fri, 19 Dec 2003 09:02:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AXLCb-0003nT-00 for xcon-web-archive@ietf.org; Fri, 19 Dec 2003 09:02:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXLCb-0001EP-Lj; Fri, 19 Dec 2003 09:02:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXLBp-0001Dk-6h for xcon@optimus.ietf.org; Fri, 19 Dec 2003 09:01:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09273 for ; Fri, 19 Dec 2003 09:01:11 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AXLBn-0003lF-00 for xcon@ietf.org; Fri, 19 Dec 2003 09:01:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AXLBm-0003l8-00 for xcon@ietf.org; Fri, 19 Dec 2003 09:01:11 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AXLBm-0003l4-00 for xcon@ietf.org; Fri, 19 Dec 2003 09:01:10 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hBJE18U24479 for ; Fri, 19 Dec 2003 16:01:08 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 19 Dec 2003 16:01:06 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 19 Dec 2003 16:01:06 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] CPCP Requirement: de-activating a conference Date: Fri, 19 Dec 2003 16:01:05 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB70118B15D@esebe019.ntc.nokia.com> Thread-Topic: [XCON] CPCP Requirement: de-activating a conference Thread-Index: AcPGIUAnLv8ctENNQuW4A1PPMyIzfwAFnA9A To: , , X-OriginalArrivalTime: 19 Dec 2003 14:01:06.0394 (UTC) FILETIME=[8BE3DBA0:01C3C638] Content-Transfer-Encoding: quoted-printable Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable You are getting into the solution already, so I take it that you agree = that such a requirement is needed. Having multiple start and stop times has the side effect that a = conference policy will forever grow. In the solution we propose using = XCAP, we have start-time, stop-time, and repeat intervals. Having = multiple start and stop times where there is a repeat interval will = cause unnecessary complexity. To accommodate setting a long lived conference inactive to a short = period of time, we have defined an inactive start and stop times. I guess we can defer the argument about what the solution should look = like until we agree on the requirement. Regards, Hisham > -----Original Message----- > From: ext Drage, Keith (Keith) [mailto:drage@lucent.com] > Sent: 19.December.2003 13:14 > To: Khartabil Hisham (NMP-MSW/Helsinki); Brian.Rosen@marconi.com; > xcon@ietf.org > Subject: RE: [XCON] CPCP Requirement: de-activating a conference >=20 >=20 > You seem to be ending defining an inactivated conference due=20 > to a lack of flexbility over start and stop times. What is to=20 > stop you having multiple start and stop times that are=20 > completely independent of regular scheduling? >=20 > If the conference them has a stop specified sometime in the=20 > middle, and a subsequent restart, how is that different from=20 > an inactivated conference? >=20 > regards >=20 > KeithKeith Drage > Lucent Technologies > drage@lucent.com > tel: +44 1793 776249 >=20 >=20 > > -----Original Message----- > > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > > Sent: 15 December 2003 15:21 > > To: Brian.Rosen@marconi.com; xcon@ietf.org > > Subject: RE: [XCON] CPCP Requirement: de-activating a conference > >=20 > >=20 > >=20 > >=20 > > > -----Original Message----- > > > From: ext Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > > Sent: 15.December.2003 16:25 > > > To: Khartabil Hisham (NMP-MSW/Helsinki); xcon@ietf.org > > > Subject: RE: [XCON] CPCP Requirement: de-activating a conference > > >=20 > > >=20 > > > Again, I'm worried about "privileged users". I think we need=20 > > > to finish > > > some discussions we started a while ago that essentially are=20 > > > semantics. > >=20 > > We can assume it is the moderator for now. > >=20 > > > What is an "inactivated" conference, and how does it differ from a > > > conference that can be re-instantiated (a weekly meeting=20 > > for example)? > >=20 > >=20 > > A long lived conference is one that runs for months (chat=20 > > sessions on the internet seem to run for that long). They are=20 > > not repeated, but instead are constantly running. > >=20 > > An administrator, for maintenance reasons, might want to=20 > > de-activate a conference for a short period of time. > >=20 > > Of course the administrator can kick everyone out by sending=20 > > them BYE requests and redefining the conference start time.=20 > > But it has the disadvantage that the inactivity time for=20 > > maintenance cannot be scheduled. Do we want to be able to=20 > > schedule such event for long lived conferences? > >=20 > > Regards, > > Hisham > >=20 > > >=20 > > > Brian > > >=20 > > > > -----Original Message----- > > > > From: hisham.khartabil@nokia.com=20 > [mailto:hisham.khartabil@nokia.com] > > > Sent: Monday, December 15, 2003 7:57 AM > > > To: xcon@ietf.org > > > Subject: [XCON] CPCP Requirement: de-activating a conference > > >=20 > > >=20 > > > This is in reference to requirement REQ-B9 in=20 > > >=20 > http://www.ietf.org/internet-drafts/draft-ietf-xcon-cpcp-reqs-00.txt > > >=20 > > > REQ-B9: It MUST be possible to inactive a conference=20 > for defined > > > period of time. > > >=20 > > > There are start and stop times for a conference. A conference=20 > > > might live for days, weeks or even months. Should a=20 > > > conference policy, using CPCP, allow a privileged user to=20 > > > de-activate a conference for a period of time within the=20 > > > start and stop times of a conference? Examples are=20 > > > administrator is performing some maintenance. > > >=20 > > > Regards, > > > Hisham > > >=20 > > > _______________________________________________ > > > XCON mailing list > > > XCON@ietf.org > > > https://www1.ietf.org/mailman/listinfo/xcon > > >=20 > >=20 >=20 > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon >=20 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Fri Dec 19 09:45:34 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10638 for ; Fri, 19 Dec 2003 09:45:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXLsI-0003YB-6d for xcon-archive@odin.ietf.org; Fri, 19 Dec 2003 09:45:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBJEj68A013641 for xcon-archive@odin.ietf.org; Fri, 19 Dec 2003 09:45:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXLsH-0003X2-SA for xcon-web-archive@optimus.ietf.org; Fri, 19 Dec 2003 09:45:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10619 for ; Fri, 19 Dec 2003 09:45:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AXLsG-000576-00 for xcon-web-archive@ietf.org; Fri, 19 Dec 2003 09:45:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AXLsD-00056z-00 for xcon-web-archive@ietf.org; Fri, 19 Dec 2003 09:45:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AXLsD-00056w-00 for xcon-web-archive@ietf.org; Fri, 19 Dec 2003 09:45:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXLsE-0003WS-QN; Fri, 19 Dec 2003 09:45:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXLrX-0003VF-Pl for xcon@optimus.ietf.org; Fri, 19 Dec 2003 09:44:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10616 for ; Fri, 19 Dec 2003 09:44:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AXLrV-00056W-00 for xcon@ietf.org; Fri, 19 Dec 2003 09:44:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AXLrU-00056P-00 for xcon@ietf.org; Fri, 19 Dec 2003 09:44:17 -0500 Received: from auemail1.lucent.com ([192.11.223.161] helo=auemail1.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1AXLrU-00054W-00 for xcon@ietf.org; Fri, 19 Dec 2003 09:44:16 -0500 Received: from uk0006exch001h.wins.lucent.com (h135-86-145-57.lucent.com [135.86.145.57]) by auemail1.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id hBJEhcc08163 for ; Fri, 19 Dec 2003 08:43:39 -0600 (CST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Fri, 19 Dec 2003 14:43:30 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB00439EF7A@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "'hisham.khartabil@nokia.com'" , "Drage, Keith (Keith)" , Brian.Rosen@marconi.com, xcon@ietf.org Subject: RE: [XCON] CPCP Requirement: de-activating a conference Date: Fri, 19 Dec 2003 14:43:28 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 At the moment I was not trying to propose words, I was merely trying to see how your inactive state was different from the conference having been stopped. So far you have been asked that question twice, once by me, and once by someone else, and you have gone into statements about side effects, but you have never actually answered the question. So, is it a different state, or not? Once we understand that, then we can look at the words. regards Keith Keith Drage Lucent Technologies drage@lucent.com tel: +44 1793 776249 > -----Original Message----- > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > Sent: 19 December 2003 14:01 > To: drage@lucent.com; Brian.Rosen@marconi.com; xcon@ietf.org > Subject: RE: [XCON] CPCP Requirement: de-activating a conference > > > You are getting into the solution already, so I take it that > you agree that such a requirement is needed. > > Having multiple start and stop times has the side effect that > a conference policy will forever grow. In the solution we > propose using XCAP, we have start-time, stop-time, and repeat > intervals. Having multiple start and stop times where there > is a repeat interval will cause unnecessary complexity. > > To accommodate setting a long lived conference inactive to a > short period of time, we have defined an inactive start and > stop times. > > I guess we can defer the argument about what the solution > should look like until we agree on the requirement. > > Regards, > Hisham > > > -----Original Message----- > > From: ext Drage, Keith (Keith) [mailto:drage@lucent.com] > > Sent: 19.December.2003 13:14 > > To: Khartabil Hisham (NMP-MSW/Helsinki); Brian.Rosen@marconi.com; > > xcon@ietf.org > > Subject: RE: [XCON] CPCP Requirement: de-activating a conference > > > > > > You seem to be ending defining an inactivated conference due > > to a lack of flexbility over start and stop times. What is to > > stop you having multiple start and stop times that are > > completely independent of regular scheduling? > > > > If the conference them has a stop specified sometime in the > > middle, and a subsequent restart, how is that different from > > an inactivated conference? > > > > regards > > > > KeithKeith Drage > > Lucent Technologies > > drage@lucent.com > > tel: +44 1793 776249 > > > > > > > -----Original Message----- > > > From: hisham.khartabil@nokia.com > [mailto:hisham.khartabil@nokia.com] > > > Sent: 15 December 2003 15:21 > > > To: Brian.Rosen@marconi.com; xcon@ietf.org > > > Subject: RE: [XCON] CPCP Requirement: de-activating a conference > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: ext Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > > > Sent: 15.December.2003 16:25 > > > > To: Khartabil Hisham (NMP-MSW/Helsinki); xcon@ietf.org > > > > Subject: RE: [XCON] CPCP Requirement: de-activating a conference > > > > > > > > > > > > Again, I'm worried about "privileged users". I think we need > > > > to finish > > > > some discussions we started a while ago that essentially are > > > > semantics. > > > > > > We can assume it is the moderator for now. > > > > > > > What is an "inactivated" conference, and how does it > differ from a > > > > conference that can be re-instantiated (a weekly meeting > > > for example)? > > > > > > > > > A long lived conference is one that runs for months (chat > > > sessions on the internet seem to run for that long). They are > > > not repeated, but instead are constantly running. > > > > > > An administrator, for maintenance reasons, might want to > > > de-activate a conference for a short period of time. > > > > > > Of course the administrator can kick everyone out by sending > > > them BYE requests and redefining the conference start time. > > > But it has the disadvantage that the inactivity time for > > > maintenance cannot be scheduled. Do we want to be able to > > > schedule such event for long lived conferences? > > > > > > Regards, > > > Hisham > > > > > > > > > > > Brian > > > > > > > > > -----Original Message----- > > > > > From: hisham.khartabil@nokia.com > > [mailto:hisham.khartabil@nokia.com] > > > > Sent: Monday, December 15, 2003 7:57 AM > > > > To: xcon@ietf.org > > > > Subject: [XCON] CPCP Requirement: de-activating a conference > > > > > > > > > > > > This is in reference to requirement REQ-B9 in > > > > > > http://www.ietf.org/internet-drafts/draft-ietf-xcon-cpcp-reqs-00.txt > > > > > > > > REQ-B9: It MUST be possible to inactive a conference > > for defined > > > > period of time. > > > > > > > > There are start and stop times for a conference. A conference > > > > might live for days, weeks or even months. Should a > > > > conference policy, using CPCP, allow a privileged user to > > > > de-activate a conference for a period of time within the > > > > start and stop times of a conference? Examples are > > > > administrator is performing some maintenance. > > > > > > > > Regards, > > > > Hisham > > > > > > > > _______________________________________________ > > > > XCON mailing list > > > > XCON@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/xcon > > > > > > > > > > > _______________________________________________ > > XCON mailing list > > XCON@ietf.org > > https://www1.ietf.org/mailman/listinfo/xcon > > > _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Fri Dec 19 10:11:34 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12206 for ; Fri, 19 Dec 2003 10:11:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXMHR-0004eo-Ue for xcon-archive@odin.ietf.org; Fri, 19 Dec 2003 10:11:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBJFB57K017896 for xcon-archive@odin.ietf.org; Fri, 19 Dec 2003 10:11:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXMHR-0004eM-Nv for xcon-web-archive@optimus.ietf.org; Fri, 19 Dec 2003 10:11:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12157 for ; Fri, 19 Dec 2003 10:11:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AXMHP-0005vc-00 for xcon-web-archive@ietf.org; Fri, 19 Dec 2003 10:11:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AXMHO-0005vU-00 for xcon-web-archive@ietf.org; Fri, 19 Dec 2003 10:11:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AXMHO-0005vR-00 for xcon-web-archive@ietf.org; Fri, 19 Dec 2003 10:11:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXMHO-0004dq-OS; Fri, 19 Dec 2003 10:11:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXMH2-0004cx-8Z for xcon@optimus.ietf.org; Fri, 19 Dec 2003 10:10:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12094 for ; Fri, 19 Dec 2003 10:10:22 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AXMGk-0005vB-00 for xcon@ietf.org; Fri, 19 Dec 2003 10:10:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AXMGj-0005v4-00 for xcon@ietf.org; Fri, 19 Dec 2003 10:10:22 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AXMGi-0005v1-00 for xcon@ietf.org; Fri, 19 Dec 2003 10:10:21 -0500 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hBJFAJ027404 for ; Fri, 19 Dec 2003 17:10:19 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 19 Dec 2003 17:10:15 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 19 Dec 2003 17:10:17 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] CPCP Requirement: de-activating a conference Date: Fri, 19 Dec 2003 17:10:16 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB70118B15E@esebe019.ntc.nokia.com> Thread-Topic: [XCON] CPCP Requirement: de-activating a conference Thread-Index: AcPGPrHrQHXD9Pg9RRuzCVXLHwoxrQAAM6WQ To: , , X-OriginalArrivalTime: 19 Dec 2003 15:10:17.0145 (UTC) FILETIME=[35EE3290:01C3C642] Content-Transfer-Encoding: quoted-printable Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Your question is slightly different that Brian's. Here is a copy paste = from what I replied to Brian: ------------------ A long lived conference is one that runs for months (chat sessions on = the internet seem to run for that long). They are not repeated, but = instead are constantly running. An administrator, for maintenance reasons, might want to de-activate a = conference for a short period of time. ------------------------------ In this case, there is no difference in meaning when you say "stopping" = or "deactivating" the conference. But since you are stopping the = conference for a short period of time then restarting it again, and you = do not want to affect the overall start and stop time of the conference, = then you are really just making the conference inactive. Maybe inactive = in the wrong word here. Maybe suspend is a better word. You are = suspending the conference. The other scenario is that the conference does not have to be running = yet. Someone might schedule a conference starting Monday next week and = stop 3 months from Monday. Moments later, the administrator decides that = in 2 weekends time, he will suspend all running conferences. The = administrator can immediately schedule such event before the meeting = starts on Monday. Brian was asking what the difference is between de-activating a = conference and conference repeats. I guess you can think of as such, but = it is not the same thing. Certainly the solution can incorporate both, = but the 2 need to be recognised a separate requirements. I hope what I state above answers his question (and your for that matter = :) Regards, Hisham > -----Original Message----- > From: ext Drage, Keith (Keith) [mailto:drage@lucent.com] > Sent: 19.December.2003 16:43 > To: Khartabil Hisham (NMP-MSW/Helsinki); Drage, Keith (Keith); > Brian.Rosen@marconi.com; xcon@ietf.org > Subject: RE: [XCON] CPCP Requirement: de-activating a conference >=20 >=20 > At the moment I was not trying to propose words, I was merely=20 > trying to see how your inactive state was different from the=20 > conference having been stopped. >=20 > So far you have been asked that question twice, once by me,=20 > and once by someone else, and you have gone into statements=20 > about side effects, but you have never actually answered the question. >=20 > So, is it a different state, or not? >=20 > Once we understand that, then we can look at the words. >=20 > regards >=20 > Keith >=20 > Keith Drage > Lucent Technologies > drage@lucent.com > tel: +44 1793 776249 >=20 >=20 > > -----Original Message----- > > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > > Sent: 19 December 2003 14:01 > > To: drage@lucent.com; Brian.Rosen@marconi.com; xcon@ietf.org > > Subject: RE: [XCON] CPCP Requirement: de-activating a conference > >=20 > >=20 > > You are getting into the solution already, so I take it that=20 > > you agree that such a requirement is needed. > >=20 > > Having multiple start and stop times has the side effect that=20 > > a conference policy will forever grow. In the solution we=20 > > propose using XCAP, we have start-time, stop-time, and repeat=20 > > intervals. Having multiple start and stop times where there=20 > > is a repeat interval will cause unnecessary complexity. > >=20 > > To accommodate setting a long lived conference inactive to a=20 > > short period of time, we have defined an inactive start and=20 > > stop times. > >=20 > > I guess we can defer the argument about what the solution=20 > > should look like until we agree on the requirement. > >=20 > > Regards, > > Hisham > >=20 > > > -----Original Message----- > > > From: ext Drage, Keith (Keith) [mailto:drage@lucent.com] > > > Sent: 19.December.2003 13:14 > > > To: Khartabil Hisham (NMP-MSW/Helsinki); Brian.Rosen@marconi.com; > > > xcon@ietf.org > > > Subject: RE: [XCON] CPCP Requirement: de-activating a conference > > >=20 > > >=20 > > > You seem to be ending defining an inactivated conference due=20 > > > to a lack of flexbility over start and stop times. What is to=20 > > > stop you having multiple start and stop times that are=20 > > > completely independent of regular scheduling? > > >=20 > > > If the conference them has a stop specified sometime in the=20 > > > middle, and a subsequent restart, how is that different from=20 > > > an inactivated conference? > > >=20 > > > regards > > >=20 > > > KeithKeith Drage > > > Lucent Technologies > > > drage@lucent.com > > > tel: +44 1793 776249 > > >=20 > > >=20 > > > > -----Original Message----- > > > > From: hisham.khartabil@nokia.com=20 > > [mailto:hisham.khartabil@nokia.com] > > > > Sent: 15 December 2003 15:21 > > > > To: Brian.Rosen@marconi.com; xcon@ietf.org > > > > Subject: RE: [XCON] CPCP Requirement: de-activating a conference > > > >=20 > > > >=20 > > > >=20 > > > >=20 > > > > > -----Original Message----- > > > > > From: ext Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > > > > Sent: 15.December.2003 16:25 > > > > > To: Khartabil Hisham (NMP-MSW/Helsinki); xcon@ietf.org > > > > > Subject: RE: [XCON] CPCP Requirement: de-activating a=20 > conference > > > > >=20 > > > > >=20 > > > > > Again, I'm worried about "privileged users". I think we need=20 > > > > > to finish > > > > > some discussions we started a while ago that essentially are=20 > > > > > semantics. > > > >=20 > > > > We can assume it is the moderator for now. > > > >=20 > > > > > What is an "inactivated" conference, and how does it=20 > > differ from a > > > > > conference that can be re-instantiated (a weekly meeting=20 > > > > for example)? > > > >=20 > > > >=20 > > > > A long lived conference is one that runs for months (chat=20 > > > > sessions on the internet seem to run for that long). They are=20 > > > > not repeated, but instead are constantly running. > > > >=20 > > > > An administrator, for maintenance reasons, might want to=20 > > > > de-activate a conference for a short period of time. > > > >=20 > > > > Of course the administrator can kick everyone out by sending=20 > > > > them BYE requests and redefining the conference start time.=20 > > > > But it has the disadvantage that the inactivity time for=20 > > > > maintenance cannot be scheduled. Do we want to be able to=20 > > > > schedule such event for long lived conferences? > > > >=20 > > > > Regards, > > > > Hisham > > > >=20 > > > > >=20 > > > > > Brian > > > > >=20 > > > > > > -----Original Message----- > > > > > > From: hisham.khartabil@nokia.com=20 > > > [mailto:hisham.khartabil@nokia.com] > > > > > Sent: Monday, December 15, 2003 7:57 AM > > > > > To: xcon@ietf.org > > > > > Subject: [XCON] CPCP Requirement: de-activating a conference > > > > >=20 > > > > >=20 > > > > > This is in reference to requirement REQ-B9 in=20 > > > > >=20 > > >=20 http://www.ietf.org/internet-drafts/draft-ietf-xcon-cpcp-reqs-00.txt > > > >=20 > > > > REQ-B9: It MUST be possible to inactive a conference=20 > > for defined > > > > period of time. > > > >=20 > > > > There are start and stop times for a conference. A conference=20 > > > > might live for days, weeks or even months. Should a=20 > > > > conference policy, using CPCP, allow a privileged user to=20 > > > > de-activate a conference for a period of time within the=20 > > > > start and stop times of a conference? Examples are=20 > > > > administrator is performing some maintenance. > > > >=20 > > > > Regards, > > > > Hisham > > > >=20 > > > > _______________________________________________ > > > > XCON mailing list > > > > XCON@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/xcon > > > >=20 > > >=20 > >=20 > > _______________________________________________ > > XCON mailing list > > XCON@ietf.org > > https://www1.ietf.org/mailman/listinfo/xcon > >=20 >=20 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Fri Dec 19 14:29:32 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21183 for ; Fri, 19 Dec 2003 14:29:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXQJ6-00086g-4N for xcon-archive@odin.ietf.org; Fri, 19 Dec 2003 14:29:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBJJT4VU031158 for xcon-archive@odin.ietf.org; Fri, 19 Dec 2003 14:29:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXQJ5-00086T-Vw for xcon-web-archive@optimus.ietf.org; Fri, 19 Dec 2003 14:29:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21152 for ; Fri, 19 Dec 2003 14:29:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AXQJ3-0005SN-00 for xcon-web-archive@ietf.org; Fri, 19 Dec 2003 14:29:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AXQJ2-0005SF-00 for xcon-web-archive@ietf.org; Fri, 19 Dec 2003 14:29:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AXQJ2-0005SC-00 for xcon-web-archive@ietf.org; Fri, 19 Dec 2003 14:29:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXQJ3-00085w-Ft; Fri, 19 Dec 2003 14:29:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXQI5-000858-7t for xcon@optimus.ietf.org; Fri, 19 Dec 2003 14:28:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21025 for ; Fri, 19 Dec 2003 14:27:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AXQHz-0005Qd-00 for xcon@ietf.org; Fri, 19 Dec 2003 14:27:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AXQHy-0005QV-00 for xcon@ietf.org; Fri, 19 Dec 2003 14:27:55 -0500 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 1AXQHx-0005Q0-00 for xcon@ietf.org; Fri, 19 Dec 2003 14:27:54 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA10781; Fri, 19 Dec 2003 14:16:10 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA18615; Fri, 19 Dec 2003 14:15:12 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Fri, 19 Dec 2003 14:15:12 -0500 Message-ID: <313680C9A886D511A06000204840E1CF070B6229@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Drage, Keith (Keith)'" Cc: "'hisham.khartabil@nokia.com'" , xcon@ietf.org Subject: RE: [XCON] CPCP Requirement: Conference and Host Info Date: Fri, 19 Dec 2003 14:15:10 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Don't you have to have an explicit list of these kinds of things, with clear definitions of what they mean, in order to have compatible implementations? Even if all you do is "look and feel", you have to be able to display them in the correct context, and thus you need clear and explicit definitions of the available options. The only "generic requirement" you could have would be a block of displayable text. That's not enough I think. Brian -----Original Message----- From: Drage, Keith (Keith) [mailto:drage@lucent.com] Sent: Friday, December 19, 2003 6:14 AM To: Rosen, Brian; 'hisham.khartabil@nokia.com'; xcon@ietf.org Subject: RE: [XCON] CPCP Requirement: Conference and Host Info Dont these all tend to be "look and feel" type attributes, where different vendors might want to offer different sets of information. Is to not possible just to compress these into generic requirements whereby the conference vendor MAY define a number of attributes for a conference, which CPCP has the ability to set, modify or delete for a particular conference - then put an e.g. list of things that this may cover. I dont see any reason for a MUST on any of these in particular, but I see no reason not to have any of them. regards Keith Keith Drage Lucent Technologies drage@lucent.com tel: +44 1793 776249 > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > Sent: 15 December 2003 14:20 > To: 'hisham.khartabil@nokia.com'; xcon@ietf.org > Subject: RE: [XCON] CPCP Requirement: Conference and Host Info > > > I think its simple to have these. If we were prioritizing, I'd > leave the last two off, but I don't see any reason to not > implement them. > > Brian > > > -----Original Message----- > > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > > Sent: Monday, December 15, 2003 7:57 AM > > To: xcon@ietf.org > > Subject: [XCON] CPCP Requirement: Conference and Host Info > > > > > > This is in reference to requirements REQ-B1 to REG-B6, and > > REG-B10 in > > http://www.ietf.org/internet-drafts/draft-ietf-xcon-cpcp-reqs-00.txt > > > > REQ-B1: It MUST be possible to set, modify and delete a > conference > > Subject. > > > > REQ-B2: It MUST be possible to set, modify and delete > > conference URI > > display name. > > > > REQ-B3: It MUST be possible to set, modify and delete conference > > creator information. > > > > REQ-B4: It MUST be possible to set, modify and delete > > conference URI > > link for more information. > > > > REQ-B5: It MUST be possible to set, modify and delete > > conference host > > contact information. > > > > REQ-B6: It MUST be possible to set, modify and delete short > > conference session description. > > > > REQ-B10: It SHOULD be possible to set, modify and delete > conference > > Keywords. (This may be useful e.g. for search engines). > > > > I think a conference subject and display name as well as > > conference session description are useful. Perhaps the > > conference session description can appear on a conference web > > sight. What about conference host and creator information? > > > > I would like opinions on what people deem necessary > > information. Of course, we can have all if needed. > > > > Regards, > > Hisham > > > > _______________________________________________ > > XCON mailing list > > XCON@ietf.org > > https://www1.ietf.org/mailman/listinfo/xcon > > > > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon > _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Mon Dec 22 02:20:38 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05659 for ; Mon, 22 Dec 2003 02:20:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYKMM-0004nB-F0 for xcon-archive@odin.ietf.org; Mon, 22 Dec 2003 02:20:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBM7KAL5018417 for xcon-archive@odin.ietf.org; Mon, 22 Dec 2003 02:20:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYKMJ-0004me-4K for xcon-web-archive@optimus.ietf.org; Mon, 22 Dec 2003 02:20:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05599 for ; Mon, 22 Dec 2003 02:20:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AYKMF-0000l8-00 for xcon-web-archive@ietf.org; Mon, 22 Dec 2003 02:20:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AYKMC-0000kd-00 for xcon-web-archive@ietf.org; Mon, 22 Dec 2003 02:20:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AYKMB-0000kT-00 for xcon-web-archive@ietf.org; Mon, 22 Dec 2003 02:20:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYKMD-0004lc-FW; Mon, 22 Dec 2003 02:20:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYKLY-0004kG-Cm for xcon@optimus.ietf.org; Mon, 22 Dec 2003 02:19:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05505 for ; Mon, 22 Dec 2003 02:19:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AYKLU-0000jA-00 for xcon@ietf.org; Mon, 22 Dec 2003 02:19:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AYKLT-0000j3-00 for xcon@ietf.org; Mon, 22 Dec 2003 02:19:16 -0500 Received: from 212.199.61.2.forward.012.net.il ([212.199.61.2] helo=accord-mail.israel.polycom.com) by ietf-mx with esmtp (Exim 4.12) id 1AYKLT-0000io-00 for xcon@ietf.org; Mon, 22 Dec 2003 02:19:15 -0500 Received: by accord-mail.israel.polycom.com with Internet Mail Service (5.5.2653.19) id ; Mon, 22 Dec 2003 09:18:44 +0200 Message-ID: From: "Even, Roni" To: "'Umesh.Chandra@nokia.com'" , xcon@ietf.org Subject: RE: [XCON] I-D ACTION:draft-ietf-xcon-conference-scenarios-00.txt Date: Mon, 22 Dec 2003 09:18:36 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Umesh, The video mixing scenarios describe typical video conferencing scenarios. An participants with the right privilege level may select the screen layout he wants to have. The selection may be for his own view or for the whole conference view. The availability of such functionality per participant or per conference is dependent on the mixer functionality. This functionality is not saying what is the content (whose video is mixed) but on the layout. Layout may be static during the conference or may be changed dynamically based on user selection (e.g. start with a single view and request a quad view later) or the layout can change automatically based on the number of participants in the conference. The selection of the layout is independent from the selection of which stream is seen in each sub-window Roni Even ************************************* Roni Even Polycom Israel Tel: +972-3-9251200 Cell: +972-55-481099 email:roni.even@polycom.co.il ******************************************* -----Original Message----- From: Umesh.Chandra@nokia.com [mailto:Umesh.Chandra@nokia.com] Sent: Thursday, December 18, 2003 11:06 PM To: xcon@ietf.org Subject: RE: [XCON] I-D ACTION:draft-ietf-xcon-conference-scenarios-00.txt Hello, In section 4.1 of the draft ( Video mixing scenarios ), it says " For video the user selects one of a set of pre-defined video presentations offered by the server". Does it mean that end user in the conference knows what all streams the server can offer? Does this pre-defined video list changes dynamically ?...For example Particpant A is getting video of particpant B, but decides to watch a mosaic of participant B and C, it should be able to do so...The server should be able to mix the streams of B and C and send one stream to A... Umesh -----Original Message----- From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On Behalf Of ext Internet-Drafts@ietf.org Sent: Thursday, December 18, 2003 2:29 PM Cc: xcon@ietf.org Subject: [XCON] I-D ACTION:draft-ietf-xcon-conference-scenarios-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Centralized Conferencing Working Group of the IETF. Title : Conferencing Scenarios Author(s) : R. Even Filename : draft-ietf-xcon-conference-scenarios-00.txt Pages : 15 Date : 2003-12-18 This document describes SIP conferencing scenarios. It will describe basic and advance conferencing scenarios. These conferencing scenarios will help with definition and evaluation of the requirements for SIP conferencing framework and the protocol associated with the framework. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-xcon-conference-scenarios-00. txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-xcon-conference-scenarios-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-xcon-conference-scenarios-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Mon Dec 22 10:14:33 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20445 for ; Mon, 22 Dec 2003 10:14:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYRkz-0004f9-42 for xcon-archive@odin.ietf.org; Mon, 22 Dec 2003 10:14:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBMFE5wn017919 for xcon-archive@odin.ietf.org; Mon, 22 Dec 2003 10:14:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYRky-0004ew-Tm for xcon-web-archive@optimus.ietf.org; Mon, 22 Dec 2003 10:14:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20374 for ; Mon, 22 Dec 2003 10:14:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AYRkw-0006BE-00 for xcon-web-archive@ietf.org; Mon, 22 Dec 2003 10:14:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AYRku-0006Ax-00 for xcon-web-archive@ietf.org; Mon, 22 Dec 2003 10:14:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AYRku-0006Au-00 for xcon-web-archive@ietf.org; Mon, 22 Dec 2003 10:14:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYRkv-0004dm-1c; Mon, 22 Dec 2003 10:14:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYRkZ-0004bN-OV for xcon@optimus.ietf.org; Mon, 22 Dec 2003 10:13:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20324 for ; Mon, 22 Dec 2003 10:13:36 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AYRkX-0006Am-00 for xcon@ietf.org; Mon, 22 Dec 2003 10:13:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AYRkW-0006Af-00 for xcon@ietf.org; Mon, 22 Dec 2003 10:13:37 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AYRkV-0006Ac-00 for xcon@ietf.org; Mon, 22 Dec 2003 10:13:36 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hBMFDY024278 for ; Mon, 22 Dec 2003 17:13:34 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 22 Dec 2003 17:13:33 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 22 Dec 2003 17:13:33 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 22 Dec 2003 17:13:33 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] CPCP Requirement: Conference and Host Info Date: Mon, 22 Dec 2003 17:13:32 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797555@esebe019.ntc.nokia.com> Thread-Topic: [XCON] CPCP Requirement: Conference and Host Info Thread-Index: AcPGZmQtZzVK/GEDSa+aF5V2GGDDUwCN7kqw To: , Cc: X-OriginalArrivalTime: 22 Dec 2003 15:13:33.0316 (UTC) FILETIME=[2A18C440:01C3C89E] Content-Transfer-Encoding: quoted-printable Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable I agree with Brian. /Hisham > -----Original Message----- > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On Behalf Of ext > Rosen, Brian > Sent: 19.December.2003 21:15 > To: 'Drage, Keith (Keith)' > Cc: Khartabil Hisham (NMP-MSW/Helsinki); xcon@ietf.org > Subject: RE: [XCON] CPCP Requirement: Conference and Host Info >=20 >=20 > Don't you have to have an explicit list of these kinds of things, > with clear definitions of what they mean, in order to have compatible > implementations? Even if all you do is "look and feel", you have to > be able to display them in the correct context, and thus you need > clear and explicit definitions of the available options. >=20 > The only "generic requirement" you could have would be a block of=20 > displayable text. That's not enough I think. >=20 > Brian >=20 > -----Original Message----- > From: Drage, Keith (Keith) [mailto:drage@lucent.com] > Sent: Friday, December 19, 2003 6:14 AM > To: Rosen, Brian; 'hisham.khartabil@nokia.com'; xcon@ietf.org > Subject: RE: [XCON] CPCP Requirement: Conference and Host Info >=20 >=20 > Dont these all tend to be "look and feel" type attributes,=20 > where different > vendors might want to offer different sets of information. >=20 > Is to not possible just to compress these into generic=20 > requirements whereby > the conference vendor MAY define a number of attributes for a=20 > conference, > which CPCP has the ability to set, modify or delete for a particular > conference - then put an e.g. list of things that this may=20 > cover. I dont see > any reason for a MUST on any of these in particular, but I=20 > see no reason not > to have any of them. >=20 > regards >=20 > Keith >=20 > Keith Drage > Lucent Technologies > drage@lucent.com > tel: +44 1793 776249 >=20 >=20 > > -----Original Message----- > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > Sent: 15 December 2003 14:20 > > To: 'hisham.khartabil@nokia.com'; xcon@ietf.org > > Subject: RE: [XCON] CPCP Requirement: Conference and Host Info > >=20 > >=20 > > I think its simple to have these. If we were prioritizing, I'd > > leave the last two off, but I don't see any reason to not > > implement them. > >=20 > > Brian > >=20 > > > -----Original Message----- > > > From: hisham.khartabil@nokia.com=20 > [mailto:hisham.khartabil@nokia.com] > > > Sent: Monday, December 15, 2003 7:57 AM > > > To: xcon@ietf.org > > > Subject: [XCON] CPCP Requirement: Conference and Host Info > > >=20 > > >=20 > > > This is in reference to requirements REQ-B1 to REG-B6, and=20 > > > REG-B10 in=20 > > >=20 > http://www.ietf.org/internet-drafts/draft-ietf-xcon-cpcp-reqs-00.txt > > >=20 > > > REQ-B1: It MUST be possible to set, modify and delete a=20 > > conference > > > Subject. > > >=20 > > > REQ-B2: It MUST be possible to set, modify and delete=20 > > > conference URI > > > display name. > > >=20 > > > REQ-B3: It MUST be possible to set, modify and delete=20 > conference > > > creator information. > > >=20 > > > REQ-B4: It MUST be possible to set, modify and delete=20 > > > conference URI > > > link for more information. > > >=20 > > > REQ-B5: It MUST be possible to set, modify and delete=20 > > > conference host > > > contact information. > > >=20 > > > REQ-B6: It MUST be possible to set, modify and delete short > > > conference session description. > > >=20 > > > REQ-B10: It SHOULD be possible to set, modify and delete=20 > > conference > > > Keywords. (This may be useful e.g. for search engines). > > >=20 > > > I think a conference subject and display name as well as=20 > > > conference session description are useful. Perhaps the=20 > > > conference session description can appear on a conference web=20 > > > sight. What about conference host and creator information? > > >=20 > > > I would like opinions on what people deem necessary=20 > > > information. Of course, we can have all if needed. > > >=20 > > > Regards, > > > Hisham > > >=20 > > > _______________________________________________ > > > XCON mailing list > > > XCON@ietf.org > > > https://www1.ietf.org/mailman/listinfo/xcon > > >=20 > >=20 > > _______________________________________________ > > XCON mailing list > > XCON@ietf.org > > https://www1.ietf.org/mailman/listinfo/xcon > >=20 >=20 > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon >=20 > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon >=20 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Mon Dec 22 18:55:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18303 for ; Mon, 22 Dec 2003 18:55:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYZt2-000703-65 for xcon-archive@odin.ietf.org; Mon, 22 Dec 2003 18:54:56 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBMNsuCt026901 for xcon-archive@odin.ietf.org; Mon, 22 Dec 2003 18:54:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYZt2-0006zo-1m for xcon-web-archive@optimus.ietf.org; Mon, 22 Dec 2003 18:54:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18184 for ; Mon, 22 Dec 2003 18:54:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AYZsy-0006ab-01 for xcon-web-archive@ietf.org; Mon, 22 Dec 2003 18:54:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AYZqC-0006Vm-00 for xcon-web-archive@ietf.org; Mon, 22 Dec 2003 18:52:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AYZqC-0006Vf-00 for xcon-web-archive@ietf.org; Mon, 22 Dec 2003 18:52:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYZqD-0006wg-SJ; Mon, 22 Dec 2003 18:52:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYZpu-0006w8-5r for xcon@optimus.ietf.org; Mon, 22 Dec 2003 18:51:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18085 for ; Mon, 22 Dec 2003 18:51:37 -0500 (EST) From: Umesh.Chandra@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AYZpq-0006Qd-00 for xcon@ietf.org; Mon, 22 Dec 2003 18:51:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AYZeu-00069M-00 for xcon@ietf.org; Mon, 22 Dec 2003 18:40:21 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AYZeu-000697-00 for xcon@ietf.org; Mon, 22 Dec 2003 18:40:20 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hBMNdsU22580 for ; Tue, 23 Dec 2003 01:39:54 +0200 (EET) Received: from daebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 23 Dec 2003 01:39:54 +0200 Received: from daebe010.NOE.Nokia.com ([10.241.35.110]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 22 Dec 2003 17:39:52 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] I-D ACTION:draft-ietf-xcon-conference-scenarios-00.txt Date: Mon, 22 Dec 2003 17:39:52 -0600 Message-ID: <9DF4601B5A454946B4D6F1D3AF70A5881E41DE@daebe010.americas.nokia.com> Thread-Topic: [XCON] I-D ACTION:draft-ietf-xcon-conference-scenarios-00.txt Thread-Index: AcPIXACBxebkxlOkT3mGWsFd9jfiNwAhjNtw To: , X-OriginalArrivalTime: 22 Dec 2003 23:39:52.0591 (UTC) FILETIME=[E58E41F0:01C3C8E4] Content-Transfer-Encoding: quoted-printable Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hello Roni, Thanks for your input..So basically the user can decide the contents of = the screen layout, but the screen layout can be static or can be changed = dynamically based on user selection. In nutshell can the end user say i = want to see user A, B, C in mosaic ( assuming the conferencing server = supports this kind of layout) to the conferencing server?. Each user can = send its own request for content and for layout. In that case the mixer = has to support the functionality to select the desired layout and select = the particular streams the end user is asking for. And in case the conferencing server doesnt support this kind of layout, = what is the protocol to inform the client..I dont know if this would = fall under media control policy..=20 BR=20 Umesh -----Original Message----- From: ext Even, Roni [mailto:roni.even@polycom.co.il] Sent: Monday, December 22, 2003 1:19 AM To: Chandra Umesh (NRC/Dallas); xcon@ietf.org Subject: RE: [XCON] I-D ACTION:draft-ietf-xcon-conference-scenarios-00.txt Umesh, The video mixing scenarios describe typical video conferencing = scenarios. An participants with the right privilege level may select the screen layout = he wants to have. The selection may be for his own view or for the whole conference view. The availability of such functionality per participant = or per conference is dependent on the mixer functionality. This = functionality is not saying what is the content (whose video is mixed) but on the = layout. Layout may be static during the conference or may be changed dynamically based on user selection (e.g. start with a single view and request a = quad view later) or the layout can change automatically based on the number = of participants in the conference. The selection of the layout is independent from the selection of which stream is seen in each sub-window Roni Even =20 ************************************* Roni Even Polycom Israel Tel: +972-3-9251200 Cell: +972-55-481099 email:roni.even@polycom.co.il ******************************************* -----Original Message----- From: Umesh.Chandra@nokia.com [mailto:Umesh.Chandra@nokia.com] Sent: Thursday, December 18, 2003 11:06 PM To: xcon@ietf.org Subject: RE: [XCON] I-D = ACTION:draft-ietf-xcon-conference-scenarios-00.txt Hello, In section 4.1 of the draft ( Video mixing scenarios ), it says " For = video the user selects one of a set of pre-defined video presentations offered = by the server". Does it mean that end user in the conference knows what all streams the server can offer? Does this pre-defined video list changes dynamically ?...For example Particpant A is getting video of particpant = B, but decides to watch a mosaic of participant B and C, it should be able = to do so...The server should be able to mix the streams of B and C and send = one stream to A... Umesh -----Original Message----- From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On Behalf Of ext Internet-Drafts@ietf.org Sent: Thursday, December 18, 2003 2:29 PM Cc: xcon@ietf.org Subject: [XCON] I-D ACTION:draft-ietf-xcon-conference-scenarios-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Centralized Conferencing Working Group = of the IETF. Title : Conferencing Scenarios Author(s) : R. Even Filename : draft-ietf-xcon-conference-scenarios-00.txt Pages : 15 Date : 2003-12-18 =09 This document describes SIP conferencing scenarios. It will describe basic and advance conferencing scenarios. These conferencing scenarios will help with definition and evaluation of the requirements for SIP conferencing framework and the protocol associated with the framework. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-xcon-conference-scenarios-= 00. txt To remove yourself from the IETF Announcement list, send a message to=20 ietf-announce-request with the word unsubscribe in the body of the = message. Internet-Drafts are also available by anonymous FTP. Login with the = username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-xcon-conference-scenarios-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-xcon-conference-scenarios-00.txt". =09 NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. =09 =09 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Tue Dec 23 01:48:26 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27550 for ; Tue, 23 Dec 2003 01:48:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYgKk-0000y5-6K for xcon-archive@odin.ietf.org; Tue, 23 Dec 2003 01:47:58 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBN6lw9W003718 for xcon-archive@odin.ietf.org; Tue, 23 Dec 2003 01:47:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYgKk-0000xt-0R for xcon-web-archive@optimus.ietf.org; Tue, 23 Dec 2003 01:47:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27527 for ; Tue, 23 Dec 2003 01:47:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AYgKf-00022D-00 for xcon-web-archive@ietf.org; Tue, 23 Dec 2003 01:47:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AYgC2-00020V-00 for xcon-web-archive@ietf.org; Tue, 23 Dec 2003 01:38:59 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AYgC2-00020S-00 for xcon-web-archive@ietf.org; Tue, 23 Dec 2003 01:38:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYgC4-0000qO-Nm; Tue, 23 Dec 2003 01:39:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYgBu-0000pb-LZ for xcon@optimus.ietf.org; Tue, 23 Dec 2003 01:38:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27372 for ; Tue, 23 Dec 2003 01:38:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AYgBr-0001yt-00 for xcon@ietf.org; Tue, 23 Dec 2003 01:38:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AYg96-0001y9-00 for xcon@ietf.org; Tue, 23 Dec 2003 01:35:57 -0500 Received: from 212.199.61.2.forward.012.net.il ([212.199.61.2] helo=accord-mail.israel.polycom.com) by ietf-mx with esmtp (Exim 4.12) id 1AYg96-0001xa-00 for xcon@ietf.org; Tue, 23 Dec 2003 01:35:56 -0500 Received: by accord-mail.israel.polycom.com with Internet Mail Service (5.5.2653.19) id ; Tue, 23 Dec 2003 08:35:25 +0200 Message-ID: From: "Even, Roni" To: "'Umesh.Chandra@nokia.com'" , "Even, Roni" , xcon@ietf.org Subject: RE: [XCON] I-D ACTION:draft-ietf-xcon-conference-scenarios-00.txt Date: Tue, 23 Dec 2003 08:35:16 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Hi, The participant will need to select first the layout ( 3 sub windows in your example) and then select who will be seen in the windows by defining the mix. The media policy control protocol should allow this. Roni Even ************************************* Roni Even VP Product Planning Polycom Israel Tel: +972-3-9251200 Cell: +972-55-481099 email:roni.even@polycom.co.il ******************************************* -----Original Message----- From: Umesh.Chandra@nokia.com [mailto:Umesh.Chandra@nokia.com] Sent: Tuesday, December 23, 2003 1:40 AM To: roni.even@polycom.co.il; xcon@ietf.org Subject: RE: [XCON] I-D ACTION:draft-ietf-xcon-conference-scenarios-00.txt Hello Roni, Thanks for your input..So basically the user can decide the contents of the screen layout, but the screen layout can be static or can be changed dynamically based on user selection. In nutshell can the end user say i want to see user A, B, C in mosaic ( assuming the conferencing server supports this kind of layout) to the conferencing server?. Each user can send its own request for content and for layout. In that case the mixer has to support the functionality to select the desired layout and select the particular streams the end user is asking for. And in case the conferencing server doesnt support this kind of layout, what is the protocol to inform the client..I dont know if this would fall under media control policy.. BR Umesh -----Original Message----- From: ext Even, Roni [mailto:roni.even@polycom.co.il] Sent: Monday, December 22, 2003 1:19 AM To: Chandra Umesh (NRC/Dallas); xcon@ietf.org Subject: RE: [XCON] I-D ACTION:draft-ietf-xcon-conference-scenarios-00.txt Umesh, The video mixing scenarios describe typical video conferencing scenarios. An participants with the right privilege level may select the screen layout he wants to have. The selection may be for his own view or for the whole conference view. The availability of such functionality per participant or per conference is dependent on the mixer functionality. This functionality is not saying what is the content (whose video is mixed) but on the layout. Layout may be static during the conference or may be changed dynamically based on user selection (e.g. start with a single view and request a quad view later) or the layout can change automatically based on the number of participants in the conference. The selection of the layout is independent from the selection of which stream is seen in each sub-window Roni Even ************************************* Roni Even Polycom Israel Tel: +972-3-9251200 Cell: +972-55-481099 email:roni.even@polycom.co.il ******************************************* -----Original Message----- From: Umesh.Chandra@nokia.com [mailto:Umesh.Chandra@nokia.com] Sent: Thursday, December 18, 2003 11:06 PM To: xcon@ietf.org Subject: RE: [XCON] I-D ACTION:draft-ietf-xcon-conference-scenarios-00.txt Hello, In section 4.1 of the draft ( Video mixing scenarios ), it says " For video the user selects one of a set of pre-defined video presentations offered by the server". Does it mean that end user in the conference knows what all streams the server can offer? Does this pre-defined video list changes dynamically ?...For example Particpant A is getting video of particpant B, but decides to watch a mosaic of participant B and C, it should be able to do so...The server should be able to mix the streams of B and C and send one stream to A... Umesh -----Original Message----- From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On Behalf Of ext Internet-Drafts@ietf.org Sent: Thursday, December 18, 2003 2:29 PM Cc: xcon@ietf.org Subject: [XCON] I-D ACTION:draft-ietf-xcon-conference-scenarios-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Centralized Conferencing Working Group of the IETF. Title : Conferencing Scenarios Author(s) : R. Even Filename : draft-ietf-xcon-conference-scenarios-00.txt Pages : 15 Date : 2003-12-18 This document describes SIP conferencing scenarios. It will describe basic and advance conferencing scenarios. These conferencing scenarios will help with definition and evaluation of the requirements for SIP conferencing framework and the protocol associated with the framework. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-xcon-conference-scenarios-00. txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-xcon-conference-scenarios-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-xcon-conference-scenarios-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Tue Dec 23 06:03:32 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15698 for ; Tue, 23 Dec 2003 06:03:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYkJe-00029t-CG for xcon-archive@odin.ietf.org; Tue, 23 Dec 2003 06:03:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBNB36Jh008297 for xcon-archive@odin.ietf.org; Tue, 23 Dec 2003 06:03:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYkJe-00029k-6J for xcon-web-archive@optimus.ietf.org; Tue, 23 Dec 2003 06:03:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15672 for ; Tue, 23 Dec 2003 06:03:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AYkJa-0000Mf-01 for xcon-web-archive@ietf.org; Tue, 23 Dec 2003 06:03:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AYkJX-0000MG-00 for xcon-web-archive@ietf.org; Tue, 23 Dec 2003 06:03:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AYkJX-0000MB-00 for xcon-web-archive@ietf.org; Tue, 23 Dec 2003 06:02:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYkJY-00028V-SF; Tue, 23 Dec 2003 06:03:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYkJT-00027k-01 for xcon@optimus.ietf.org; Tue, 23 Dec 2003 06:02:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15609 for ; Tue, 23 Dec 2003 06:02:50 -0500 (EST) From: Jari.Mutikainen@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AYkJO-0000JF-00 for xcon@ietf.org; Tue, 23 Dec 2003 06:02:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AYkHP-0000Hm-00 for xcon@ietf.org; Tue, 23 Dec 2003 06:00:48 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AYkHP-0000Hj-00 for xcon@ietf.org; Tue, 23 Dec 2003 06:00:47 -0500 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hBNB0l014984 for ; Tue, 23 Dec 2003 13:00:47 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 23 Dec 2003 13:00:47 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 23 Dec 2003 13:00:46 +0200 Received: from esebe001.NOE.Nokia.com ([172.21.138.30]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 23 Dec 2003 13:00:46 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] CPCP Requirement: Conference package subscribers Date: Tue, 23 Dec 2003 13:00:43 +0200 Message-ID: <05DAF85DFD6A9940B7C90667D4624F0D012E58D7@esebe001> Thread-Topic: [XCON] CPCP Requirement: Conference package subscribers Thread-Index: AcPGIU+Pv/Rsop2KRCKTYQqxbOy+eQDIkxSw To: , , X-OriginalArrivalTime: 23 Dec 2003 11:00:46.0654 (UTC) FILETIME=[04798DE0:01C3C944] Content-Transfer-Encoding: quoted-printable Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ext Drage, Keith (Keith) [mailto:drage@lucent.com] > Sent: 19 December, 2003 13:14 > To: Mutikainen Jari (NMP-MSW/Helsinki); Khartabil Hisham > (NMP-MSW/Helsinki); xcon@ietf.org > Subject: RE: [XCON] CPCP Requirement: Conference package subscribers >=20 >=20 > See below >=20 > > -----Original Message----- > > From: Jari.Mutikainen@nokia.com [mailto:Jari.Mutikainen@nokia.com] > > Sent: 15 December 2003 14:14 > > To: hisham.khartabil@nokia.com; xcon@ietf.org > > Subject: RE: [XCON] CPCP Requirement: Conference package subscribers > >=20 > heavily snipped > >=20 > > >=20 > > > 1. Use your TEL URI in the SUBSCRIBE. Why would you use your=20 > > > SIP URI? You certainly don't have to. > >=20 > > At least in IMS this is impossible. I cannot take my grand=20 > > ma's PSTN phone, write down it's E.164 number, and register=20 > > from my SIP client using this E.164 number. In my=20 > > understanding the IMS provider allows registration only from=20 > > tel URIs it has allocated to me. > >=20 > This comes as part of release 6 for IMS. The it is possible=20 > to associate the same public user identity with two private=20 > user identities. and therefore register the same public user=20 > identity from two different devices (they must however have=20 > the appropriate USIM or ISIM application to hold the private=20 > user identity etc). >=20 > regards >=20 > Keith Yes, I agree, but the requirement was to be able to join to the = conference from any POTS terminal, while subscribing and managing the = conference status from IMS SIP device. BR, Jari =20 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Wed Dec 24 07:44:28 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07449 for ; Wed, 24 Dec 2003 07:44:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AZ8Mo-0001b7-Ud for xcon-archive@odin.ietf.org; Wed, 24 Dec 2003 07:43:59 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBOChwsH006138 for xcon-archive@odin.ietf.org; Wed, 24 Dec 2003 07:43:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AZ8Mo-0001aq-KP for xcon-web-archive@optimus.ietf.org; Wed, 24 Dec 2003 07:43:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07417 for ; Wed, 24 Dec 2003 07:43:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AZ8Mn-00006N-00 for xcon-web-archive@ietf.org; Wed, 24 Dec 2003 07:43:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AZ8J7-0007L7-00 for xcon-web-archive@ietf.org; Wed, 24 Dec 2003 07:40:10 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AZ8HR-0007Ht-01 for xcon-web-archive@ietf.org; Wed, 24 Dec 2003 07:38:25 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1AZ8FA-0005P4-TJ for xcon-web-archive@ietf.org; Wed, 24 Dec 2003 07:36:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AZ8F7-0001D0-QZ; Wed, 24 Dec 2003 07:36:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AZ8Ew-0001CG-RV for xcon@optimus.ietf.org; Wed, 24 Dec 2003 07:35:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07320 for ; Wed, 24 Dec 2003 07:35:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AZ8Ew-0007GQ-00 for xcon@ietf.org; Wed, 24 Dec 2003 07:35:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AZ8Cz-0007Eg-00 for xcon@ietf.org; Wed, 24 Dec 2003 07:33:50 -0500 Received: from auemail1.lucent.com ([192.11.223.161] helo=auemail1.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1AZ8BH-0007Aa-00 for xcon@ietf.org; Wed, 24 Dec 2003 07:32:03 -0500 Received: from uk0006exch001h.wins.lucent.com (h135-86-145-57.lucent.com [135.86.145.57]) by auemail1.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id hBOCVTc26761 for ; Wed, 24 Dec 2003 06:31:30 -0600 (CST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Wed, 24 Dec 2003 12:31:28 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB00439EF80@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "'hisham.khartabil@nokia.com'" , xcon@ietf.org Subject: RE: [XCON] CPCP Requirement: de-activating a conference Date: Wed, 24 Dec 2003 12:31:27 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 So I think you are basically telling me it is the same state. I would therefore suggest combining all the requirements in this area into a single requirement - something along the lines of: START PROPOSAL The conference administrator can set start and stop times for a conference, or may start and stop the conference on-demand. A conference that is stopped on-demand does not have a programmed stop time removed, and thus if the conference is restarted, that programmed stop time will apply. Start and stop times can be specific (i.e. for a single conference event) or recurring such that the conference occurs e.g. daily, weekly, monthly. Recurring conferences can have the frequency set using an appropriate set of time intervals. END PROPOSAL The way this is worded would also allow a conference that is programmed to start later to be started early. This would seem to me to be useful, and the only reason to preclude it would be lack of resources, which could be determined and rejected at the time of making of the request. Of course if the conference has been started early, and then stopped before the start time, it will restart at the programmed start time. I agree that we can exclude multiple start and stop times (except for the recurring conferences outlined above). If this is a necessity for any user, then it would seem simple enough to programme up multiple conferences, each with their own start and stop times. Maybe we can have a note expressing this in the requirements. Are we placing any CPCP restrictions on conferences that have already started? I currently see none in the requirements documents so assume that we can add, remove and modify CPCP data when the conference is in progress. regards Keith Keith Drage Lucent Technologies drage@lucent.com tel: +44 1793 776249 > -----Original Message----- > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > Sent: 19 December 2003 15:10 > To: drage@lucent.com; Brian.Rosen@marconi.com; xcon@ietf.org > Subject: RE: [XCON] CPCP Requirement: de-activating a conference > > > Your question is slightly different that Brian's. Here is a > copy paste from what I replied to Brian: > > ------------------ > A long lived conference is one that runs for months (chat > sessions on the internet seem to run for that long). They are > not repeated, but instead are constantly running. > > An administrator, for maintenance reasons, might want to > de-activate a conference for a short period of time. > ------------------------------ > > In this case, there is no difference in meaning when you say > "stopping" or "deactivating" the conference. But since you > are stopping the conference for a short period of time then > restarting it again, and you do not want to affect the > overall start and stop time of the conference, then you are > really just making the conference inactive. Maybe inactive in > the wrong word here. Maybe suspend is a better word. You are > suspending the conference. > > The other scenario is that the conference does not have to be > running yet. Someone might schedule a conference starting > Monday next week and stop 3 months from Monday. Moments > later, the administrator decides that in 2 weekends time, he > will suspend all running conferences. The administrator can > immediately schedule such event before the meeting starts on Monday. > > Brian was asking what the difference is between de-activating > a conference and conference repeats. I guess you can think of > as such, but it is not the same thing. Certainly the solution > can incorporate both, but the 2 need to be recognised a > separate requirements. > > I hope what I state above answers his question (and your for > that matter :) > > Regards, > Hisham > > > -----Original Message----- > > From: ext Drage, Keith (Keith) [mailto:drage@lucent.com] > > Sent: 19.December.2003 16:43 > > To: Khartabil Hisham (NMP-MSW/Helsinki); Drage, Keith (Keith); > > Brian.Rosen@marconi.com; xcon@ietf.org > > Subject: RE: [XCON] CPCP Requirement: de-activating a conference > > > > > > At the moment I was not trying to propose words, I was merely > > trying to see how your inactive state was different from the > > conference having been stopped. > > > > So far you have been asked that question twice, once by me, > > and once by someone else, and you have gone into statements > > about side effects, but you have never actually answered > the question. > > > > So, is it a different state, or not? > > > > Once we understand that, then we can look at the words. > > > > regards > > > > Keith > > > > Keith Drage > > Lucent Technologies > > drage@lucent.com > > tel: +44 1793 776249 > > > > > > > -----Original Message----- > > > From: hisham.khartabil@nokia.com > [mailto:hisham.khartabil@nokia.com] > > > Sent: 19 December 2003 14:01 > > > To: drage@lucent.com; Brian.Rosen@marconi.com; xcon@ietf.org > > > Subject: RE: [XCON] CPCP Requirement: de-activating a conference > > > > > > > > > You are getting into the solution already, so I take it that > > > you agree that such a requirement is needed. > > > > > > Having multiple start and stop times has the side effect that > > > a conference policy will forever grow. In the solution we > > > propose using XCAP, we have start-time, stop-time, and repeat > > > intervals. Having multiple start and stop times where there > > > is a repeat interval will cause unnecessary complexity. > > > > > > To accommodate setting a long lived conference inactive to a > > > short period of time, we have defined an inactive start and > > > stop times. > > > > > > I guess we can defer the argument about what the solution > > > should look like until we agree on the requirement. > > > > > > Regards, > > > Hisham > > > > > > > -----Original Message----- > > > > From: ext Drage, Keith (Keith) [mailto:drage@lucent.com] > > > > Sent: 19.December.2003 13:14 > > > > To: Khartabil Hisham (NMP-MSW/Helsinki); > Brian.Rosen@marconi.com; > > > > xcon@ietf.org > > > > Subject: RE: [XCON] CPCP Requirement: de-activating a conference > > > > > > > > > > > > You seem to be ending defining an inactivated conference due > > > > to a lack of flexbility over start and stop times. What is to > > > > stop you having multiple start and stop times that are > > > > completely independent of regular scheduling? > > > > > > > > If the conference them has a stop specified sometime in the > > > > middle, and a subsequent restart, how is that different from > > > > an inactivated conference? > > > > > > > > regards > > > > > > > > KeithKeith Drage > > > > Lucent Technologies > > > > drage@lucent.com > > > > tel: +44 1793 776249 > > > > > > > > > > > > > -----Original Message----- > > > > > From: hisham.khartabil@nokia.com > > > [mailto:hisham.khartabil@nokia.com] > > > > > Sent: 15 December 2003 15:21 > > > > > To: Brian.Rosen@marconi.com; xcon@ietf.org > > > > > Subject: RE: [XCON] CPCP Requirement: de-activating a > conference > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: ext Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > > > > > Sent: 15.December.2003 16:25 > > > > > > To: Khartabil Hisham (NMP-MSW/Helsinki); xcon@ietf.org > > > > > > Subject: RE: [XCON] CPCP Requirement: de-activating a > > conference > > > > > > > > > > > > > > > > > > Again, I'm worried about "privileged users". I > think we need > > > > > > to finish > > > > > > some discussions we started a while ago that > essentially are > > > > > > semantics. > > > > > > > > > > We can assume it is the moderator for now. > > > > > > > > > > > What is an "inactivated" conference, and how does it > > > differ from a > > > > > > conference that can be re-instantiated (a weekly meeting > > > > > for example)? > > > > > > > > > > > > > > > A long lived conference is one that runs for months (chat > > > > > sessions on the internet seem to run for that long). They are > > > > > not repeated, but instead are constantly running. > > > > > > > > > > An administrator, for maintenance reasons, might want to > > > > > de-activate a conference for a short period of time. > > > > > > > > > > Of course the administrator can kick everyone out by sending > > > > > them BYE requests and redefining the conference start time. > > > > > But it has the disadvantage that the inactivity time for > > > > > maintenance cannot be scheduled. Do we want to be able to > > > > > schedule such event for long lived conferences? > > > > > > > > > > Regards, > > > > > Hisham > > > > > > > > > > > > > > > > > Brian > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: hisham.khartabil@nokia.com > > > > [mailto:hisham.khartabil@nokia.com] > > > > > > Sent: Monday, December 15, 2003 7:57 AM > > > > > > To: xcon@ietf.org > > > > > > Subject: [XCON] CPCP Requirement: de-activating a conference > > > > > > > > > > > > > > > > > > This is in reference to requirement REQ-B9 in > > > > > > > > > > > http://www.ietf.org/internet-drafts/draft-ietf-xcon-cpcp-reqs-00.txt > > > > > > > > > > REQ-B9: It MUST be possible to inactive a conference > > > for defined > > > > > period of time. > > > > > > > > > > There are start and stop times for a conference. A conference > > > > > might live for days, weeks or even months. Should a > > > > > conference policy, using CPCP, allow a privileged user to > > > > > de-activate a conference for a period of time within the > > > > > start and stop times of a conference? Examples are > > > > > administrator is performing some maintenance. > > > > > > > > > > Regards, > > > > > Hisham > > > > > > > > > > _______________________________________________ > > > > > XCON mailing list > > > > > XCON@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/xcon > > > > > > > > > > > > > > > _______________________________________________ > > > XCON mailing list > > > XCON@ietf.org > > > https://www1.ietf.org/mailman/listinfo/xcon > > > > > > _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon