Re: [XCON] Is the goal to Build H.3261?

[Cullen Jennings <fluffy at cisco.com>]

I'm not being clear on what I am saying here. I'm not saying that because
TCP can be used in a conferencing system, TCP has to say how to do it. I'm
not saying that because the protocols XCON defines are used in conferences
that XCON has to define how calendaring or reservations work - as you point
out I have argued in the past that both of those are complicated problems.
I'm just saying that the XCON protocols are going to be goofy if they can
not be used in systems that do involve schedules, reservations, and even
multicast. 

I'm in the middle of trying to build a system that supports the XCON
protocols. However, this systems conferencing system will integrate with the
two most popular calendaring systems and will do resource reservation. It's
reasonable to question if one needs reservation for audio but it's certainly
needed for video. 

Now I don't see how I am going to make this work unless the XCON data model
or architecture has the idea of changing the things it is allowed to change
on both the sequence and on the individual.

I've seen several proposal that work work for this:

Brian proposed: there is a series and you can change all instances of the
series, or a particular instance

Henning proposed: there is a tree, the instances correspond to leaf nodes
and you can edit the the leaf or the common parent which represents the
series

Cullen proposed: there is a master or default copy for the series that you
can edit and a list of related instances with individual specializations

Adam proposed: we have a group of meetings and you can make changes on the
group or on the instances in the group

Mary/Chris/Orit proposed: we have an explicit thing called a reservation
which spawns conference instances.

Now *any* of the above proposal would work for me. Here are the two things I
can' see working. 

1) Many instances of one a recurring conference are represented by one named
object. This may be fine for rules but for the state I don't know how, when
one instance does not end before the other starts, I will be able to
represent that User A is a participant in the first conference but is not in
the second conference.

2) There is an object for every instance of a conference and they have no
relationship to each other. The reason I can' make this work is that there
are infinite number of of instances of a single recurring conference. The
other issue is that, in practice, if I am using CCCP or CPCP to change
something about the conference, I am just as likely to want to change it for
every instance as for a single instance. Let's take a specific example -
imagine I am setting up a conference my IP phone and I want to setup the
dialout to call my cell phone. I hope no one is seriously suggesting I need
to implement one protocol if it is a recurring meeting and a different
protocol if it is a just setting it for a single instance.

This problem is not really about scheduling - it's just that scheduling
illustrates the issue. Let me bring up another example where this problem
comes up. Say I have a conference system where I dial into a single number
and enter a meeting ID code in an IVR system. Every system I have every used
allows a recurring meeting with the same meeting ID code. When the user
dials in, the system needs to connect them to the most recent conference
instance that has this ID code. Now most systems will allocate you a code or
let you pick one. The user selected one typically called called a vanity ID.
The scheduling system will not know what ID are allocated at what times -
it's hopeless to try and make this happen - the conferencing system will
need to deal with this. Now I'm not saying XCON needs to define how to do
this. However, xcon needs to recognize that the xcon protocol will be used
in systems that do this and define the things that xcon does in a way that
does not make preclude the conferencing system from solve the above issues.

I'm not advocating that an XCON system MUST support reacuring meeting - I
can imagine systems that won't. I just want the data model rich enough that
it can be used in a conferencing system that does support recurring
meetings. 

Again, we have proposals from Brian, Cullen, Adam, Orit, Mary, Chris,
Henning which all allow this. None of these result in XCON defining a
conferencing system. Let's start talking about which one of the proposals
makes sense - actually, they may all be much the same thing when you get
down to what state is where and only differ in the metaphor used to describe
them. 

Cullen

 

On 12/29/04 1:34 PM, "Adam Roach" <adam at nostrum.com> wrote:

> [not as chair]
> 
> Cullen Jennings wrote:
> 
>> I don't think this proposal works. The proposal pushes the problem of
>> resource reservation into the calendaring system. The calendaring system has
>> to be able to ask the conferencing system to reserve resources for an
>> infinite series of meetings and find out if that is available or not. The
>> calendaring system won't understand the resources well enough to reserve
>> them even if it wanted to.
>>  
>> 
> 
> In Korea, you adamantly argued that resource reservation was way out of
> scope for XCON. (Search
> http://www.softarmor.com/xcon/meets/ietf59/xcon-minutes.txt for the
> phrase, "Cullen thought reservations are way out of scope.")
> 
> I agree with the Cullen who spoke at the microphone in Seoul last March.
> 
>> The other issues is that saying a meeting that was created by the
>> calendaring system can only be modified thought the calendaring systems does
>> not really work for me. I want to be able to use the XCON protocol for a
>> client to change something like who the moderators is for a conference (see
>> previous use case), or change the list of allowed participants. I'm imaging
>> that the connector to the calendar system would be able to use the XCON
>> protocol to talk to the conferencing system and modify meetings.
>>  
>> 
> 
> Perhaps the ability to say, "Create a conference on Thursday, January
> 13th, 2005 at 16:00 UTC for one hour; make it part of group A," and
> having the ability to manipulate all conferences in group X (e.g.
> "change the moderator for all conferences in group X to Cullen") would
> be a reasonable thing to do.
> 
> The ability to semantically say, "create a group of meetings that
> happens every Thursday starting now, running indefinitely, at 10:00 am
> UTC+5 from the first Sunday in April at 2:00 am until the last Sunday of
> October at 2:00 am, and UTC+6 otherwise" would basically entail either
> sucking in all of iCal as part of the XCON protocols or replicating most
> of the iCal functionality in XCON. Both solutions would lead to a
> protocol that is unrealistic to implement for both clients and servers.
> The latter approach clearly involves XCON working well outside its charter.
> 
>> Today's conferencing systems have web pages where you can go and schedule
>> and modify conferences and they sync that with calendaring systems. One way
>> of looking at XCON is standardizing some ways to describing the knobs and
>> controls on these web pages so they can be remote controlled by clients that
>> understand them.
>> 
> 
> XCON was chartered to solve a narrow set of problems surrounding very
> specific aspects of conferencing, not every problem that might be
> related to the conferencing space in some way. We're not trying to
> address collaborative document editing. We're not trying to address
> focus control of mixers in the cases that such functions are physically
> separate. We're not trying to address general purpose calendaring
> systems for conference scheduling. That's not to say that these are
> uninteresting problems, or that they must not be solved; however, they
> are *separable* problems that will be solved *elsewhere*.
> 
> /a
> 
> _______________________________________________
> XCON mailing list
> XCON at ietf.org
> https://www1.ietf.org/mailman/listinfo/xcon


_______________________________________________
XCON mailing list
XCON at ietf.org
https://www1.ietf.org/mailman/listinfo/xcon