Subject: RE: [Sipping] Comments on johnston-sipping-cc-conferencing-00.txt (the second duck in theline ;-)

From: Orit Levin <[email-masked]>
Date: Mon, 4 Nov 2002 12:47:40 -0500

>From the "requirements 01" draft:

"SIP conference is an association of SIP User Agents (e.g. conference
members) with a central member (e.g. a conference host), which has a direct
peer-wise relationship with each other member by means of a SIP dialog. Each
dialog can belong to a different SIP session."

"Member" is the CC SIP part of a "Participant". Participant is either a
human or a more sophisticated user application supporting policies, managing
media, etc. "Host" is a member, and therefore it is a SIP UA.

We (in the requirements draft) didn't model the conference server as a farm
of user agents. The "host" requirements mean the requirements from a
Conferencing SIP Host that maintains its Conferences with all the details
per each.

If the model of "a new focus UA per conference" reflects the reality in a
better way, I am perfectly OK with this. Then we should have both "the
focus" and the "farm of focuses", indeed.

I do have some problems with the framework still (which I expressed within
the design group). My regret was that we couldn't find time to align between
the drafts in time.

That being said, I am glad then these discussions greatly contribute towards
this direction.

Orit.

> -----Original Message-----
> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Monday, November 04, 2002 10:02 AM
> To: Orit Levin
> Cc: Rosen, Brian; [email-masked]
> Subject: Re: [Sipping] Comments on johnston-sipping-cc-conferencing-
> 00.txt(the second duck in theline ;-)
> 
> 
> 
> Orit Levin wrote:
> >
> > Guys!
> > It seems that we are debating the least controversial part in the whole
> set
> > of the conferencing documents.
> 
> That should be a *good* thing! Means the stuff you though was
> controversial isn't.
> 
> > Below is my point of view.
> >
> > Focus is the "conference factory" or the "conference server" itself.
> 
> In this you are in conflict with the framework document.
> 
> > (Focus
> > is called "host" in the old version of the "requirements" draft.)
> 
> Which old version? The ones I can find, including one authored by you,
> don't define "host" or use it as a noun, or in any formal way.
> 
> > According to all focus definitions, "Focus is a UA".
> 
> OK. No problem there.
> 
> > This UA has special
> > capabilities of creating and "hosting" conferences (i.e. instances of
> > Conference). Focus has two published AORs: one the general UA AOR,
> second
> > the Focus AOR is the entry to its "conference factory".
> 
> You are now on shakey ground.
> 
> The way I have always thought of it, every distinct address is
> conceptually a unique UA. Since each "conference" gets its own address,
> every conference is itself a separate UA. And since the "factory" that
> creates conferences has an address distinct from the conferences it
> creates, it too is a UA.
> 
> "Focus" can be one or the other of these, but not both. According to the
> framework document, the Focus is the UA corresponding to the address of
> the conference itself. You need a different term to refer to the factory.
> (Note that the factory need not reside on the same "server" where the foci
> of the conferences it creates reside.)
> 
> >
> > I don't think we would like to start instantiating UAs (i.e. focuses) in
> our
> > model (together with their AORs.)
> 
> That is exactly what you are doing when you specify that you can create
> new conferences, each with its own address.
> 
> This doesn't of course mean that we must start instantiating new physical
> servers to host the UAs. The UA is simply a logical (virtual) concept. All
> it requires is an extra entry in the server that hosts it, listing the
> user part of the address. Why is this a problem?
> 
> >
> > Based on current conferencing requirements and conferencing models, I
> don't
> > see need for generating additional terminology. I would rather
> streamline
> > some redundant definitions than introduce new (unless we identify
> practical
> > need for them, of course!)
> >
> > If the current focus definition is somehow misleading, I suggest fitting
> the
> > definition to the model rather then fitting the model to the definition.
> 
> That's what I'm trying to do, and I think that is what the framework is
> trying to do. But clearly others have felt that new terminology is
> required. The term "focus"  doesn't appear in any meaningful way in the
> older requirements or model documents. I presume it has been coined to
> facilitate the creation of more precise definitions. But that doesn't work
> if we end up with "focus" itself having a fuzzy definition.
> 
> It is pretty common to mix up the definition of a server and the things it
> serves, or a factory and the things it creates, especially when first
> coming up with a conceptual model for something new. But eventually you
> need to sort out the differences.
> 
> 	Paul
> 
> 
> I don't have any problems with the framework.
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 04 Nov 2002 14:14:39 -0500

> Conferencing SIP Host that maintains its Conferences with all the details

OK - my mistake - host is better defined than I thought. (I searched my private store of documents and only found the -00 requirements.)

In draft-levin-sipping-conferencing-requirements-01 "host" is used both to identify the UA the maintains dialogs with all active participants in the conference, *and* the entity that creates conferences. I think it is probably fine to leave things that way in the requirements, but disambiguate them in the framework and in cc-conference. This shouldn't be confusing because the term "host" isn't being used in those documents.

> That being said, I am glad then these discussions greatly contribute towards

I don't want to be negative about this work at all. I think it is *great* work. When it is being done by a loosely affiliated bunch of people there are bound to be inconsistencies along the way. Whether they come across that way or not I intend my comments to be constructive - identifying the odd loose ends that need to be cleaned up. 

I know how easy it is for a group to come to verbal concensus and then, when writing it down, to omit things that are necessary for someone else to understand what the group agreed to.

	Paul