Subject: [Simple] comments on rpids-01

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 26 Jun 2003 04:48:22 -0400

I have some comments about the new version of the RPIDS draft. I definitely
appreciate that the capability stuff has been removed from the document - I
think it will makes the scope of this draft more manageable in the short
term. Since this is my first really close reading of the document since
before the -00 came out, I'm sure I comment on many things here are not new
to this -01 version. 

I am still mindful of our chartered short-term goal to identify and/or
provide all of the components necessary to build a commercial IM & Presence
system. RPIDS is a collection of relatively diverse elements, and still
incorporates many things that go beyond that goal, I think. To me, the note
in 6.1, "it is highly unlikely that a presentity will publish or announce
all of these elements at the same time", highlights the fact that many of
these elements could be in separate extensions without interdependencies - I
would prefer if smaller collections of related elements could be used in
PIDF instances without importing the whole of RPIDS. In short, rather than
having a monolithic entity called RPIDS, I'd rather have a collection of
smaller, more tactical XML schemas that extend PIDF towards specific goals.
I don't think any of the current RPIDS elements are technically specific to
SIP, and thus they might play well with other extensions to PIDF that could
be developed inside or even outside of the SIMPLE WG.

I think the core elements in this document, the ones that address our most
important requirements, are <category> and <idlesince>. Both are currently
fine by me, although I'm a little unsure if 'category' is the right name for
something that describes 'what the presentity is currently doing'. I
actually think the term 'activity' is a much better name for this, and since
I'm not sure the element currently named 'activity' is necessary, maybe this
could be reused instead of 'category'. Even if not, I think we need an
element name that is a bit more explicit than 'category' - 'doing' or
something like that.

<contact-type> is hard for me to comment on, since the need for this
parameter is fundamental to the current controversy about how tuples should
be understood, and whether or not watchers need some indication of the
intention of the constructor of a tuple. If it turns out that this is
necessary, then we need <contact-type>, yes. On another naming point, I
wonder if 'contact' doesn't imply that there's a contact address, which of
course not all <tuples> will contain.

Speaking of <contact-type>, I would either remove or further motivate the
<class> element. I'm not sure what the relationship between <class> and
<contact-type> is supposed to be. The motivation given in the Intro for
class is:

   We add an <class> element (Section 6.6) that labels each
   tuple as being a presentity, a group of presentities or a device.

... but Section 6.6 is where <contact-type> is defined, and <contact-type>
has this description, not <class>. <class> is essentially unqualified, given
its description in Section 6.5. I also note that <contact-type> is not used
in any of the examples, but that <class> is used in the examples in a
roughly similar way to how I imagined <contact-type> would be used. 

There are a number of elements in RPIDS that represent predictive or
calendrical presence information - <time-status>, <until>, and I think
<from>, in so far as <from> differs from the baseline PIDF <timestamp> (and
following the mention of <from> in 6.16). While I can see the value in
specifying these, I'd like to suggest that they should be outside the scope
of our initial work here in SIMPLE. First of all, it is debatable to what
degree calendar information is presence information. Moreover the precedence
and interaction between calendar or predictive information and real-time
publication might give rise to new problems. This is not a feature that I
currently see in a lot of commercial instant messaging applications. I think
that this would be a good separate extension to PIDF, that could be
imported/supported as necessary. I'd like to suggest that this be broken off
into a separate document that provides calendaring/timing extensions to
PIDF.

<card> and <icon> are, I think, not presence information as such.
Icon-sharing is common in instant messaging applications, but there are
other ways in SIP (like Call-Info) to share an icon (I'd further note that
the IM applications with which I have experience display user-provisioned
icons only when a messaging channel is opened, etc). There is an argument to
be made that vCard should be included, since it is mentioned in RFC2779 (Req
3.1.6) and not included in PIDF, but even in this turbulent economy, my
business card doesn't change enough that I would consider it to be real-time
communications info. I think that for the time being, there isn't any
pressing motivation to put these features into PIDF to complete our work
here. If need be, I'd recommend incorporating them as one or more separate
PIDF extensions.

Though I like <idlesince>, I'm less sure about <activity>. In response to
the motivation given in 6.2, if a computer doesn't have a keyboard or mouse,
it should be publishing a state of CLOSED; we don't need <activity> to
supplement this. Similarly, if I see the word 'active' in presence, I would
assume that the presentity is around (and thus perhaps ready to communicate)
- perhaps not what I should assume if they are on the phone. If someone is
totally idle (at a threshold judged by the watcher), they could derivately
be considered inactive - that's the quality that we really need here; the
only difference that <activity> introduces, I think, is that the presentity
rather than the watcher makes the judgment call of activeness based on that
idleness timer. But then again, the presentity still always gets to choose
the threshold at which it starts including an <idlesince> element. Finally,
commercial instant messaging systems don't tell me, for example, that a
presentity is currently conversing with two other IMers (which would
presumably be the corollary of <activity> for IM), so I'm not sure I see
this sort of activity as being something we immediately need for our
short-term goals.

<privacy> and <placetype> seem to be similar to one another - they convey a
sense to watchers of how appropriate various kinds of communication might be
given the environment of the presentity. Since the value of these elements
can be free text (i.e. arbitrary), it's hard for me to see why <note>
doesn't suffice to express these values - an automaton shouldn't be keying
off a free text field, and moreover, an automaton isn't going to supervise
your IMs (or speech) to determine whether or not what you're saying is
appropriate to the presentity's placetype. Moreover, choosing between
'home', 'office' and 'public' doesn't really seem to give a reliable
indication of what kinds of communication might be appropriate. Similarly, I
might consider this laptop 'private' until somebody walks up and looks over
my shoulder - but I'm not always going to change my presence to reflect that
condition. In short, I have a hard time seeing how useful these would really
be, and I see no reason why a <note> to the same effect wouldn't be just as
useful.

I'm unsure about <relationship> because it encourages presentities to
publish their presence under another entity's AoR (and for compositors to
accept such publications) - given that this would include family members,
associates, and the like, it seems to give rise to fairly complicated
authorization logic in compositors. I wonder, though, if there aren't other
solutions to this problem - like, giving out a group alias as your AoR, or
something, that includes any other persons whose presence is 'equivalent' to
yours as necessary. It seems weird to include presence information in a
<presence> document that doesn't below to the resource identified by the
'entity' attribute of the <presence> document. Most importantly, I'm not
sure that this is very backwards-compatible with baseline PIDF - if you
don't understand the <relationship> element, you might be unpleasantly
surprised when you IM one of the contact addresses in the associated
<tuple>. I agree that something that provides this capability (associating
presence from one party with that of another) would be useful, but I'm not
sure that it should be done as a PIDF extension.

I think that from the conclusion of our discussion of tuple composition, we
should remove <label> - it is redundant with tuple-id. It is easy to say, as
a part of publication spec, that tuple IDs are constant across publications,
which would in turn make them constant across subscriptions.

I would remove <info> - if <note> from baseline PIDF doesn't suffice for
this, I'm really missing something here. <info> would provide an alternative
that would not be compatible with baseline PIDF. I don't think the advantage
that it offers a URL to a web page is, in itself, sufficient justification
not to use <note> instead. Just put your URL in the <note>.

Smaller things:

The convention, mentioned towards the end of Section 2, that a tuple with no
contact address signifies face-to-face communication - is that left over
from a previous version, or was it intended to be left that way? I don't
recall this being the final consensus on the matter.

The Abstract still includes capability as one of the functions of RPIDS, as
does the end of Section 2 and the whole of Section 3.

Though I don't recommend retaining the <relationship> element, I note that
in the current example in 7.1, it is outside of the <status> element,
although 6.1 lists <relationship> as extending <status>.

Also, there seems to be an extraneous paragraph at the end of 6.14.

And, <members> is still mentioned in the schema and in 6.1.

The first sentence of the Intro misspells 'information'.

Finally, the mention of SIP priority values in the middle of Section 2
doesn't seem to connect with anything given in the remainder of the doc.

- J

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 26 Jun 2003 22:38:26 -0400

> actually think the term 'activity' is a much better name for this, and since

The name <category> is inherited from calsch. I'm fine with either.

> element name that is a bit more explicit than 'category' - 'doing' or

In the interest of clarity, I'll change to 'activity', as that does 
indeed seem more descriptive.

> course not all <tuples> will contain.

This is indeed a placeholder until the discussion has been completed. My 
inclination at this point is to get rid of it, given the semantic 
difficulties in distinguishing them that can only be entertaining to 
lawyers. (If my family sometimes answers my phone, is my address a 
group? If I only have one device, is it a device or a presentity? If an 
address represents two devices, should be it be labeled as a device? Etc.)

Also, as became clear during the tuple discussion, it seems unobvious 
what a watcher would reliably do differently by knowing this information.

>    tuple as being a presentity, a group of presentities or a device.

This is an editing error. Contact-type used to be called <class>, but 
<class> is now a much looser description, with labels chosen by the 
presentity, but not in any way standardized (except by convention 
between the presentity and scripts run by the presentity). This allows a 
presentity to label things for, say, filtering and access control. For 
example, a presentity could label all 'public' information as 'public', 
and then have a filter in the PA that restricts all other information. 
Or label things that represent a particular view. Or whatever else makes 
sense to the presentity. As I mention in the text, the closest analogy 
is the class parameter in HTML, which associates rendering (CSS) 
information that is common among a set of elements. (HTML also has the 
equivalent of the tuple id, with uniqueness-within-document semantics, 
by the way.)

> roughly similar way to how I imagined <contact-type> would be used. 

I'll add additional motivation. Hopefully, once the editing confusion 
disappears, this will be somewhat clearer.

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 26 Jun 2003 22:38:26 -0400

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 26 Jun 2003 22:44:53 -0400

> into a separate document that provides calendaring/timing extensions to

Extending what Brian and others have remarked, I don't think the 
division is as clean as you make it out to be. Most of the information 
in presence can be envisioned as being generated by things that look 
like calendars (or other sensors, such as a passive infrared sensor that 
detects whether I'm in my office, an active badge reader, etc.).

I don't think we should try to restrict or limit the source of 
information as to whether it is generated by sensors, a human, somebody 
acting on behalf of another human or software. All of these are subject 
to various errors and deliberate obfuscation. As in Sherlock Holmes, the 
inconsistencies in your alibi will give you away...

Even the <time-status> information could be generated manually be a very 
conscientious secretary (or a person that's sufficiently bored in the 
meeting), without the aid of a calendar.

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 26 Jun 2003 22:44:53 -0400

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 26 Jun 2003 22:56:06 -0400

> this sort of activity as being something we immediately need for our

The idea is to provide additional, automatically derivable, indication 
of liveness. Current systems (like Windows Messenger) change the 
activity indication to 'idle' if you don't use your keyboard or mouse. 
However, that's at best a guess (you might just be talking to a 
colleague in your room, so you're hardly "idle"), and overloads an 
indicator with two meanings that are not orthogonal.

A device that is 'idle' can be either OPEN or CLOSED - it just provides 
an additional hint to the watcher as to why nobody writes back when I 
type. (MS Messenger puts up some kind of message saying that the other 
side may not respond, I think.)

If I recall the discussion correctly, <activity> was seen as a "less 
revealing" form of <idlesince>. Thus, they share the same motivation, 
but <activity> allows a presentity to indicate lack of activity without 
revealing how long I've not been using the device.

Maybe a simpler, less confusing, way of coding this is to simply allow
<idlesince> to be empty, indicating that I am indeed 'idle', but I won't 
tell you for how long. Would that be clearer?

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 26 Jun 2003 22:56:06 -0400

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 26 Jun 2003 23:17:38 -0400

> not to use <note> instead. Just put your URL in the <note>.

I dislike having to guess, email-reader-style, what are URLs and what's 
plain text by do regular expression matching. With the info URL, a 
watcher can automatically underline the presentity name as a link, for 
example. Can't do that with <note>. In general, I'm trying to have 
semantically labeled information, so that watcher or other elements 
don't have to do natural language processing. This also makes filtering 
a whole lot easier. I can much more readily remove information as a 
watcher and as a presentity if it is labeled by category rather than 
being all piled into one catch-all field. As an example, if my bandwidth 
is such that I really don't care about anything but the bare basics, I 
would strip the <card>, <info>, <activity>, etc. in my subscription 
filter, but <note> seems like something that has to remain since it 
likely conveys special information that I need to know.

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 26 Jun 2003 23:06:02 -0400

> doesn't suffice to express these values - an automaton shouldn't be keying

That's not true. With a "reserved words + additional words", an 
automaton can check for the reserved words and treat "free text" as 
'default' or 'other' or 'unknown'. This is not possible with a <note> 
field which not only has no defined meanings, but probably incorporates 
a range of information that has nothing to do with placetypes or privacy.

> appropriate to the presentity's placetype. Moreover, choosing between

I don't understand. This is an indication to the watcher. We have a lab 
prototype that uses BlueTooth to convey the <privacy> and <placetype> 
information to devices that are in the room. Works very nicely; my 
office indicates 'office' and 'private', my lab 'office' and 'public', etc.

> indication of what kinds of communication might be appropriate. Similarly, I

It provides one useful indication in that many people explicitly don't 
want to receive certain calls at home (office dalliance) or at work 
(medical appointment with psychologist) or when they are in a public 
place (both).

> be, and I see no reason why a <note> to the same effect wouldn't be just as

As with all of these, these are approximations that are useful even if 
they are right only most of the time. Cellphone profiles indicate, as 
noted, that people do use this type of information, probably set as a 
cluster, rather than parameter-by-parameter.

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 26 Jun 2003 23:25:00 -0400

> recall this being the final consensus on the matter.

It's both left over and an attempt to finally reach consensus on this. I 
think having a means to indicate "face-to-face" is useful. I don't know 
if there is a better way of indicating that, given that we've ruled out 
creating a new URI schema for the walk-to-office-and-knock protocol. 
There are other cases where a tuple might not have a contact (geoloc has 
been mentioned), so I agree that this definition is not sufficient. I 
welcome other suggestions.

> doesn't seem to connect with anything given in the remainder of the doc.

Editing errors fixed; thanks for catching them.

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 26 Jun 2003 23:25:00 -0400

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 26 Jun 2003 23:11:46 -0400

> which would in turn make them constant across subscriptions.

Simple editing error in trying to do a quick cleanup. It shouldn't be there.

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 26 Jun 2003 23:17:38 -0400

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 26 Jun 2003 23:10:26 -0400

> sure that it should be done as a PIDF extension.

The surprise can occur even with the AOR, if you suddenly reach the 
secretary. This is quite common in any system that has any form of 
redirection of where phones are sometimes picked up by people other than 
the party which advertised that number. Thus, this doesn't seem to add 
any more confusion for 'naive' watchers than hiding the secretary behind 
the same AOR. If anything, the second AOR, with a different name, may 
provide a better clue to the non-RPIDS watcher that this is a different 
person, more so than just having the proxy route the MESSAGE to another 
person automatically.

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 26 Jun 2003 23:11:46 -0400

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 26 Jun 2003 23:10:26 -0400

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 26 Jun 2003 23:06:02 -0400