Subject: [Simple] updated data model draft

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 18 Jul 2005 04:27:28 -0400

Folks,

I've just posted an update to the presence data model. This update 
reflects conclusions from last meeting, discussions since then, and 
results from the schema alignment activity. Until the draft appears in 
the archives, you can pick it up from:

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

Changes:

* updated schema, consistent with rpid-07 [validated by XML Spy 2005 Rel 3]

* mention that documents created MUST be valid, but entites that
receive them aren't expected to validate them, and SHOULD be prepared
to expect invalid ones

* IANA registrations for namespace and two schemas

* the <status> element was removed from <person> and <device> because
there was no clear line between a status and characteristic, and
allowing presence attributes to appear in two different places seemed
like a recipe for interoperability problems. The data model draft
still talks about both status and characteristics, but a section has
been added that indicates that this distinction is conceptual and only
useful as an aid for understanding

* added a section that discusses the interpretation of a lack of a
presence attribute - follows the rfc3840 model, where it means you
cant draw a conclusion. Similarly, the draft recommends including as
many presence attributes as possible.

* changed from the term "instance" to "occurrence" to avoid confusion
with gruu. As a result, each occurence of a person, device or ID is
said to have a unique occurence id.

* added a paragraph describing the difference between gruu instance ID
and occurrence ID

* updated UUID reference to RFC4412, and added a little more
discussion on its usage, clarifying that future specs will provide
better device ID URNs. Added discussion on MAC address as a device ID,
pros and cons.

* added a paragraph on how devices can have no services, and why this
may still be useful

* updated example, validated with rpid and prescaps

* added discussion of namespaces and document extensibility
-- 
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, 18 Jul 2005 10:37:02 -0400

> useful as an aid for understanding

If the concept isn't really translated into visible protocol behavior, 
how is this useful to an implementor?

My concern is conceptual complexity - the more philosophical concepts we 
discuss, the longer documents get, the more confused the 
non-SIMPLE-in-crowd gets and the less likely we are to see deployments.

> better device ID URNs. Added discussion on MAC address as a device ID,

I continue to be concerned that the two most common devices today don't 
have an identifier story. As far as I can tell, neither (non-WiFi) cell 
nor landline phones can usefully generate UUIDs since they don't have 
MAC addresses.

Henning

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 18 Jul 2005 11:34:52 -0400

> nor landline phones can usefully generate UUIDs since they don't have 

I don't understand this issue. Neither of those devices are going to be 
reporting their own presence status - they are going to be depending on 
something else to report on their behalf. Whatever is reporting on their 
behalf can make up some device id to use for the purpose.

Or is your concern that there will be multiple sources attempting to 
report presence status on behalf of one of these devices, and no good 
way to correlate those?

I can't seem to retrieve RFC 4412. I think the proper number is 4122. 
(Is somebody becoming dyslectic?)

Once upon a time I did propose that we permit an arbitrary URI as an 
instance-id, but this was shot down.

Looking at 4122, there is provision for generating name-based UUIDs 
based on names in some "name space". One form that is covered  by that 
is "Name string is a URL". So that could be used to generate a UUID from 
a TEL URI. However for that to work well there would have to be some 
canonicalization regarding how the tel uri was represented - e.g. use of 
separator characters.

	Paul

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 18 Jul 2005 14:47:41 -0400

> behalf can make up some device id to use for the purpose.

Certainly - it just would be nice to have a mechanism that minimizes 
collisions.

> report presence status on behalf of one of these devices, and no good 

Less so. Just multiple publishers for these "imported" devices (one 
publisher for each, but a different publisher for the landline phone and 
the cell phone).

> canonicalization regarding how the tel uri was represented - e.g. use of 

I think there are multiple ways to do this, but leaving this completely 
to the imagination of the implementor seems likely to lead to things like

device:1234

or other random things that may or may not be unique.

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 18 Jul 2005 19:40:21 -0400

Henning Schulzrinne wrote:
>>
>> I don't understand this issue. Neither of those devices are going to 
>> be reporting their own presence status - they are going to be 
>> depending on something else to report on their behalf. Whatever is 
>> reporting on their behalf can make up some device id to use for the 
>> purpose.
> 

Well, if that is the only concern then I think we can just leave it up 
to the applications. As long as they follow 4122 regarding construction 
of valid UUIDs there should be no big problem with collisions.

If they can't follow the rules there I doubt more rules somewhere else 
will help. There needs to be a better reason to be more normative.

>> is "Name string is a URL". So that could be used to generate a UUID 
>> from a TEL URI. However for that to work well there would have to be 
>> some canonicalization regarding how the tel uri was represented - e.g. 
>> use of separator characters.
> 
> I think there are multiple ways to do this,

Yes. And that is a problem if we expect multiple publishers of presence 
status for the same device. IF we expect that then it is worthwhile to 
come up with a recommendation on what do do.

> but leaving this completely 

AFAIK it isn't a valid URI unless the scheme is registered and it 
conforms to the syntax of that scheme.

So while we can't count on people not doing the above, we can hang them 
out to dry when we discover they have.

	Paul

---

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

> will help. There needs to be a better reason to be more normative.

We can go a teeny step further; if, for now, we are not concerned about 
correlations, and all we want is uniqueness, we can recommend usage of 
version 4 UUID, which do not require a mac or a registered namespace.

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 25 Jul 2005 17:14:15 -0400

> non-SIMPLE-in-crowd gets and the less likely we are to see deployments.

Its a question of whether the discussion is helpful to aid in 
understanding, or not. YMMV, I suppose. It seems that there has been a 
lot of confusion about what presence data is and isn't, which is why the 
model document was written. As such, a thorough treatment of the kinds 
of things that might be presence, and why they are useful, is in order. 
Rather than lumping all such presence data into one bucket, the draft 
splits it out into various types. I think that aids in comprehension.

-Jonathan R.