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

From: "Boyer, David G \(Dave\)" <[email-masked]>
Date: Mon, 18 Oct 2004 10:44:36 -0400

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 18 Oct 2004 16:20:15 -0400

> I have a different definition for group - see next comment.

I think the model encompasses the "group that appears as one person" 
model discussed.

> statement than the example you present above?

Yes. One or two IETF discussion cycles ago, we had discussed groups 
where individual members were visible to the watcher. For example, each 
member of the group would have a tuple so that you could see what 
salesperson Alice, Bob, Carol and Dave were up to as individuals. This 
gets more complicated.

> in a meeting in a conference room, ...)

Again, there is a difference between uncertainty (one of the pieces of 
information happens to be wrong about the person, it's just hard to tell 
which one) and true being-in-multiple-places, as would be the case for a 
group of individuals.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 19 Oct 2004 21:44:26 -0400

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.

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