Subject: [Simple] comments on RPID

From: Rohan Mahy <[email-masked]>
Date: Wed, 2 Mar 2005 19:15:59 -0800

Hi,

I just gave a fresh read to rpid-05 and have a number of comments and 
suggestions.

General Comments:
Table 1 is a nice feature.  I would add (non-normatively) cipids, 
servcaps, and devcaps to the table for the convenience of implementers

I am a bit unclear where the normative root of the pidf schema belongs. 
  The current organization is a nightmare for implementors. I'm assuming 
the intent is for the presence-data-model to be the root of things, but 
the text did not seem to specify this.

values with free-text and semantic data should have tags instead to 
handle the same semantics in multiple languages.  for example if i set 
the sphere to <home/> I should be able to set this in a Japanese GUI 
and have a friend see it semantically in Portuguese.  If someone puts 
in something unregistered, that's fine, just put in free text.
I think this is a problem with activity, mood, sphere, relationship, 
and possibly service-class

In the person and tuple tags it would be useful to add an 
"input-source" element indicating if a human or automata generated the 
markup.

I think we *really* need a way to associate person data with the tuples 
that contributed it.  I suggest a list of contributing-tuples in each 
person element.  Otherwise, there is no way to intelligently tie 
ambiguous presence data about a person to the service(s) that provided 
it.  For example, I may want to ignore the person information from a 
service running on my home PC when I am travelling at IETF.  (for 
example if I leave my home PC on and another family member uses the 
computer).  The presence compositor doesn't know how to handle this 
ambiguous data, but a human might, *IF* they can associate the faulty 
presence data with the service(s) that contributed it.

Many values could use an explicit "unknown" value to override an 
explicit value somewhere else.  (I explicitly want to override some 
piece of presence data that became stale).

I think we really want the note and activity fields to work in an 
interoperable way.  I have no clue how to begin to intelligently 
resolve a note and an activity, or merge 2 arrays of activities.  Even 
as a human, I can construct two different activity arrays that have 
very different semantics (both reasonable) when merged one way vs the 
other.  I know the overall approach is that we are not specifying 
merging algorithms, but this one looks like it is asking for trouble.

Wherever we provide URIs (status-icon, and cipids) we have a potential 
content indirection attack.

Comments about characteristics:
I would add to <activities>:
presenting: giving a presentation, lecture, or formal round-table 
discussion

i'm completely unclear what "class" is supposed to convey.

I think <device-id> really belongs under <tuple>.  The text indicates 
this, but the table and schema do not.  Also, I think the device-id 
MUST always be a urn and SHOULD be UUID URN.  this is consistent with 
the instance parameter used in GRUU.

I think <place-is> should have separate audio, video, and text elements 
to encourage orthogonality.
	video: toobright, toodark, ok, unknown
	audio: tooloud, tooquiet, ok, unknown
	text: toouncomfortable, notappropriate, ok, unknown

I have several proposed additions to <place-type>
cycle: in or on a motor or human-powered cycle
classroom: in an academic classroom or lecture hall
prison: in a prison, jail, brig, or criminal mental institution
hospital: in a hospital, medical clinic, or mental institution
bar: in a bar or cafe
club: in a dance club or discotheque
underway:  in a land, water, or air craft which is under way (in motion)

i think <sphere> may more appropriately belong in <tuple> than <person> 
in some cases.  i propose that it is allowed in either.

there is a potentially half or full duplex nature to privacy  (ex: a 
speaker phone), but I am not sure this needs to be included.

for <relationship>  I would add "friend" to the list.

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 04 Mar 2005 20:35:47 -0500

[responding in parts]

> presenting: giving a presentation, lecture, or formal round-table 

Added.

> i'm completely unclear what "class" is supposed to convey.

It's a free-form label that allows the publisher to convey information 
to the PA, e.g., for selection, grouping or filtering. It is not 
generally meant to be rendered to a human user.

> this, but the table and schema do not.  Also, I think the device-id MUST 

Bug; fixed in the table.

> always be a urn and SHOULD be UUID URN.  this is consistent with the 
> instance parameter used in GRUU.

Changed.

>     text: toouncomfortable, notappropriate, ok, unknown

Changed; roughly in that way.

> hospital: in a hospital, medical clinic, or mental institution

Separated; I don't think you would appreciate being shown as placetype 
'bar' as you're ordering your tall capuccino at Starbucks at 10 am.

> in some cases.  i propose that it is allowed in either.

Can you describe such cases?

> speaker phone), but I am not sure this needs to be included.

I'd rather omit this for now.

> for <relationship>  I would add "friend" to the list.

Added.

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 04 Mar 2005 20:45:33 -0500

[Replying in bits and pieces to keep message sizes in check.]

> servcaps, and devcaps to the table for the convenience of implementers

Wouldn't it make more sense to add these tables to the respective drafts?

> the text did not seem to specify this.

I'm looking forward to the schema discussion next week to get this mess 
cleaned up a bit.

> the sphere to <home/> I should be able to set this in a Japanese GUI and 
> have a friend see it semantically in Portuguese.  If someone puts in 
> something unregistered, that's fine, just put in free text.
> I think this is a problem with activity, mood, sphere, relationship, and 
> possibly service-class

These are indeed all meant to be tags. Some of the examples need to be 
cleaned up to reflect this.

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 04 Mar 2005 20:59:04 -0500

[more responses]

Rohan Mahy wrote:

> In the person and tuple tags it would be useful to add an "input-source" 
> element indicating if a human or automata generated the markup.

If we can keep it simple, this would indeed be helpful for composition. 
There are probably two types of information:

(1) a rough classification of the source ("manual", "calendar", 
"sensor", "composed"), either as an attribute or as an element:

   <derived-from><calendar/><derived-from>

(2) a more detailed labeling of the source, primarily meant for 
composers (e.g., "sensor17" or "Outlook").

We had previously, I believe, discussed this as future work. I'd rather 
avoid delaying the completion of this draft if this discussion turns out 
to be lengthier.

Henning

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 04 Mar 2005 21:16:31 -0500

> presence data with the service(s) that contributed it.

This assumes that service tuples provided the person information. That 
is not likely to be generally true. For example, calendar information 
would not be associated with a <tuple>, nor would other sensors that 
might feed into the compositor.

Wouldn't this best be handled as part of the source identification (see 
separate message)?

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 04 Mar 2005 21:30:14 -0500

[final response]

Rohan Mahy wrote:

> interoperable way.  I have no clue how to begin to intelligently resolve 
> a note and an activity, or merge 2 arrays of activities.  Even as a 
> human, I can construct two different activity arrays that have very 
> different semantics (both reasonable) when merged one way vs the other.  
> I know the overall approach is that we are not specifying merging 
> algorithms, but this one looks like it is asking for trouble.

Can you give examples?

Clearly, there's the potential for interesting compositions. One would 
hope that combinations like

<activities>
   <steering/>
   <sleeping/>
</activities>

are rare, for example. But I don't see how this differs significantly 
from merging problems that can occur with other elements.

---

From: Rohan Mahy <[email-masked]>
Date: Sat, 5 Mar 2005 11:33:18 -0800

On Mar 4, 2005, at 17:35, Henning Schulzrinne wrote:
>> i think <sphere> may more appropriately belong in <tuple> than 
>> <person> in some cases.  i propose that it is allowed in either.
>

Sure,  I have a presentity URI (single person) for which I have several 
services providing presence data.  Some of them are acting in a work 
context and others in a home context.

thanks,
-rohan

---

From: Rohan Mahy <[email-masked]>
Date: Sat, 5 Mar 2005 11:44:43 -0800

On Mar 4, 2005, at 18:16, Henning Schulzrinne wrote:

> Rohan Mahy wrote:
>
>> I think we *really* need a way to associate person data with the 
>> tuples that contributed it.  I suggest a list of contributing-tuples 
>> in each person element.  Otherwise, there is no way to intelligently 
>> tie ambiguous presence data about a person to the service(s) that 
>> provided it.  For example, I may want to ignore the person 
>> information from a service running on my home PC when I am travelling 
>> at IETF.  (for example if I leave my home PC on and another family 
>> member uses the computer).  The presence compositor doesn't know how 
>> to handle this ambiguous data, but a human might, *IF* they can 
>> associate the faulty presence data with the service(s) that 
>> contributed it.
>
> Wouldn't this best be handled as part of the source identification 
> (see separate message)?

Your proposal doesn't address my use case above.  Two sources of 
ambiguous data could have the same source classification (ex: sensor, 
or manual).  This doesn't help the compositor. Then the source reported 
in the composed document has the source classification of "composed".  
This doesn't help the client.

To be clear, I am proposing a list of contributing sources.  Its 
semantics are that the following tuple tags in this document 
contributed to the data in this person element.  Other sources may or 
may not have contributed, but these definitely did.

one more below...

Henning also wrote:
>> "input-source" element indicating if a human or automata generated 
>> the markup.
>
> If we can keep it simple, this would indeed be helpful for 
> composition. There are probably two types of information:
>

i like this, and i think it should be included, but I think it is 
orthogonal to the problem I describe above

thx,
-r

> We had previously, I believe, discussed this as future work. I'd 
> rather avoid delaying the completion of this draft if this discussion 
> turns out to be lengthier.
>
> Henning

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 05 Mar 2005 14:55:26 -0500

> context and others in a home context.

This sounds like the home vs. business phone distinction?

I think there are really two somewhat distinct concepts here:

(1) A service (or possibly device) is located in a home or business 
environment. This would be indicated by the 'class' identification in 
the callee caps/prescaps environment.

(2) Whether the human is currently thinking of himself wearing his work 
cap or his off-the-clock/home/leisure cap, for example. This doesn't 
necessarily depend on my service - my cell phone, for example, may well 
be used for both and a home office phone service might also serve both 
spheres.

Henning

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 05 Mar 2005 15:13:02 -0500

Rohan Mahy wrote:
> ambiguous data could have the same source classification (ex: sensor, or 
> manual).  This doesn't help the compositor. Then the source reported in 
> the composed document has the source classification of "composed".  This 
> doesn't help the client.

The second part of the source description (that you clipped) identifies 
the source. I just don't think that we can count on the source for 
<person> information being any of the other <tuple> or <device> tuples 
in the document.

Also, how would you identify or reference calendar information or 
information provided by non-device sources, such as the BlueTooth beacon 
in Starbucks that announces the location and the place-type "cafe"?

> semantics are that the following tuple tags in this document contributed 
> to the data in this person element.  Other sources may or may not have 
> contributed, but these definitely did.

I can see this for device tuples, but that does seem to be the same that 
I had proposed as part of source identification (as part 2 of that 
labeling).

> orthogonal to the problem I describe above

This should probably be an attribute for each element, as this 
information can differ across elements in the same <person>, for 
example. (E.g., time-offset is probably derived automatically, while

---

From: Rohan Mahy <[email-masked]>
Date: Mon, 7 Mar 2005 09:55:12 -0600

It is not necessary to solve all problems of source identification to 
address one of them.

On Mar 5, 2005, at 14:13, Henning Schulzrinne wrote:
>> or manual).  This doesn't help the compositor. Then the source 
>> reported in the composed document has the source classification of 
>> "composed".  This doesn't help the client.
>
> The second part of the source description (that you clipped) 
> identifies the source. I just don't think that we can count on the 
> source for <person> information being any of the other <tuple> or 
> <device> tuples in the document.

you are right, you can't.  and i'm not asking for that.  i'm saying 
that  *IFF* the source is a tuple, that you provide this information.  
that's all.

thx,
-r

> information provided by non-device sources, such as the BlueTooth 
> beacon in Starbucks that announces the location and the place-type 
> "cafe"?
>
>
> I can see this for device tuples, but that does seem to be the same 
> that I had proposed as part of source identification (as part 2 of 
> that labeling).
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 07 Mar 2005 11:37:42 -0500

If we can agree on this minimalist model, I'm happy to add two 
attributes to each element, as in

<activities derived-from="device" device-id="URN">
   ...
</activities>

As Jonathan points out, we need to ship, so if this requires a long 
discussion, this is a good indication that we don't understand the 
problem well enough to include it in this iteration.

---

From: Rohan Mahy <[email-masked]>
Date: Mon, 7 Mar 2005 11:27:13 -0600

Henning,

What I am specifically proposing is a "contributor" sub-element to the 
person element that can contain a service URI that contributed to this 
person element.  There can be more than one of these. Other services 
and other non-services which contributed might not be included in this 
list (and that is ok).

<person>
    <activities>...</activities>
    <sphere>work</sphere>

    <contributor>sip:serviceA@somewhere</contributor>
    <contributor>sip:serviceC@somewhereelse</contributor>
</person>

thx,
-r

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 07 Mar 2005 13:37:39 -0500

> person element.  There can be more than one of these. Other services and 
> other non-services which contributed might not be included in this list 
> (and that is ok).

As I briefly noted in passing earlier, this is unlikely to be helpful if 
different sources contributed to one particular (composed) <person> 
element. Thus, my simple attribute proposal, which allows to maintain 
this source identity across composition, in the common case that 
different facets of the <person> are arrived at from different sources.

I don't see what the recipient would do with the <contributor> element.