Subject: RE: [XCON] CPCP Requirement: Repeat times

From: "Even, Roni" <[email-masked]>
Date: Tue, 6 Jan 2004 14:16:08 +0200

Hi, 
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.
Regards
Roni Even

*************************************
Roni Even

Polycom Israel

Tel: +972-3-9251200
Cell: +972-55-481099
email:[email-masked]
*******************************************

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Monday, December 15, 2003 4:57 PM
To: [email-masked]
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.

Regards,
Hisham

_______________________________________________
XCON mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/xcon

_______________________________________________
XCON mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/xcon

---

From: [email-masked]
Date: Tue, 6 Jan 2004 18:50:37 +0200

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

---

From: "Even, Roni" <[email-masked]>
Date: Tue, 6 Jan 2004 19:06:11 +0200

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: [email-masked]
To: [email-masked]; [email-masked]; [email-masked]
Sent: 06/01/2004 18:50
Subject: RE: [XCON] CPCP Requirement: Repeat times 

Hi Roni,

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

---

From: [email-masked]
Date: Wed, 7 Jan 2004 11:21:55 +0200

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

> From: ext Even, Roni [mailto:[email-masked]]
> Sent: 06.January.2004 19:06
> To: Koskelainen Petri (Nokia-NRC/Tampere); Even, Roni; 
> Khartabil Hisham
> (Nokia-TP/Helsinki); [email-masked] '

---

From: "Chris Boulton" <[email-masked]>
Date: Wed, 7 Jan 2004 14:46:08 -0000

I agree with Paul.  We are already in danger of over-complicating the
work being done in XCON.  There does not seem to me to be any
detrimental effects of having this policy information included in CPCP.

Chris.

>From: Paul Kyzivat [mailto:[email-masked]]
>Sent: 07 January 2004 14:35
>To: Even, Roni
>Cc: [email-masked]'; [email-masked];
>[email-masked]
>Subject: Re: [XCON] CPCP Requirement: Repeat times
>
>Roni,
>
>To me this is splitting hairs. I think it makes sense to include start
>and stop time(s) in the conference policy - they are quite consistent
>with other kinds of policy information. How that policy gets acted upon
>is irrelevant, as long as it does get acted upon - it is an
>implementation detail. It might be acted upon directly by the policy
>server, or by a separate conference server, or some other way. The
>simple fact is that you can influence it by changing the policy using
CPCP.
>
>Do you really want to standardize another active entity and another
>protocol just for this?
>
>	Paul
>
>Even, Roni wrote:
>> 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
>>
>> Sent: Wednesday, January 07, 2004 11:22 AM
>> To: [email-masked]; [email-masked];
[email-masked]
>> 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
>>
>>

This message has been scanned for viruses by MailControl - www.mailcontrol.com

---

From: "Eric Burger" <[email-masked]>
Date: Tue, 20 Jan 2004 11:00:39 -0500

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

> From: Even, Roni [mailto:[email-masked]]
> Sent: Wednesday, January 07, 2004 4:56 AM
> To: [email-masked]'; Even, Roni;
> [email-masked]; [email-masked]
> draft-ietf-sipping-conferencing-framework-01. The framework 
> mentioned the
> 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
> address it then we should have a separate element in the 
> frame work which

---

From: [email-masked]
Date: Wed, 21 Jan 2004 15:09:55 +0200

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

> From: ext Eric Burger [mailto:[email-masked]]
> Sent: 20.January.2004 18:01
> To: Even, Roni; Khartabil Hisham (Nokia-TP/Helsinki); 
> Koskelainen Petri
> (Nokia-NRC/Tampere); [email-masked]
> 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?
>

---

From: "Eric Burger" <[email-masked]>
Date: Wed, 21 Jan 2004 08:15:20 -0500

So the use case isn't "I'm taking the bridge out of service for maintenance", but "I have a weekly meeting, except for next week."

That would be better handled by a calendaring application (i.e., why it doesn't belong in XCON).

> Sent: Wednesday, January 21, 2004 8:10 AM
> To: Eric Burger; [email-masked]; [email-masked];
> [email-masked]
> 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
>

---

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 21 Jan 2004 09:38:38 -0500

I did a reply instead of reply all :(

Brian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, January 21, 2004 9:37 AM
To: [email-masked]
Subject: RE: [XCON] CPCP Requirement: Repeat times 

Brian,

I'm not sure if your reply was supposed to be to the list or just personal.
Anyway, some response inline...

> From: ext Rosen, Brian [mailto:[email-masked]]
> Sent: 21.January.2004 16:09
> To: Khartabil Hisham (Nokia-TP/Helsinki)
> 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
> > To: [email-masked]; [email-masked];

---

From: [email-masked]
Date: Wed, 21 Jan 2004 16:51:20 +0200

Great, we can do what you did for CPL, or even rip off what you have for CPL.

Just to point out that the currently proposed solution has, here is an example:

            <conference-time:Conference-time>
               <Conference-occurrence>
                  <Start-time>2003-06-16T10:00:00Z</Start-time>
                  <Repeat interval="604800" Active-duration="3600" offsets="0 90000"/>
                  <Stop-time>2003-09-16T12:00:00Z</Stop-time>
               </Conference-occurrence>
            </conference-time:Conference-time>

http://www.ietf.org/internet-drafts/draft-koskelainen-xcon-xcap-cpcp-usage-01.txt if you want to read details.

I think it is very similar to what you have in CPL, but we can unify the syntax.

/Hisham

> From: ext Henning Schulzrinne [mailto:[email-masked]]
> Sent: 21.January.2004 15:46
> Cc: [email-masked]; [email-masked]
> [email-masked] wrote:
> 
> > There is no need to blow up a simple requirement of start, stop and
> > repeat times which can easily be handled in CPCP to be the size of
> > calendering that requires a separate protocol that needs to be
> > somehow linked to the corresponding conference policy.
> 
> 
> As soon as you have repeat times, you run into the problem 
> that people 
> expect to be able to export real calsch-like repeat times 
> ("every other 
> Monday, except if it is Dec. 25"), not just the basic subset. 
> We had the 
> same discussion for CPL and ended up with calsch, rather than 
> trying to 
> do 20% or 50% of it.
> 
> > 
> > /Hisham
> 
>

---

From: [email-masked]
Date: Sun, 25 Jan 2004 15:31:20 +0200

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

> > least specify start/stop times for conferences, and that if 
> > the start time is in the future, that is a reservation.
> 
> Agreed.
> 
> > 
> > and standards exist (iCal).  So, the issue I want to discuss is:
> > 		allow complex scheduling?  That implies duplicating significant
> > 		parts of e.g. iCal.
> > 
> > (actually iMIP) transaction now.  
> > 
> > iMIP) now (or maybe as a minimum).  
> > 
> 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.
> > > > > > 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
> > > > > > > 
> > > > > > 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.

---

From: "Even, Roni" <[email-masked]>
Date: Sun, 25 Jan 2004 15:43:53 +0200

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

Polycom Israel

Tel: +972-3-9251200
Cell: +972-55-481099

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Sunday, January 25, 2004 3:31 PM
To: [email-masked]
Subject: RE: [XCON] CPCP Requirement: Repeat times 

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

significant

---

From: "Even, Roni" <[email-masked]>
Date: Mon, 26 Jan 2004 14:44:33 +0200

Hisham,
I can not understand why you conclude that there is a rough consensus. I
looked at this thread and there are mixed views.
I would like to add that considering another protocol like iCal points again
to show that this is a different application. 
I can agree to conference duration but I would recommend not to get into
future reservations
Roni

VP Product Planning
Polycom Israel

Tel: +972-3-9251200
Cell: +972-55-481099

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Monday, January 26, 2004 1:43 PM
To: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [XCON] CPCP Requirement: Repeat times 

Roni,

Your objection is noted, but I believe we have rough consensus on this issue
already. The most recent discussions on the list have already tapped into
the solution domain.

Regards,
Hisham

> From: [email-masked] [mailto:[email-masked]]On Behalf Of ext
> Even, Roni
> Sent: 25.January.2004 15:44
> To: Koskelainen Petri (Nokia-NRC/Tampere); [email-masked]
> > we are proposing (using XCAP), each feature, like 
> conference-time, has its
> own 
> > XML namespace.
> > > > > > > The CPS is a data storage that is used by the 
> focus, so the 
> > > > > > > focus will have
> > > > > current proposed solution has repeat times (eg: 
> meeting repeats
> weekly),

---

From: [email-masked]
Date: Mon, 26 Jan 2004 13:42:33 +0200

Roni,

Your objection is noted, but I believe we have rough consensus on this issue already. The most recent discussions on the list have already tapped into the solution domain.

Regards,
Hisham

---

From: [email-masked]
Date: Tue, 27 Jan 2004 16:06:36 +0200

The issue is complex if we choose to make it so. A simple start, stop and repeat times will suffice for now. If we realise the need to create or adopt a separate and complex protocol for scheduling, then we can take that issue up then. In the mean time, I suggest to keep it simple. Many folks agreed that simple scheduling is needed and is not harmful. The implementation will be optional.

/Hisham

> Sent: 26.January.2004 17:02
> To: Khartabil Hisham (Nokia-TP/Helsinki); Even, Roni; 
> Koskelainen Petri
> What I claimed that the example and the complexity of the 
> issue where raised
> as an objection and not as an agreement
> Roni
> 
> Sent: Monday, January 26, 2004 4:34 PM
> I believe there has been more voices for having scheduling 
> information in a
> conference policy than not. The issue was how complex do we make it.
> 
> iCal was introduced in the discussion as an indicator of how 
> complex it can
> be.
> 
> Perhaps I'm missing your point. What was the reason for your objection
> again?
> 
> /Hisham
> 
> > Sent: 26.January.2004 14:45
> > To: Khartabil Hisham (Nokia-TP/Helsinki); Even, Roni; 
> > Koskelainen Petri
> > [mailto:[email-masked]]
> > > > > > > > should not be part of the conference policy. 
> > Reservation is 
> > > > > > > a separate
> > > > > > > > application from the conference policy. I 
> suggest that if 
> > > > > > > you want to
> > > > > > > > > To: [email-masked]; 
> > [email-masked]; 
> > > > > > > > [email-masked]
> > > > > > > > > Sent: 06/01/2004 18:50

---

From: "Even, Roni" <[email-masked]>
Date: Tue, 27 Jan 2004 16:34:23 +0200

Hi,
 If the start stop and repeat time are for knowledge and do not mean a
reservation of any resource on the conferencing server than it is simple.
Any other meaning for the parameters is not simple. Resources for multimedia
conferences are not simple. if you have voice activated video switch
conference or if you have a 4x4 mixed video there is a need for difference
resource management. Even the number of different mixes you want to create
make it more complicated. 
And of course Eric Burger's comment about the definition of scheduling is
complex.
Overall I see reservation as a separate application then ad-hoc conferences.
Roni

Tel: +972-3-9251200
Cell: +972-55-481099

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, January 27, 2004 4:07 PM
To: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [XCON] CPCP Requirement: Repeat times 

The issue is complex if we choose to make it so. A simple start, stop and
repeat times will suffice for now. If we realise the need to create or adopt
a separate and complex protocol for scheduling, then we can take that issue
up then. In the mean time, I suggest to keep it simple. Many folks agreed
that simple scheduling is needed and is not harmful. The implementation will
be optional.

/Hisham

---

From: [email-masked]
Date: Tue, 27 Jan 2004 17:19:38 +0200

[why is the XCON reflector so slow?]

Roni,

Start time indicates to the focus when it should start inviting users and/or allow users to join.
Stop time indicates to the focus when it should terminate sessions with users.
Repeat time indicates when this process starts again.

The other issue is scheduling and resource reservation as you define it: why do you see that CPCP is not suitable to this and a separate protocol is required? Why scheduling can't be part of the conference policy? (I'm just trying to understand your point of view)

Regards,
Hisham

> Sent: 27.January.2004 16:34
> > > > > > > > > No, the focus host (conference server) is the 
> one that 
> > > > > > handles the

---

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 27 Jan 2004 11:54:25 -0500

I point out that resource reservation is local to the server, and not
subject to standardization.  The actual request for the reservation
(start/stop/repeat/#ports/media...) is.

Brian

> Sent: Tuesday, January 27, 2004 10:20 AM
> Start time indicates to the focus when it should start 
> inviting users and/or allow users to join.
> The other issue is scheduling and resource reservation as you 
> define it: why do you see that CPCP is not suitable to this 
> and a separate protocol is required? Why scheduling can't be 
> part of the conference policy? (I'm just trying to understand 
> your point of view)
> 
> Regards,
> Hisham
>

---

From: "Eric Burger" <[email-masked]>
Date: Mon, 26 Jan 2004 14:22:45 -0500

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

> Sent: Sunday, January 25, 2004 8:44 AM
> To: [email-masked]'; [email-masked]

---

From: "Even, Roni" <[email-masked]>
Date: Mon, 26 Jan 2004 17:02:19 +0200

Hisham,
What I claimed that the example and the complexity of the issue where raised
as an objection and not as an agreement
Roni

Tel: +972-3-9251200
Cell: +972-55-481099

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Monday, January 26, 2004 4:34 PM
To: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [XCON] CPCP Requirement: Repeat times 

I believe there has been more voices for having scheduling information in a
conference policy than not. The issue was how complex do we make it.

iCal was introduced in the discussion as an indicator of how complex it can
be.

/Hisham

---

From: [email-masked]
Date: Wed, 28 Jan 2004 13:49:55 +0200

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

> [email-masked]
> Sent: 28.January.2004 09:30
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> 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
> 
> > Eric Burger
> > Sent: 26.January.2004 21:23
> > To: [email-masked]
> > Cc: Even, Roni
> > 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"?
> > 
> > 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 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."
> >

---

From: [email-masked]
Date: Wed, 28 Jan 2004 16:03:54 +0200

Ok, I agree that there is no need to repeat time at this stage.

/Hisham

> Sent: 28.January.2004 15:30
> Cc: [email-masked]; [email-masked]; [email-masked]
> > 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.
> 
> It's unclear to me what value repeat times add. They are just an 
> abbreviation for having several instances. Repeat times make 
> sense for a 
> human user, but CPCP is likely at least one layer of 
> indirection removed 
> from a GUI. The problem with repeat times is that things get messy 
> quickly, even for the seemingly trivial cases. Random example: 
> conference repeats once a week at 9 am. However, daylight 
> savings time 
> happens during the repeats. If you just repeat every 86400*7 seconds, 
> suddenly your conference starts an hour earlier or later than you had 
> planned on. Thus, you now need to make sure you encode timezones 
> correctly, plus making the implementation messier and more 
> error-prone, 
> for no additional functional capability that couldn't have been 
> expressed by just enumerating the instances.
>

---

From: "Boyer, David G (Dave)" <[email-masked]>
Date: Wed, 28 Jan 2004 09:39:07 -0500

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: [email-masked] [mailto:[email-masked]]On Behalf Of
[email-masked]
Sent: Wednesday, January 28, 2004 6:50 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [XCON] CPCP Requirement: Repeat times 

Regards,
Hisham

---

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Thu, 29 Jan 2004 14:57:22 -0000

I am not convinced we need the repeat times either.

That is surely something that can be dealt with by some other application which then uses CPCP.

regards

Keith

> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: 28 January 2004 13:30
> To: [email-masked]

---

From: "Chris Boulton" <[email-masked]>
Date: Thu, 29 Jan 2004 15:02:22 -0000

I'm also not convinced that this is a requirement.

Chris.

>From: Drage, Keith (Keith) [mailto:[email-masked]]
>Sent: 29 January 2004 14:57
>To: Henning Schulzrinne; [email-masked]
>Cc: [email-masked]
>That is surely something that can be dealt with by some other
application
>which then uses CPCP.

---

From: [email-masked]
Date: Thu, 29 Jan 2004 17:23:53 +0200

Hi,
Agreed. I'll submit new version shortly including requirements only for start/stop times.

Petri

> Chris Boulton
> Sent: 29 January, 2004 17:02
> To: Drage, Keith (Keith); Henning Schulzrinne; Khartabil Hisham
> (Nokia-TP/Helsinki)
> Cc: [email-masked]
> start with

---

From: "Eric Burger" <[email-masked]>
Date: Thu, 29 Jan 2004 10:41:50 -0500

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.

> From: Boyer, David G (Dave) [mailto:[email-masked]]
> Sent: Wednesday, January 28, 2004 9:39 AM
> To: [email-masked]; Eric Burger; [email-masked]
> 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.
> 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.
> 
> 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.
>

---

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 29 Jan 2004 10:48:21 -0500

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

> From: Eric Burger [mailto:[email-masked]]
> Sent: Thursday, January 29, 2004 10:42 AM
> To: [email-masked]; [email-masked]
> 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...
>

---

From: "Eric Burger" <[email-masked]>
Date: Thu, 29 Jan 2004 10:56:23 -0500

If the start time is not in the future, it makes for a pretty useless service :-)

I can go for that.

> From: Rosen, Brian [mailto:[email-masked]]
> Sent: Thursday, January 29, 2004 10:48 AM
> To: Eric Burger; [email-masked]; [email-masked]
> > > > > > 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
> > > > > > 
> > > > > > > > What I want to discuss is, how far do we go, 
> and what is 
> > > > > > > the end game?
> > > > > > > If there is an XML schema already defined that we 
> can use, 
> > > > > > then it is
> > > > > > > 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

---

From: "Eric Burger" <[email-masked]>
Date: Thu, 29 Jan 2004 11:16:55 -0500

iCal isn't just an example of complexity, but an example of something that exists.

> Sent: Monday, January 26, 2004 9:34 AM
> information in a conference policy than not. The issue was 
> how complex do we make it.
> 
> complex it can be.
> Perhaps I'm missing your point. What was the reason for your 
> objection again?
> 
> /Hisham
>

---

From: Alan Johnston <[email-masked]>
Date: Thu, 29 Jan 2004 10:50:49 -0600

Sounds like we are headed towards consensus on this.

The requirement for having a start time (in the future) is so that a 
conference URI can be reserved in advance.  The reservation of actual 
resources is way, way beyond XCON's charter.

Thanks,
Alan Johnston
MCI
sip:[email-masked]

---

From: Nermeen Ismail <[email-masked]>
Date: Fri, 30 Jan 2004 11:02:28 -0800

>I am also okay with no repeats.

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