Re: [XCON] CPCP Requirement: Repeat times
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [XCON] CPCP Requirement: Repeat times
Start time I can understand but it is seems more complex that you are making
it sound. Is it the time the focus URL becomes valid? Is it the time that if
before this you tired to connect you would get rejected? Is it the time that
mixing of the media starts? is it the time that normal participants gets
dialed on a dial out? Is it the time the moderator get dialed?
Theses are all separate times and reducing them to a single "start time"
won't work.
Stop time is even worse. Is it when the the human who set this up expects it
to end? Is the absolute max time after which all session will be torn down?
Is the time that resources are reserved for? (I hope not) I think someone
needs to say what stop time is before we decide if it is CPCP or not.
I'm assuming that people are thinking that all times will be in GMT or
relative offsets from some GMT time. If folks see a need for local times,
lets get that discussion going.
I have a long rant why I hate Repeat times but sounds like I don't need to
send that :-)
On 1/30/04 11:02 AM, "Nermeen Ismail" <nismail@cisco.com> wrote:
> At 10:48 AM 1/29/2004 -0500, Rosen, Brian wrote:
>> Do we all agree that the start time can be in the future, and that
>> constitutes a (simple) reservation?
>>
>> I am also okay with no repeats.
>>
>> Brian
>
> If start time can not be in the future then there is no reason for it. I am
> OK with having a start time.
>
> nermeen
>
>
>
>>> -----Original Message-----
>>> From: Eric Burger [mailto:eburger@snowshore.com]
>>> Sent: Thursday, January 29, 2004 10:42 AM
>>> To: hisham.khartabil@nokia.com; xcon@ietf.org
>>> Subject: RE: [XCON] CPCP Requirement: Repeat times
>>>
>>>
>>> Exactly. The idea "we'll start small and extend later" on
>>> the reservation / scheduling function is how we will end up
>>> re-inventing iCal, only this time with people with less
>>> expertise in the area...
>>>
>>> I think all we need is start time & end time. Period.
>>>
>>>> -----Original Message-----
>>>> From: Boyer, David G (Dave) [mailto:dgboyer@avaya.com]
>>>> Sent: Wednesday, January 28, 2004 9:39 AM
>>>> To: hisham.khartabil@nokia.com; Eric Burger; xcon@ietf.org
>>>> Cc: roni.even@polycom.co.il
>>>> Subject: RE: [XCON] CPCP Requirement: Repeat times
>>>>
>>>>
>>>> If a conference focus is created at conference start time by
>>>> a conference factory, the focus will only need to know it's
>>>> end time in order to prevent any users from joining.
>>>> Repeat times and more complex reservations can be handled by
>>>> an "external" reservation
>>>> application.
>>>>
>>>> Dave Boyer
>>>> -----Original Message-----
>>>> From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On Behalf Of
>>>> hisham.khartabil@nokia.com
>>>> Sent: Wednesday, January 28, 2004 6:50 AM
>>>> To: eburger@snowshore.com; xcon@ietf.org
>>>> Cc: roni.even@polycom.co.il
>>>> Subject: RE: [XCON] CPCP Requirement: Repeat times
>>>>
>>>>
>>>> Let me elaborate a little on this proposal.
>>>>
>>>> I agree that eventually we need complex scheduling for
>>>> conferences. We can pick this up after we finalise a solution
>>>> for CPCP. In can be decided at that point if this scheduling
>>>> could be done inside CPCP as an extension (similar approach
>>>> to CPL) or is a separate protocol.
>>>>
>>>> In the mean time, we can define a very simple start, stop and
>>>> repeat times that is OPTIONAL TO IMPLEMENT at the client
>>>> side. The purpose of those would not be to indicate the need
>>>> for resource reservation, although they can be used for that.
>>>>
>>>> Start time indicates to the focus when it should start
>>>> allowing users to join or when it should invite users to join.
>>>> Stop time indicates to the focus when it should stop allowing
>>>> users to join. It also indicates that the focus should not
>>>> invite users that have been added to dial-out list.
>>>> Repeat times is obvious.
>>>>
>>>> Again, this would be optional and can be deprecated by a more
>>>> complex scheduling solution.
>>>>
>>>> Regards,
>>>> Hisham
>>>>
>>>>> -----Original Message-----
>>>>> From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On
>>>> Behalf Of ext
>>>>> hisham.khartabil@nokia.com
>>>>> Sent: 28.January.2004 09:30
>>>>> To: eburger@snowshore.com; xcon@ietf.org
>>>>> Cc: roni.even@polycom.co.il
>>>>> Subject: RE: [XCON] CPCP Requirement: Repeat times
>>>>>
>>>>>
>>>>> I'm sorry, but I don't buy the argument that just because
>>>>> scheduling is complex it requires a separate protocol.
>>>>> Henning did mention how they approached the problem for CPL.
>>>>> We can adopt that here also.
>>>>>
>>>>> If we don't want a full scheduling solution yet, then we
>>>>> start with something basic and design the protocol in a way
>>>>> that allows complex scheduling to be added later.
>>>>>
>>>>> /Hisham
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On
>>>>> Behalf Of ext
>>>>>> Eric Burger
>>>>>> Sent: 26.January.2004 21:23
>>>>>> To: xcon@ietf.org
>>>>>> Cc: Even, Roni
>>>>>> Subject: RE: [XCON] CPCP Requirement: Repeat times
>>>>>>
>>>>>>
>>>>>> I started to say that it was totally out of scope. Here are
>>>>>> both sides of the coin:
>>>>>>
>>>>>> AGAINST *ANY* SCHEDULING IN CPCP:
>>>>>> Scheduling logic is arbitrarily complex. Scheduling
>>>>>> semantics are arbitrarily complex, and have been tackled in
>>>>>> other venues much better than we every will (e.g., iCal).
>>>>>> What more does CPCP need other than "Create conference NOW"
>>>>>> and "Remove conference NOW"?
>>>>>>
>>>>>> FOR *SOME* SCHEDULING IN CPCP:
>>>>>> Resource management should be at the focus, not at the
>>>>>> application. This would lead to "Reserve resources for a
>>>>>> conference starting LATER" (could succeed or fail).
>>>>>>
>>>>>> I *might* understand "Reserve resources for a conference that
>>>>>> repeats every {time unit}".
>>>>>>
>>>>>> I would NOT approve "Reserve resources for a conference that
>>>>>> repeats every week except for the week after next." Limit
>>>>>> ourselves to "Reserve resources for a conference this week
>>>>>> and next. + Reserve resources for a conference starting
>>>>>> three weeks from now."
>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Even, Roni [mailto:roni.even@polycom.co.il]
>>>>>>> Sent: Sunday, January 25, 2004 8:44 AM
>>>>>>> To: 'petri.koskelainen@nokia.com'; xcon@ietf.org
>>>>>>> Subject: RE: [XCON] CPCP Requirement: Repeat times
>>>>>>>
>>>>>>>
>>>>>>> Hi,
>>>>>>> Repeating myself I would like to state my objection, and I
>>>>>>> would suggest to
>>>>>>> have conference reservation functionality not in the scope of
>>>>>>> conference
>>>>>>> policy but maybe as an application functionality that we may
>>>>>>> consider as a
>>>>>>> different working item.
>>>>>>> Roni
>>>>>>>
>>>>>>> *************************************
>>>>>>> Roni Even
>>>>>>>
>>>>>>> Polycom Israel
>>>>>>>
>>>>>>> Tel: +972-3-9251200
>>>>>>> Cell: +972-55-481099
>>>>>>> email:roni.even@polycom.co.il
>>>>>>> *******************************************
>>>>>>>
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: petri.koskelainen@nokia.com
>>>>>> [mailto:petri.koskelainen@nokia.com]
>>>>>>> Sent: Sunday, January 25, 2004 3:31 PM
>>>>>>> To: xcon@ietf.org
>>>>>>> Subject: RE: [XCON] CPCP Requirement: Repeat times
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Back to the original question in this thread:
>>>>>>>
>>>>>>>>>>>> Do we see a need for such capability using CPCP?
>>>>>>>>>>>> If so, then we need to add a requirement.
>>>>>>>
>>>>>>> I guess we can close this open issue now as rough consensus
>>>>>> seems to
>>>>>>> be that such a requirement is needed (at least for the
>>>>>>> start/stop/repeat
>>>>>>> times).
>>>>>>> Note that we don't have to design the actual solution yet
>>>>>>> (e.g. using iCal vs defining own format).
>>>>>>>
>>>>>>> --
>>>>>>> Petri
>>>>>>>
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: ext Rosen, Brian [mailto:Brian.Rosen@marconi.com]
>>>>>>>>> Sent: 21.January.2004 16:09
>>>>>>>>> To: Khartabil Hisham (Nokia-TP/Helsinki)
>>>>>>>>> Subject: RE: [XCON] CPCP Requirement: Repeat times
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I think we need to figure out where we are going on
>>>>> scheduling.
>>>>>>>>>
>>>>>>>>> First, let me say that I think we SHOULD allow CPCP to at
>>>>>>>>> least specify start/stop times for conferences,
>>> and that if
>>>>>>>>> the start time is in the future, that is a reservation.
>>>>>>>>
>>>>>>>> Agreed.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> What I want to discuss is, how far do we go, and what is
>>>>>>>> the end game?
>>>>>>>>> I think we can agree that generalized scheduling is
>>>> complex,
>>>>>>>>> and standards exist (iCal). So, the issue I want to
>>>>> discuss is:
>>>>>>>>> if we allow simple scheduling (start/stop) now,
>>>>>> do we EVENTUALLY
>>>>>>>>> allow complex scheduling? That implies
>>>>>> duplicating
>>>>>>> significant
>>>>>>>>> parts of e.g. iCal.
>>>>>>>>>
>>>>>>>>> We could consider an alternative - explicitly
>>>> support an iCal
>>>>>>>>> (actually iMIP) transaction now.
>>>>>>>>>
>>>>>>>>> One could allow the iMIP Request/Reply only (ie subset of
>>>>>>>>> iMIP) now (or maybe as a minimum).
>>>>>>>>>
>>>>>>>>> Or we could pull in some or all of calsch
>>>>>>>>
>>>>>>>> If there is an XML schema already defined that we can use,
>>>>>>> then it is
>>>>>>>> possible to embed that in CPCP. If you look at the solution
>>>>>>>> we are proposing (using XCAP), each feature, like
>>>>>>> conference-time, has its
>>>>>>> own
>>>>>>>> XML namespace.
>>>>>>>> We can take the iCal XML namespace and just drop it
>>> in there.
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Hisham
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Brian
>>>>>>>>>
>>>>>>>>>> -----Original Message-----
>>>>>>>>>> From: hisham.khartabil@nokia.com
>>>>>>>> [mailto:hisham.khartabil@nokia.com]
>>>>>>>>>> Sent: Wednesday, January 21, 2004 8:10 AM
>>>>>>>>>> To: eburger@snowshore.com; roni.even@polycom.co.il;
>>>>>>>>>> petri.koskelainen@nokia.com; xcon@ietf.org
>>>>>>>>>> Subject: RE: [XCON] CPCP Requirement: Repeat times
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Yes.
>>>>>>>>>>
>>>>>>>>>> We all have weekly meetings with predefined start
>>>> and stop
>>>>>>>>>> times. I think it is a valid use case for a user to
>>>>> create a
>>>>>>>>>> conference policy to satisfy this once and once only.
>>>>>>>>>>
>>>>>>>>>> Regards,
>>>>>>>>>> Hisham
>>>>>>>>>>
>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>> From: ext Eric Burger [mailto:eburger@snowshore.com]
>>>>>>>>>>> Sent: 20.January.2004 18:01
>>>>>>>>>>> To: Even, Roni; Khartabil Hisham (Nokia-TP/Helsinki);
>>>>>>>>>>> Koskelainen Petri
>>>>>>>>>>> (Nokia-NRC/Tampere); xcon@ietf.org
>>>>>>>>>>> Subject: RE: [XCON] CPCP Requirement: Repeat times
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> For that matter, is there a use case for end
>>>>> points (XCON)
>>>>>>>>>>> doing such complicated scheduling? Why don't we
>>>>> just take
>>>>>>>>>>> the bridge out of service?
>>>>>>>>>>>
>>>>>>>>>>> Wow! Agreeing with Roni twice in one day!!!
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>> From: Even, Roni [mailto:roni.even@polycom.co.il]
>>>>>>>>>>>> Sent: Wednesday, January 07, 2004 4:56 AM
>>>>>>>>>>>> To: 'hisham.khartabil@nokia.com'; Even, Roni;
>>>>>>>>>>>> petri.koskelainen@nokia.com; xcon@ietf.org
>>>>>>>>>>>> Subject: RE: [XCON] CPCP Requirement: Repeat times
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Hisham,
>>>>>>>>>>>>
>>>>>>>>>>>> The conference server is not mentioned in
>>>>>>>>>>>> draft-ietf-sipping-conferencing-framework-01. The
>>>>>> framework
>>>>>>>>>>>> mentioned the
>>>>>>>>>>>> conference policy server. As for reservation my
>>>>>>> view is that
>>>>>>>>>>>> reservation is
>>>>>>>>>>>> starting an ad-hoc conference when the schedule
>>>>> time has
>>>>>>>>>>>> arrived and it
>>>>>>>>>>>> should not be part of the conference policy.
>>>>>> Reservation is
>>>>>>>>>>> a separate
>>>>>>>>>>>> application from the conference policy. I
>>>>> suggest that if
>>>>>>>>>>> you want to
>>>>>>>>>>>> address it then we should have a separate
>>>>> element in the
>>>>>>>>>>>> frame work which
>>>>>>>>>>>> will be a reservation server.
>>>>>>>>>>>>
>>>>>>>>>>>> Roni
>>>>>>>>>>>>
>>>>>>>>>>>> *************************************
>>>>>>>>>>>> Roni Even
>>>>>>>>>>>>
>>>>>>>>>>>> Polycom Israel
>>>>>>>>>>>>
>>>>>>>>>>>> Tel: +972-3-9251200
>>>>>>>>>>>> Cell: +972-55-481099
>>>>>>>>>>>> email:roni.even@polycom.co.il
>>>>>>>>>>>> *******************************************
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>> From: hisham.khartabil@nokia.com
>>>>>>>>>> [mailto:hisham.khartabil@nokia.com]
>>>>>>>>>>>> Sent: Wednesday, January 07, 2004 11:22 AM
>>>>>>>>>>>> To: roni.even@polycom.co.il;
>>>>> petri.koskelainen@nokia.com;
>>>>>>>>>>>> xcon@ietf.org
>>>>>>>>>>>> Subject: RE: [XCON] CPCP Requirement: Repeat times
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> No, the focus host (conference server) is the
>>>> one that
>>>>>>>>> handles the
>>>>>>>>>>>> reservations. The focus is only created and
>>>>>>> destroyed by the
>>>>>>>>>>>> conference
>>>>>>>>>>>> server according to the start and stop times.
>>>>>>>>>>>>
>>>>>>>>>>>> /Hisham
>>>>>>>>>>>>
>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>> From: ext Even, Roni
>>>> [mailto:roni.even@polycom.co.il]
>>>>>>>>>>>> Sent: 06.January.2004 19:06
>>>>>>>>>>>> To: Koskelainen Petri (Nokia-NRC/Tampere);
>>>>> Even, Roni;
>>>>>>>>>>>> Khartabil Hisham
>>>>>>>>>>>> (Nokia-TP/Helsinki); 'xcon@ietf.org '
>>>>>>>>>>>> Subject: RE: [XCON] CPCP Requirement:
>>> Repeat times
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Hi Petri,
>>>>>>>>>>>> The CPS is a data storage that is used by the
>>>>>>> focus, so the
>>>>>>>>>>>> focus will have
>>>>>>>>>>>> to handle the reservation
>>>>>>>>>>>> Roni
>>>>>>>>>>>>
>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>> From: petri.koskelainen@nokia.com
>>>>>>>>>>>> To: roni.even@polycom.co.il;
>>>>>> hisham.khartabil@nokia.com;
>>>>>>>>>>>> xcon@ietf.org
>>>>>>>>>>>> Sent: 06/01/2004 18:50
>>>>>>>>>>>> Subject: RE: [XCON] CPCP Requirement:
>>> Repeat times
>>>>>>>>>>>>
>>>>>>>>>>>> Hi Roni,
>>>>>>>>>>>>
>>>>>>>>>>>> My opinion is that the conference policy
>>>>> needs only a
>>>>>>>>>>>> conference duration parameter if any.
>>>>>>>>>>>> I think that reservation is an external
>>>>>>>>>>>> application to the focus. According to the
>>>>> conference
>>>>>>>>>>>> framework the focus is using the
>>>> information in the
>>>>>>>>>>>> conference policy server and the focus is
>>>>>>>>>>>> not the right place for reservation.
>>>>>>>>>>>>
>>>>>>>>>>>> The reservation is sent to CPS, not to focus.
>>>>>>>>>>>> I think it makes sense to have this (repeat time)
>>>>>>>> capability in protocol since we need the feature anyway in
>>>>>>> real-world
>>>>>>>> (either in CPCP or in some new mystery protocol between the
>>>>>>> user and the
>>>>>>>>>>> reservation application).
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> Petri
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Regards
>>>>>>>>>>>> Roni Even
>>>>>>>>>>>>
>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>> From: hisham.khartabil@nokia.com
>>>>>>>>>>> [mailto:hisham.khartabil@nokia.com]
>>>>>>>>>>>> Sent: Monday, December 15, 2003 4:57 PM
>>>>>>>>>>>> To: xcon@ietf.org
>>>>>>>>>>>> Subject: [XCON] CPCP Requirement: Repeat times
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> 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.
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> 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
>>>
>>
>> _______________________________________________
>> 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
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.