Subject: RE: [Simple] updated presence data model

From: "Boyer, David G \(Dave\)" <[email-masked]>
Date: Wed, 23 Feb 2005 11:14:24 -0500

Jonathan,

Just curious, why was the "flow of operations" figure removed
(Figure 3 in data-model-01)?

Thanks
Dave

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Jonathan Rosenberg
> Sent: Monday, February 21, 2005 9:23 AM
> To: Simple WG
> Subject: [Simple] updated presence data model
> 
> 
> 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
> 

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 24 Feb 2005 00:23:44 -0500

The presence data model was split into two drafts:

http://www.ietf.org/internet-drafts/draft-ietf-simple-presence-data-model-01.txt
http://www.ietf.org/internet-drafts/draft-rosenberg-simple-presence-processing-model-00.txt

the latter one now contains that figure. The data model now focuses on 
the DATA - what the presence document means. The processing model 
focuses on things like composition and what a presence server does in 
its operations. We agreed, per Robert's direction, to do this split in 
order to make forward progress on the data model before figuring out 
composition and some of the harder processing problems.

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

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Fri, 25 Feb 2005 11:22:04 -0600

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

Jonathan:

This is excellent work and I think light years ahed of
its predecessor (-00) in terms of specifying the model.

Some comments follow.

1) In Section 2, it is stated that a Presentity URI is "a URI that
acts as a unique identifier for a presentity..."  However, this
seems to contradict Section 3.1: "For each unique presentity in the
network, there is one or more presentity URIs."  The model implicitly
assumes the latter anyway (see discussion in Section 3.1).

2) Should we mandate that _SIP_-based presence systems have their
presentity URIs (i.e., the URI that appears in the entity
parameter of the <presence> attribute) be sip URIs instead
of pres URIs?  What happens if a SIP-based PS is sent a document
with a pres URI?  How will it co-relate it with an existing
user in the presence system?  Section 3.1 does a good job of
covering the case where the presentity URI is sip-based, but
what if it is a pres URI?

3) In Section 3.2, a reference to rpid appears appropriate.

4) In Section 3.3.2, is prescaps one form of reach information?
If so, maybe a reference to it would help.

5) In Section 3.3.4, the last phrase of the first paragraph
appears to be too optimistic ("...and reach the desired target").
We have already taken pains to point out earlier that the
system cannot authoratatively ensure that a session will be
established with the desired target.  A quick fix is to align
that phrase by adding a "may," as in, "...and may reach the
desired target."

6) Section 3.3.4, second paragraph -- I think we are skating
on thin ice here.  In my reading of the model, this paragraph
appears to contradict the sixth paragraph of Section
3.3.2 ("Because the reach ... for a single service.").
Here's why:

In the paragraph of Section 3.3.2, we take pains to explain
that it is not possible to describe a softphone that does
audio and video as two services; it must be described as
one service.  However, in Section 3.3.4, we have a softphone
that offers two services -- audio and IM -- and can
select which of these services can be reached by deducing the
status of one service from the other.  Why can't we do the
same for the softphone with an audio and video service?

My suggestion would be to have some other example in Section
3.3.4.

Nits:

*) In section 2, under the definition of "Characteristics", the
fourth line ("A status or characteristic...") appears to be a
cut-and-paste error from -00...?

*) Define "Attribute" as "A piece of data that provides a
description about a service, person, or device."  Then,
the definition of "Presence Attribute" can simply refer to
"Attribute".

*) Section 3.3, s/Each service is/each service is

*) Section 3.3.2, s/users SIP/user's SIP

*) Same section, s/the user would/the watcher would

*) Same section, it is stated that:
     Firstly, the service in the document might actually be
     modelling a number of actual services used by the user, and
     it may not be possible to connect the watcher to a service
     with all of the characteristics described in the presence
     document.
    Does it make more sense to rephrase that as:
     Firstly, the service tuple in the document might actually
     be modelling a number of actual services used by the
     presentity, and it may not be possible to connect the
     watcher to a single instance of a service that
     simultaneously exhibits all the characteristics described
     in the tuple.

*) Same section,
    s/since a URI could/since a URN could

*) Section 3.3.3, s/the user has/the presentity has

*) Section 3.4, s/allow the user to/allow the watcher to

*) Same section, s/a *model* if/a *model* of

That's it for now.  I will send comments for Section 5 to the
end later.

Thanks,

- 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: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 28 Feb 2005 13:06:55 -0600

[Resending because I don't see it on the list archives and
  nobody flamed me for it ;-).  Not sure if it made it out
  or not]

[...]

Jonathan:

Some comments follow.

Nits:

*) Same section,

Thanks,

- vijay