Subject: [Simple] New I-D: presence data model and its relationship to our presence work

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 12 Jul 2004 15:49:17 -0400

Folks,

I've just submitted an I-D on a presence data model for SIMPLE, which 
will appear shortly in the archives. Until then, you can pick it up from:

http://www.jdrosen.net/papers/draft-rosenberg-simple-presence-data-model-00.txt

This I-D is a further elaboration on the model I discussed at the 
interim, and it further analyzes the meaning of operations like 
composition, publication, and filtering as they relate to the data 
model. Composition in particular gets a lot of discussion, since its 
fundamentally about manipulating presence data, and then is intimately 
related with the presence data model. The document distills a lot of 
concepts that have been discussed over the years of this group, which 
have afaik remain undocumented (for example, Henning's pivot operations, 
and the presence server processing flow that we discussed on the list 
some months back).

After writing this, I had a lot more clarity in my mind about how all of 
our presence work fit together, and an particular, I feel that it 
answers the question of "what is a tuple" in a sufficiently clear way 
that we can have some interoperability of presence document 
interpretation across implementations.

The document proposes a concrete plan of attack for how this data model 
affects our ongoing work. Mostly its minor changes to the presence 
related documents.

I'd like to try and see if we can agree on the following points:

1. the data model makes sense,
2. the data model gives people the flexibility they need to represent 
the systems they are interested in,
3. the data model makes it sufficiently clear about what a tuple is to 
create interoperable presence systems,
4. the plan of attack makes sense given the previous 3

Comments in any of these four categories are most welcome.

I'll be starting some other threads, and in particular, responding to 
Henning's recent note, and referring to some of the concepts described 
in here as part of the discussion.

As such, the main point of this note is really to encourage people to 
please take a look at this document. At this point, I feel that we are 
really stuck on resolving this "what is a tuple" question in order to 
produce a coherent set of specs. In as much as I hope this document 
unstucks us, I think its a key part of moving forward. Please take a 
look and comment.

Thanks,
Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

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

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Wed, 14 Jul 2004 11:00:40 -0500

Jonathan Rosenberg wrote:
> Folks,
> 
> I've just submitted an I-D on a presence data model for SIMPLE
> 
[...]
> 3. the data model makes it sufficiently clear about what a tuple 
> is to create interoperable presence systems,

Jonathan:

The data model outlined in the I-D is sound, and my vote
would be that work should proceed as you outline.

I had proposed a somewhat similar model back in Jan 2003 on the
SIMPLE WG list.  In that email thread (which is very
long), I had argued for a user-centric presence model as
opposed to the device-centric one that was being used.  For
reference, please see

http://www1.ietf.org/mail-archive/web/simple/current/msg00061.html
http://www1.ietf.org/mail-archive/web/simple/current/msg00080.html

To me, a presentity has always corresponded to a human (or a
group of humans, as in a call center); it is the presence
state of the human we are trying to model, not the devices
commanded by it.  Unfortunately, in  current usage, a
presentity can be anything -- a VM server, a bot, a person,
and so on.  In think your model is closer to a presentity
being a user.

I also like your model with the three levels (presentity,
service, devices).  It is richer than the two level model
(presentity, device) I had in mind (see
http://www1.ietf.org/mail-archive/web/simple/current/msg00092.html).
Your model also provides for the composition of more fine
grained presence information.

Some other points in the I-D:

(1) You note (in Section 5) that "The terminlogy here is
confusing: we talk about the presentity as a data element
and the presentity as the entire thing being modeled..."
What if we used the term "actor" for the entire thing being
modeled?  As in, "The entity attribute in the
<presence> element is always present, and identifies the
actor described in the document."
Other terms: target, principal, addressee

(2) In Section 2 (Definitions), the primary difference
between "Privacy Filtering" and "Watcher Filtering"
appears to be who is requesting the filter to be applied.
The watcher is in the latter, and the presentity is in
the former.  While you explicitly mention the watcher
when discussing "Watcher Filtering", maybe you should
also mention the presentity when discussing "Privacy
Filtering."

(3) Page 9, s/offering a choice to the presentity/offering
a choice to the watcher/

Thanks for compiling this.  It distills in a clear fashion
a lot of ideas we have discussed on the WG mailing list.

- vijay
-- 
Vijay K. Gurbani  vkg@{lucent.com,research.bell-labs.com,acm.org}
Wireless Networks Group/Internet Software and Services
Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440
Naperville, Illinois 60566     Voice: +1 630 224 0216

---

From: Alex Audu <[email-masked]>
Date: Tue, 20 Jul 2004 18:05:42 -0500

Hello  Jonathan,

After reading your simple-presence-data-model- draft,  it occured to me that the
definition
of a presentity could be broadened out  more than it currently is to mean:

    Model of information about a  "user" whom the presence data is trying to
describe.
    The "user" could be a person, (place) or thing.  The information consists of an
identifier
    for the presentity, its characteristics, status, and capabilities.

    The only thing that is being brought out here is the "capability" part. This
describes
    what the presentity is capable of doing.  In other words, the "service" it can
render.
    A person can render a certain type of service,..and so can devices or systems,
or a place.
    For example, the hospital renders a healing service.

Any comments?

Regards,
Alex.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 20 Jul 2004 22:27:49 -0400

inline.

>     For example, the hospital renders a healing service.

I'm not really sure I follow. The rest of the presence document will 
contain information on communications services and devices, which are 
about the communications capabilities of a person. Thats what our target 
application is for presence. I don't quite see how this is extended to 
'hospitals rendering healing services'.

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 20 Jul 2004 23:59:14 -0400

Thanks for the comments, Vijay. Sorry for the delay in responding. More 
inline.

> and so on.  In think your model is closer to a presentity

The model says that there is something called a presentity, and the 
attributes we ascribe to it are ones more typically associated with a 
human user. That doesnt preclude you from trying to model a bot or a VM 
server with it. You may just find that the model comes up short. I think 
thats OK. If we tried to accurately and completely model all of the 
communications systems out there, we would never be done and never do 
anything actually useable.

> Other terms: target, principal, addressee

I tend to prefer calling the whole thing presentity, primarily because 
that is closest in alignment with the model that rfc2778 presents. I 
think that the "inside" thing currently called presentity could be 
called something else; "user" is, itself, not a bad choice, since it 
conveys the most common case.

> appears to be who is requesting the filter to be applied.

Yes.

> the former. 

Mostly. Other interested parties can provide privacy rules - the 
operator, for example, or a group. For example, my enterprise my have 
something to say about what information gets distributed.

  While you explicitly mention the watcher
> also mention the presentity when discussing "Privacy

I will add some text on who provides these filters.

> (3) Page 9, s/offering a choice to the presentity/offering

fixed, thanks.

> a lot of ideas we have discussed on the WG mailing list.

Thanks!

-Jonathan R.

---

From: Alex Audu <[email-masked]>
Date: Wed, 21 Jul 2004 12:26:49 -0500

Hi  Jonathan,

The example with the "hospital rendering healing service" may not apply to our immediate
mandate,..but the point I was trying to make was that the  notion of a presentity could
could be applicable to a much broader case if it is realized that a presentity could
represent
a person, place or thing (sort of like a noun).  Now,  an object (both animate and
inanimate)
has a capability attribute. This is nothing more than the service the object can render.

So we have: A  Presentity contains the following attrributes:
  - characteristics (hard state info)
  - Status (dynamic/soft state info)  (including activciy, mood, location, etc)
  - Capability (service it can render)

I am just curious as to what effect, if any, this has on the ongoing debate about service
and
device.

Regards,
Alex.