Subject: RE: [Simple] Updated RPID

From: "Dag Ekengren" <[email-masked]>
Date: Mon, 11 Oct 2004 16:01:25 +0200

>distinguishing between the 
>source of information (which element derived this information) and the 
>scope (all the elements that are affected by it)

That is then another issue that needs to be aligned with the presence
data model draft.

The presence data model draft states that:

>Each of these data elements contains information (called attributes)
that >provide a description about the service, person, or device.  It is
central >to this model that each attribute is affiliated with the
service, person, >or device because they describe that service,
presentity or device. This is >in contrast to a model whereby the
attributes are associated with the >service, presentity, or device
because they were reported by that service, >presentity, or device.

So in the presence model draft, the cell phone service would report that
you are driving using the <person> tuple, and the PDA would report that
you are in a meeting also using the <person> tuple.

This would be the case because the information applies to the person
(although it is reported by various services). It is then up to the
composition policy to decide which information should be displayed. It
could merge the information so that potentially conflicting information
is displayed to the watcher if that is the composition policy in use.

/Dag

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]] 
Sent: den 11 oktober 2004 15:17
To: Dag Ekengren
Cc: Simple WG
Subject: Re: [Simple] Updated RPID

As Jonathan noted, alignment efforts are under way. However, the issue 
you raise is somewhat more general, namely distinguishing between the 
source of information (which element derived this information) and the 
scope (all the elements that are affected by it). This becomes relevant 
if different devices may arrive at conflicting information. For example,

my cell phone service may know that I'm driving (since it can detect 
movement based on my cell coordinates), while my PDA might consult its 
calendar and determine that I'm in a meeting (which I'm actually late 
for...).

We agreed, I believe, that in many cases, only the watcher can be 
sufficiently intelligent to deal with conflicting information and thus, 
there need to be facilities for each element to report such information,

so that the watcher can determine whom to believe or just be confused. 
In some cases, a composer can merge the data and remove contradictions, 
but since the RPID format is also used for publishing, we need to be 
able to carry this information in the element that it belongs to.

Thus, activities can be reported by a (service) tuple, a person or a 
device, depending on the particular circumstances.

Dag Ekengren wrote:
> I think the relationship between the latest RPID document and the
presence
> data model document is a little unclear.
> 
> In RPID, it says that the "<activities> element describes what the
> presentity is currently doing, expressed as an enumeration of
<activity>
> elements". I think this clearly belongs to the <person> element in the
> presence data model. In the examples in the RPID draft, the activities
> element is applied to service tuples. Maybe it should be mentioned
that
> these should be used on the <person> element?
> 
> Wouldn't it be a good idea to include the definitions of <person> and
> <device> in the RPID draft?
>

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 11 Oct 2004 14:21:36 -0400

My concern is that losing source information is not desirable, as it 
makes it rather difficult for any downstream entity to decide which 
information might be more credible.

You could, presumably, add a 'source' attribute to each element as one 
alternative that preserves this information, but linkage by identifier 
is always more brittle (since you then have to make sure that there are 
no dangling pointers and that the pointers themselves do not reveal 
information, e.g., due to naming conventions).

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 11 Oct 2004 16:10:53 -0400

>  information might be more credible.

We discussed this extensively on the design team.

It was concluded that we could support the reporting of conflicting
information downstream, in later extensions, by inclusion of multipel
values for a particular element along with its source. That meant that
the baseline mode of operation was kept simple. Given the confusion
we've had all along about interpretation of data in multiple places, the
tradeoff seemed appropriate.

I, for one, strongly support this decision. I think, prior to the model,
we were on a path to failure. We clearly had a lack of agreement or
understanding on what these attributes meant and what they were saying.
No small part of that was that any data could appear anywhere. I am
reluctant to return to that. I think that consistent and coherent
information should be the baseline mode of operation, with conflicting
data and source information being an extension, something we can do later.

To be concise, Dan wrote:
> So in the presence model draft, the cell phone service would report
> that you are driving using the <person> tuple, and the PDA would
> report that you are in a meeting also using the <person> tuple.
> 
> composition policy to decide which information should be displayed.
> It could merge the information so that potentially conflicting
> information is displayed to the watcher if that is the composition
> policy in use.

Correct up to the last sentence - as above, we are not supporting, in
this current version, the ability to indicate conflicting data.

To answer Paul's original question, he wrote:
> I have a question about how the data model xml type extensions for
> <person> and <device> interact with the status and characteristic
> types defined in various places.
> 
> (This may just be a matter of my ignorance of XML details.)
> 
> The data model defines a number of abstract types. I infer that the
> only elements that are permitted as capabilities or status of person
> or device must have themselves been declared as extensions to the
> corresponding abstract type.
> 
> If that is true, then it would seem to rule out the same type being
> used in more than one of <tuple>, <person>, or <device>. This would
> minimally mean that every type defined in RPID will need to be
> revised to specify which container it is intended for.
> 
> This also means that we can't have types that are intended to be
> useful in more than one of these. (E.g. idle.)

If you want an element to be valid for both person and device, than yes, 
you would need to define it twice. You can give it the same name, and 
just use different namespaces.

I think that being crisp about its interpretation in each of the 
different components of the data model is a feature of this approach, 
not a bug. You need to EXPLICITLY make it apply to all three, rather 
than have that be the case only unless you say otherwise.

In the case of rpid, based on my pass through the -04 version, there was 
only one attribute that was plausibly valid in two places - idle, for 
either device or service. We've in fact been debating its validity for 
service in any case.

Thus, the fact that this is a problem in theory and not in practice, 
says to me that we are doing the right thing.

-Jonathan R.

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

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 11 Oct 2004 17:42:58 -0400

> just use different namespaces.

Then I gather there is no "multiple inheritance" in xml that would 
permit me to define it once as a realization of both.

But note that this kind of typing of the extension elements was not done 
in PIDF, and so it doesn't apply to <tuple>. So there is no syntactical 
restriction to my using one of the person-specific elements in a 
<tuple>. Its too late to go back and change PIDF to use the same approach.

Making equivalent extensions in two namespaces for use in both person 
and device might feel better, but semantically (and probably in 
implementation) they are different. It would be at least annoying *if* 
there were a lot of cases where this was the right thing to do.

> than have that be the case only unless you say otherwise.

I agree that there are benefits.

> says to me that we are doing the right thing.

Yes, it is a data point in that direction.

	Paul

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 11 Oct 2004 20:39:30 -0400

> We discussed this extensively on the design team.

Probably in a somewhat different context, at least from my recollection 
of the discussion.

> tradeoff seemed appropriate.

This is different. It simply includes the data with the source tuple 
that generated it. This is no more complicated than the alternative 
approach, and in the absence of a defined composition operation, almost 
unavoidable. In practice, with all existing and plausible near-term 
composition operations (which will be effectively some form of union or 
concatenation), this will occur whether we allow for this or not. It is 
fairly straightforward, for the policy rules, to define algorithms that 
take these cases into account, and work for the desirable case of no 
conflict. (For example, the "matches if all instances match" is a 
privacy-safe example of such a rule.)

This does not mean that any element type can or should contain any RPID 
element.

Indeed, if we don't allow for this now, even without the source 
identification, we may not be able to do this later, due to the policy 
rule issues, in particular.