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

From: Orit Levin <[email-masked]>
Date: Sat, 2 Nov 2002 11:19:29 -0500

Guys!
It seems that we are debating the least controversial part in the whole set
of the conferencing documents.
Below is my point of view.

Focus is the "conference factory" or the "conference server" itself. (Focus
is called "host" in the old version of the "requirements" draft.)
According to all focus definitions, "Focus is a UA". 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".

I don't think we would like to start instantiating UAs (i.e. focuses) in our
model (together with their AORs.)

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.

Cheers,
Orit.

> -----Original Message-----
> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Friday, November 01, 2002 2:36 PM
> To: Rosen, Brian
> Cc: 'Orit Levin'; [email-masked]
> Subject: Re: [Sipping] Comments on johnston-sipping-cc-conferencing-
> 00.txt(the second duck in theline ;-)
> 
> 
> 
> "Rosen, Brian" wrote:
> >
> > We went round and round on names, and we agreed on
> > focus.  Of course we can go round and round again,
> > but the design team got there by agreeing that
> > the name needed to be something that did not
> > imply multiple things to multiple people based on
> > past experience.  "Focus" has that characteristic,
> > Where "Conference Server" doesn't.
> 
> I *like* the term "Focus" as used in the framework.
> 
> >
> > The confusion of focus URI and conference URI I think
> > is pretty small.
> 
> Technically it is small - certainly it is easily fixed.
> But I think it is important.
> 
> If you have an entity called a "Focus" that can be identified by a URI,
> and you also have something called a "Focus URI", then it only makes sense
> that the Focus URI should identify a Focus. It is the violation of this
> common sense that I find troubling.
> 
> 
> > The focus entity could be the focus
> > for multiple conferences,
> 
> Here you depart from the framework document. Are you suggesting that there
> is something else, called a "Focus Entity" that is different from a
> "Focus", or are you simply referencing the "Focus" entity?
> 
> In the framework, each distinct conference has its own, separately
> addressable, Focus. So you would not have the case of a single Focus for
> multiple conferences.
> 
> The framework doesn't seem to have a term for what you are calling "Focus
> Entity". I believe such a term would be useful, but "Focus Entity" seems
> like a poor choice because it is too easily confused with "Focus".
> 
> > thus you need to distinguish
> > between conferences, and the conference URI is the
> > way you do that.
> 
> One way would be to use the term "Focus URI" to reference the Focus. But
> Conference URI also seems well (better) suited for this.
> 
> > The cc-conference draft proposes that
> > the focus be able to create a conference URI as a result
> > of a sip request to the focus entity.
> 
> Once again the underlying concepts are fine, but the the terminology is
> unnecessarily confusing. You have a "Focus Entity", identified by a "Focus
> URI" (not "Focus Entity URI"), interacting with a "Focus" (different from
> the "Focus Entity") to create a "Conference URI" that identifies the
> "Focus".
> 
> > The way it
> > proposes is to have a URI that accepts a request to
> > create a conference URI.
> 
> I like this approach.
> 
> > There are other ways you could
> > request the focus to create a conference URI.  For example,
> > the focus could have a web page and you could ask it
> > to make you a conference URI which you then cut/paste, email
> > or otherwise disseminate.
> 
> Is it the "Focus", or the "Focus Entity" that you ask to create a
> conference URI?
> 
> In principle, you can't ask the Focus until it exists. And it won't exist
> until the conference is created. So presumably you must first ask the
> Focus Entity to create the conference, and then ask the Focus to create a
> Conference URI for the conference.
> 
> Seems like it would be simpler to describe this as asking the "Focus
> Entity" to create the Conference and the Conference URI. The Focus itself
> need not come into existence until the first attempt to contact it.
> 
> > The cc-conference proposal to
> > use a focus URI is a new one, and I think it has some merit.
> > If "focus URI" is too confusing, we could try to come up
> > with another name.  "conference URI factory" perhaps?
> 
> My *only* issue here is naming of things. Here is a suggestion:
> 
> 
>  OLD NAME		NEW NAME		COMMENT
> 
>  Focus Entity		Conference Factory
>  Focus URI		Conference Factory URI
>  Focus			Focus			unchanged
>  Conference URI		Conference URI		unchanged
>  Conference URI		Focus URI		synonym
> 
> I am suggesting considering "Conference URI" and "Focus URI" as synonyms.
> Alternatively "Focus URI" could simply become a term that is intentionally
> undefined. In practice, the term is likely to be used informally even if
> it isn't defined, so its important that it not get a conflicting
> definition.
> 
> Sorry to be a pain in the ass, but I think this is unnecessarily
> confusing, and fixing it now will save a lot of grief later.
> 
> 	Paul
_______________________________________________
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 10:02:12 -0500

> of the conferencing documents.

That should be a *good* thing! Means the stuff you though was controversial isn't.

> Focus is the "conference factory" or the "conference server" itself.

In this you are in conflict with the framework document.

> (Focus

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

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

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

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