Subject: RE: [Simple] Data model - attempt at summary (Groups)

From: "Boyer, David G \(Dave\)" <[email-masked]>
Date: Thu, 21 Oct 2004 16:02:55 -0400

Johnathan,

I think the problem is we are saying that a "person" can really
represent
an entity that is not a person.  What has been discused so far
concerning groups are
- a group can represent a list of users (this is not appropriate for the
<person>
object in the model)
- or a group can represent an "entity" that is the sum of it's
constituants, I guess it is not necessarilly the sum, could be a union,
but it 
represents something unique in it's own right, kind of a meta object.  A
call center
entity represents the capabilities of it's group members.  There may be
no single 
group member that has all that capabilities that the call center object
has.  The
call center object is unique in that sense and also may have unique
contact URIs
so that no member's contact information is exposed.  Calling this entity
a <person>
is confusing.  I keep using the word entity to describe this, more
generic
than person I guess.  If we call it an "entity" - an entity could
represent a person, 
a group (in the sense of something unique in it's own right), an
application, a bot,
etc.  Just seems that what we are talking about here is more than a
person.

Dave
> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]] 
> Sent: Tuesday, October 19, 2004 9:44 PM
> To: Boyer, David G (Dave)
> Cc: Henning Schulzrinne; Simple WG; Mataga, Peter Andrew (Peter)
> Subject: Re: [Simple] Data model - attempt at summary (Groups)
> 
> 
> I suspect part of the problem here is that the words in the 
> document are 
> not quite right to explain the intent. I agree with Henning here that 
> you can model "groups", in as much as you can represent them 
> as a single 
> person. That is, the model only talks about a single person. 
> Whether or 
> not the thing BEHIND the URI in the document is actually multiple 
> people, we cannot prevent, but we cannot explicitly provide 
> information 
> about this fact.
> 
> The example as Henning points out, is a URI like "[email-masked]". 
> WIth the model, you could say that thre is a <person> and they are 
> available, and they have a voip service with a specific URI. 
> In reality, 
> this URI could be routed to one of several people, and thus the URI 
> really represents a group. The model can't capture this finer 
> granularity.
> 
> Suggestions on text improvement are welcome.
> 
> -Jonathan R.
> 
> Boyer, David G (Dave) wrote:
> 
> > Henning:
> > 
> > inline
> > 
> > 
> >>-----Original Message-----
> >>From: Henning Schulzrinne [mailto:[email-masked]]
> >>Sent: Monday, October 18, 2004 10:29 AM
> >>To: Boyer, David G (Dave)
> >>Cc: Simple WG; Mataga, Peter Andrew (Peter)
> >>Subject: Re: [Simple] Data model - attempt at summary (Groups)
> >>
> >>
> >>Dave:
> >>
> >>Can you point out which part of the data model is being
> >>contradicted? I 
> >>thought that statement was simply a summary of the data model 
> >>assumption.
> > 
> > 
> > I thought you were contradicting the statement in the data 
> model draft 
> > - "Nothing in the model mandates that the entity being modeled is 
> > actually composed
> >    of a single user. "
> > 
> > I interpreted this statement to imply group support.  I 
> think I have a 
> > different definition for group - see next comment.
> > 
> >>(Contact centers as a whole can be represented, if they look like a
> >>single individual through aggregation. There's nothing 
> fundamentally 
> >>different about Joe Salesman and [email-masked] (the whole sales 
> >>crew), as long as they appear both like a single logical 
> >>entity. It does 
> >>mean you can't choose whether you want to talk to Alice, Bob 
> >>or Carol in 
> >>the call center. They can't be at different locations, etc.)
> > 
> > 
> > What you describe above is a good example of what I would call a 
> > group.  When you said - "We model only one person (and 
> possibly their 
> > assistant), not groups of individuals."
> > Were you thinking of a group as something different in this 
> > statement than the example you present above?
> > 
> >>Thus, the assumption probably needs to be generalized a bit, but the
> >>spirit remains the same.
> >>
> >>The reasoning is simple and has to do with uncertainty: You
> >>want to be 
> >>able to distinguish between "Alice is in place A and Bob is 
> >>in place B, 
> >>where Alice and Bob are both members of a group" from "Alice 
> >>might be in 
> >>A or B, depending on which sensor is right". We don't do the 
> >>first part 
> >>right now, but reality for a single individual includes the 
> >>second part.
> > 
> > 
> > We have the same problem for a single individual - active 
> contacts may 
> > have different locations (your cell phone is on, but you left it in 
> > your car, your office IM was recently active, but you are now in a 
> > meeting in a conference room, ...)
> > 
> >>I think there are backwards-compatible solutions for the problem you
> >>pose, but I think we should solve the single-person problem first.
> > 
> > 
> > Makes sense.
> > Dave
> > 
> > 
> > 
> >>Henning
> >>
> >>Boyer, David G (Dave) wrote:
> >>
> >>>Henning -
> >>>
> >>>In response to your first item -
> >>>We model only one person (and possibly their assistant),
> >>
> >>not groups of individuals.
> >>
> >>>This conflicts with some of the statements in Johnathan's
> >>
> >>data model paper.
> >>
> >>>Without groups, how can something like a contact center be
> >>
> >>supported?
> >>
> >>>A contact center will not want to expose specific, or even 
> general, 
> >>>information about it's agents.  Without a grouping mechanism that 
> >>>exposes available agent's basic capabilities, how will
> >>
> >>something like
> >>
> >>>a contact center be supported?
> >>>
> >>>Dave
> >>
> > 
> > _______________________________________________
> > Simple mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/simple
> > 
> 
> -- 
> Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
> Director, Service Provider VoIP Architecture   Parsippany, NJ 
> 07054-2711
> Cisco Systems
> [email-masked]                        FAX:   (973) 952-5050
> http://www.jdrosen.net                         PHONE: (973) 952-5000
> http://www.cisco.com
> 
> 

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 21 Oct 2004 17:18:29 -0400

Boyer, David G (Dave) wrote:
> an entity that is not a person. 

Right. But there is nothing that we can do anyway to prevent that; i 
can't force someone to use the <person> construct to only model a single 
person.

What has been discused so far
> - a group can represent a list of users (this is not appropriate for the

Right.

> etc.  Just seems that what we are talking about here is more than a

No, it is a person from a model perspective. That is, the watcher will 
think it is a person, and nothing in the presence document will (or 
should) clue the watcher into the fact that this person is really a 
meta-person that is merely a facade around a group of users.

I'm not sure if you are proposing rather that we change the name to 
<entity>; that is sufficiently vague to make it not clear what we are 
trying to model. We are trying to model states of a single person 
relevant for communications. Thus, <person> is the right thing.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                        FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 22 Oct 2004 08:54:49 -0400

[snip]
> The

Applying presence to call centers presents some unique challenges:

- Attempting to represent every call center agent as part of the
   presence status would generally not be considered acceptable
   to the call center management, it would present performance
   problems, and it wouldn't provide any utility to an outside
   watcher.

- as you mention, the call center can have special kinds of
   capabilities that shared equally by all the agents in the
   call center. These groupings are often called "skill groups".
   If you are going to expose the call center via presence, you
   may want to expose each skill group as a separate presentity.

- The status of a skill group can't be represented accurately
   by the status attributes currently defined. For instance
   availability vs idleness is not even close to binary - it is
   statistical - measured by something like average wait time.

In spite of these problems, I think it will eventually make sense expose 
the status of call centers via presence. But I think that can be a 
follow-on activity.

	Paul

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 31 Oct 2004 22:56:16 -0500

> relevant for communications. Thus, <person> is the right thing.

I think <person> is close enough. To use an analogy: I'm not a lawyer, 
but I believe that US law treats corporations consisting of many 
individuals in many ways like a person. From a random web page:

"A legal person is an entity that has the legal capacity to represent 
its own interests in its own name, before a court of law, to obtain 
rights or obligations for itself, to impose binding obligations, or to 
grant privileges to others, for example as a plaintiff or as a 
defendant. A legal person exists wherever the law recognizes, as a 
matter of policy, the personality of any entity, regardless of whether 
it is naturally considered to be a person. Thus, a legal person is 
distinguished from a natural person.

In the case of artificial persons, such as corporations for example, the 
"personality" of the legal person, including its rights, obligations and 
actions, is separate from any of the natural persons who participate in 
it, and is not altered by a change in their membership. Therefore, the 
natural persons who are members cannot be held fully accountable for the 
actions of the legal person."

See also http://en.wikipedia.org/wiki/Legal_person

Thus, we're really trying to represent a "legal person", not a "natural 
person" here. Since this is good enough for lawyers, this should be good 
enough for a protocol document. I won't point out that the Wikipedia 
article uses the term "legal entity", but will note that "entity" is one 
of these words like "node", "stream", "session" that has enough meanings 
without us adding one more.

Henning

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 31 Oct 2004 23:01:23 -0500

> the status of call centers via presence. But I think that can be a 

Logically, there is no reason not to add a <group> notion at some later 
point as another element in the hierarchy, by just enhancing the data 
model "on top" a bit. However, it may turn out that this grouping is 
much more similar to other groupings, such as buddy lists, that we're 
already working on.

No need to solve this now; I see little danger of constraining our 
choices by leaving this for later.