Subject: [Simple] diffs in presence data model from previous version

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 28 Sep 2004 17:00:21 -0400

* Terminology: using "person" to refer to the human-user status (busy, in a
meeting, etc.), with presentity representing the combination of person,
device and service information

* mention that the presentity URI will often be the SIP AOR, and that
such equivalence is recommended.

* UUID URN for device ID

* mention that device IDs are ideally obtained from operating system

* clarified the role of characteristics and status information for
devices - cannot be used to determine nature of the service. Rather,
aids in the selection of service based on what the device
is. Clarified that status of a device does not affect status of the
service unless it is known otherwise.

* cleaned up document to remove references to "what is a tuple", or
"this group has had trouble" and other discussions not appropriate in
an RFC

* clarified that it is not that important to cleanly delineate status
and characteristic information.

* syntax is now using new <device> and <person> elements, rather than
re-using tuple. It was felt that this was likely to be backwards
compatible with existing PIDF implementations, whereas the previous
approach would not be. It does mean that partial publish and partial
notify specs will need to change, but they are not done yet.

* clarified that a PUA can "represent" a service, device or person,
but is usually a service, and the discussion focuses on that.

* changed definition of service, presentity and device views, based on
the fact that a presence document has to contain at least one service
tuple

* updated references and examples

* removed plan-of-action section

* clarified that privacy filtering can run at the request of the
presentity or other parties

* added dsicussion of deciding to combine a set of services together
because they provided contacts that are gruus under the same aor

* added a lot of text on overriding published information and on
time-based conflict resolution in presence servers

* removed example of helpdesk application as a case where the r-uri of
the publish is not the same as the entity field in the presence
document, since its confusing and not a good use case.
-- 
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