Subject: [Simple] updated presence data model

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 21 Feb 2005 09:22:38 -0500

I've submitted an update to the presence data model. Until it appears in 
the archives, you can pick up a copy at:

http://www.jdrosen.net/papers/draft-ietf-simple-presence-data-model-02.txt

This is a major revision. The biggest three changes are the split of the 
processing and data model, the allowance for multiple instances of a 
particular person, device or service, and the introduction of the notion 
of generic "reach information". Reach information includes the URI for 
the service but can also include other information that a watcher has to 
do in order to get a request to the service. I think that, from a model 
perspective, this would cover our needs for something like an "app 
launcher" as we have been discussing in another thread on enumerating 
services.

Note that the examples are not schema-validated at all (or evne close). 
We have a much bigger issue on schema alignment, which I'll post on 
separately.

Here are the specific diffs:

* split out composition and presence server processing sections,
leaving only the data model

* fixed examples, which had tuple extensions before <status>. They
need to come after

* changed terminology from person, device and service elements, to
person device and
service components, to refer to the part of the data model that talks
about person, service. This is to differentitate the XML concept of
element from the disaggregation implied by component. With this
change, it makes sense to say that there is one person component, but
there can be multiple <person> elemnents.

* added the ability for there to be multiple instances of a particular
service or device, or person. This was done by modeling the system
hierarchically. The presentity is at the top layer, followed by
devices, services and person. Within a particular device, service, or
person, there can be multiple instances. Each instance of a service
shares the same service URI, each instance of a device shares the same
device ID. Each instance is identified by an instance ID. This is
described in the document as a feature in order to explicitly model
ambiguity in cases where the compositor cannot, or doesn't want to,
resolve the ambiguity, but rather wishes for the consumer of the
document to do so. It is important to note that this means that the
reason we choose to have multiple instances of a service is ONLY
because we want to model ambiguity; it we want to explicitly say
something like "My softphone is open for IM, but not audio",
standardized ways of doing that, where the compositor or the device
knows this to be the case, are not to be done using multiple
instances. Otherwise, we are back in the boat of multiple ways of
saying the same thing.

* The spec mentions usage of timestamp and note to allow humans and
automata to resolve conflicts

* allow timestamp and note as part of person and device. Aligned
schemas for person and device to match structure of the tuple.

* Modified schemas to extract types for note and timestamp into a
common schema, which is included into the person and device schemas.

* added a section discussion general properties of documents in the
model. Emphasize that the meaning of a document is well-defined and
not based on its transport or transferrance method, and that presence
systems allow for infinite composeability.

* since a person element can have a note, and there can be a note in
the document overall, the model defines how these resolve. Its like
attributes in SDP. If a note is defined under the person itself, that
is used. If there isn't one, the document-wide one is used.

* substantially revamped definition of a service. Created subsections
to define the components of a service - characteristics, reach
inforamtion, status, relative information. Reach information includes
the URI but could include things like a software app you have to use,
or a header you have to place into your request.

* clarified that capabilities don't mean that you have to format your
request in a specific way - that is what reach information is for

* no longer reference the roach service examples draft; rather, the
ideas there are expanded upon here

* tel URI is discussed as being similar to sip, in that it can
indicate multiple services

* discuss that since reach information uniquely identify a service,
two things can't be separate services if they can't be reached
separately

* describe Aki's "available on my softphone if you use IM, but not if
you use audio" as an example of a more complex status for a single
service

* mention that capabilities for a service can be more complex than we
have today; for example eventually rfc2533.

* mention that implied behaviors on receipt of a document cannot be
assumed - everything has to be explicit

* nothing says that the service URI has to be a gruu or anything else;
from a data model perspective its just a URI that is used to access
the service. The processing model draft will give guidance on how its
filled in by PUA.

* added a treatment on the type of URI that can be included in the
service URI. There is no limit, but abstract URIs like URN and tel
mean you can't say much about characteristics. Using a tel URI with
enum dip indicator is better, or using a tel URI when there is no enum
record is better, that means its a phone number and you can say more
about it

* mention that the service URI to service mapping is many to one, and
that it is ok for service URI to change over time too. Mention that
this is useful for anti-spam and give reference to the
ietf-sipping-spam draft

* mention that the presentity URI represents a form of "one number"
communications - providing an index by which all of the other reach
addresses for a user can be discovered.

* concluded that the UUID URN was not going to work very well for us out 
of the
box, since it requires a time-based component and thus doesnt have the
characteristics of being guessable or correlatable with other
information sources in the network. As such, its listed as a fallback
option until other, better URN are defined. Also, ESN and MAC are
listed as useful identifiers but they don't have URN schemes.

* clarified that the person component represents a single individual,
and talked about how groups or users or a dog could actually be hiding
behind that person facade.

* added discussion of dealing with both pres and SIP URI; and how to
set the entity URI correctly. Discussed the more general alias issue
as well.

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

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 21 Feb 2005 17:18:55 -0500

> listed as useful identifiers but they don't have URN schemes.

As a hack to move forward, we could use a UUID that uses a specific, 
agreed-upon time (say, 01/01/2000). As long as everyone picks the same 
time, it's essentially a MAC-based identifier, at least in one of the 
incarnations of the UUID.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 22 Feb 2005 22:07:10 -0500

I asked the authors of the draft about this kind of approach some time 
back, and the feeling was that it was hokey. I think we are better off 
writing a short URN spec for a mac address. Its not a lookup mechanism; 
just an encoding for representing a mac address in URI/URN form. Should 
be a trivial document....

-Jonathan R.

Henning Schulzrinne wrote:

>> I've submitted an update to the presence data model. Until it appears 
>> in the archives, you can pick up a copy at:
>>
>> * concluded that the UUID URN was not going to work very well for us 
>> out of the