Subject: [Simple] updated data-model I-D

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 23 Aug 2005 01:32:16 -0400

I've submitted an update to the data-model spec, which includes 
conclusions from the last IETF meeting. Until it appears in the 
archives, you can pick it up at:

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

One discrepancy, however, between the minutes and my recollection. The 
minutes say:

Issue 4: PIDF-LO integration: Proposal to keep definition of PIDF-LO 
encapsulation out of data model spec. Argued that this makes for a lot 
of documents to read in order to get an implementation. General 
consensus on proposal.

I actually recall that Henning argued against this, and the conclusion 
was to just put words in. So I did. See below for the specific text.

Here are the changes:

* Added recommendation to use version 1 UUID for devices with a MAC,
version 4 UUID for those without

* added discussion of aliases as part of the section on the person
data element, as it is proposed that aliases would be a property of
the person data element.

* updated schema definition, renaming fromUntil to sinceUntil

* added text on incorporating <geopriv> objects. The text reads:

<t>
<xref target="I-D.ietf-geopriv-pidf-lo"/> defines the &lt;geopriv&gt;
XML element for conveying location information, and indicates that it
is carried as a child of the &lt;tuple&gt; element in a PIDF
document. <xref target="I-D.ietf-geopriv-pidf-lo"/> was developed
prior to this specification, and unfortunately, its recommendation to
include location objects underneath &lt;tuple&gt; runs contrary to the
recommendations here. As such, implementations based on this
specification SHOULD include &lt;geopriv&gt; location objects
as part of person and device components of the document, but SHOULD be
prepared to receive presence documents with that object as a child to
&lt;tuple&gt;.
</t>

* added text clarifiying garbage in/garbage out issue for compositors:

<t>
Presence documents created according to this model MUST be valid, with
the following exception. A compositor is permitted to create a
presence document which it cannot fully validate but which otherwise
validates when processed according to the lax processing rules allowed
by the schema of the compositor.  However, it is not expected that
entities receiving these documents would perform schema validation,
rather, they would merely access the information from the document in
the places they were expecting it to be. Implementations
SHOULD be prepared to receive documents that are not valid, and
extract whatever information from them that they can parse.
</t>

Also, as mentioned in the minutes and recently on the list, an update to 
rpid is needed to remove the <deviceID> definition and to use the new 
definition of sinceUntil.

I also checked in the schemas I used for common-schema.xsd and 
data-model.xsd into the subversion repository.

I believe we can now go to WGLC on this document.

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: Sun, 28 Aug 2005 19:51:11 -0400

> was to just put words in. So I did. See below for the specific text.

Indeed - the wording of the minutes makes little sense, as the second 
sentence directly contradicts the first one.

I think the full discussion went something like this:

- We need to tell people how to use PIDF-LO within the data model, as 
the current PIDF-LO draft is silent on this topic and only defines its 
position by example - which unfortunately puts it exactly in the wrong 
place by the logic of the data model. (PIDF-LO predates the data model 
work although it hasn't emerged from AUTH48, apparently.)

- We could write another draft that just addressed this question.

- But that would add yet another document that an implementor has to 
find and read [while the data model document currently serves as a good 
first document and substitutes for an architecture document].

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 30 Aug 2005 11:31:05 -0400

So, given that we are agreed on adding some text, does the text below 
work for you?

-Jonathan R.