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

[Alex Audu <alex.audu at alcatel.com>]

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.

Jonathan Rosenberg wrote:

> 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
> jdrosen at dynamicsoft.com                     FAX:   (973) 952-5050
> http://www.jdrosen.net                      PHONE: (973) 952-5000
> http://www.dynamicsoft.com
>
> _______________________________________________
> Simple mailing list
> Simple at ietf.org
> https://www1.ietf.org/mailman/listinfo/simple


_______________________________________________
Simple mailing list
Simple at ietf.org
https://www1.ietf.org/mailman/listinfo/simple