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: [email-masked]
Date: Thu, 26 Jun 2003 17:04:11 +0300

Hi Jon,

A couple of comments inline.

[snip]
 > here. If need be, I'd recommend incorporating them as one or 

I disagree. There are commercial systems out there already which provide <icon>, <info>, and <card>-like semantics. And I think an image is as much presence information as a freetext note - it adds considerably to the effectiveness of the message. In theory, an <icon> is worth a thousand <note>. ;-)

Also, we seem to come back to this old disagreement over what is considered presence information. In my opinion, how often something changes may not be the optimal basis for this decision. In the past 6 months or so, my mobile has been CLOSED for total of maybe 60 hours. That means it has been OPEN for over 98% of the time (with admittedly varying degrees of <category>), which I consider an incredibly infrequent change in status.

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

See above - the genie is already out of the bottle... 

To me the semantics of the two are distinctly different. And I reckon the reason for having both is that you can provide a baseline PIDF compatible note as well as a URL. And watchers won't have to guess links off of <note> elements, support clicking the URLs in the GUI etc., when we provide a separate element explicitly for URLs.

Cheers,
Aki

---

From: [email-masked]
Date: Thu, 26 Jun 2003 17:04:11 +0300

Hi Jon,

[snip]

[snip]

Cheers,
Aki

---

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 26 Jun 2003 15:27:19 -0400

While I understand the concept that we should have a few core
documents and a set of extensions to them, I also understand that
every document that goes through the mill consumes resources,
and splitting documents rarely lowers the total resources consumed.
On the contrary, for documents such as this, the "fixed" overhead
is likely to be linear with the number of documents, and the
"variable" overhead will be small.  Since the document does not (yet)
require any specific elements, there is no overhead in leaving them
in if we agree that they are useful, and moving them to a separate
document is not wise, in my opinion.

If we don't agree on their usefulness, then we might want to split
in order to make progress.  That DOES increase our overall workload
though.

Also, as a general comment, the experience we have is that manual
mechanisms don't work, automatic ones do.  Getting information from
activity, or calendar is something that will work.  Getting information
manually from a user won't.

In fact, vague hints from automatic mechanisms prove to be more useful
than explicit direct input, because you actually get the automatic
stuff, and you don't get any manual stuff.  A case in point:
  In front of me right now is a presence app that has a mix of old PA
clients 
  and new PA clients.  The old ones have a very simple, and very obvious
  "current state" indication with a drop down list to change it.  It's
  right in front of you, and takes two clicks (one to get the list, one
  to make the choice) to change it.  There are about 8 states to choose
  from.  It's roughly <category>

  New ones have the same setting, but they have also have the option to
  change the state from unavailable to available when you login, and
  from available to busy when you are on the phone.

  Looking at my display of perhaps 50 presentities, I see:
	Approximately 75% of the older clients are incorrect, and the
	vast majority of the correct ones are only correct because
	the state they were in happens to match the state they were
	how ever many eons ago they last changed their state

	All of the new clients show accurate, and up to date information
	as far as it goes.  It's not complete, because there are so few
	bits of information going into the automatic function at this time.
	However, it has proven to be very useful.

  If I, for example, put calendar derived state into the presence
  document, it would be incorrect around 20% of the time (many people
  are pretty fanatic about keeping their calendar accurate, some
  because they are just plain fanatic about keeping their lives
  straight and others because if they don't they would miss 70% of
  the events they were supposed to attend).  It's pretty clear that
  we don't get enough information yet (available is logged in,
  not on the phone, which is not correct if you are in a meeting).
  Adding calendar data should be pretty useful, we think.

So, I claim calendar based presence may be one of the most important
elements of RPIDS, and anything that could reasonably be automatically
derived is more valuable than anything which must be determined by
user effort.

Specifics in line, and I did not comment on the items
related to the "what is a tuple" discussion

> specifying these, I'd like to suggest that they should be 
Disagree as above.  They tell you useful information, they are
straightforwardly discoverable, and they fit in the RPIDS schema
nicely.  These are some of the most important parts of RPIDS (past
<category>) for me.

> here. If need be, I'd recommend incorporating them as one or 
On this one, I'm going to agree, somewhat reluctantly.  These are
not presence, they are really user identification (more detail
than "display name").  My reluctance is that we need icon for
a real IM system, and we have needed vCards for some time in SIP,
and there isn't any other place they are being standardized.

A well designed system, however, would be more complex.  It would offer
icons and vCards, with some sort of timestamp/checksum digest.
The recipient would ask for it if it wanted/needed it.  Just dumping
it in every time is bandwidth wasteful, and requires more work
on the receiver if it is actually trying to maintain a "database"
of them.

> this sort of activity as being something we immediately need for our
I think this needs some more discussion.

Generally, I think it is useful to have a more than binary indication
of activity.  If you have been idle for a few seconds, that tells me
much more than if you have been idle for a few hours.  Activity of
this sort is automatically derivable, and thus, to me, very valuable.

I think the basic point you seem to raise is whether interpretation
of the length of time is best done in the watcher or the PA.
Generally, I think the PA is in a better position to judge if
some kind of judgment is to be made.  Henning and others have
argued that no one but the human watcher really is able to decide,
which is the argument for sending the actual time.

One could fold this into <category>, but at the moment, I'm somewhat
reluctant to do so.  It may be better, for example, to show you
some kind of visual indication of how long someone has been idle,
rather than change the category to something akin to "presumed
not in the office".  On the other hand, some presentities may
not wish to give you this level of information, but may be willing
to have their PA provide some more coarse indications.  That could
be done by deliberately degrading the precision of <idlesince>.

If I seem to be waffling on this, I am.  I want to use the data,
I just don't know yet how best to use it.

> be, and I see no reason why a <note> to the same effect 
Disagree.  It may be possible to derive, or at least make a 
good guess, at <placetype>.  Automatons can certainly use the
registered values.  If a freeform value was encountered, they
would have to cope, but the listed values are the ones I
think you have a shot at deriving automatically.

<privacy>, at least public/quiet turns out to be automatically 
derivable for many people. It's the setting of the ringer on your cellphone.
You can also use calendar information for it.

> sure that it should be done as a PIDF extension.
I'm going to agree, but for a different reason.
This information is/should be in the vCard.

---

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 26 Jun 2003 17:25:14 -0400

[snip]
> 
> I disagree. There are commercial systems out there already 
> which provide <icon>, <info>, and <card>-like semantics. And 
> I think an image is as much presence information as a 
> freetext note - it adds considerably to the effectiveness of 
> the message. In theory, an <icon> is worth a thousand <note>. ;-)
> 

I wasn't saying that the total im/presence application doesn't need to
support icon sharing and whatnot - merely that it doesn't need to be in
presence information. I spoke to one way that icons can be shared with SIP
today (the Call-Info header) that didn't require this to be carried in
presence. So again, I'm not so much disagreeing with the requirement as I am
questioning if presence is the right way to carry it.

> Also, we seem to come back to this old disagreement over what 
> is considered presence information. In my opinion, how often 
> something changes may not be the optimal basis for this 
> decision. In the past 6 months or so, my mobile has been 
> CLOSED for total of maybe 60 hours. That means it has been 
> OPEN for over 98% of the time (with admittedly varying 
> degrees of <category>), which I consider an incredibly 
> infrequent change in status.
> 

This is true... but the status of your mobile phone is communications
status, unlike an <icon> or a <card>.

All that said, I think I'm most on the fence about these two attributes -
other than the argument from redundancy, and that they don't seem to be
presence as such, it doesn't matter to me either of way. If these two needed
to stay, I wouldn't be that upset.

> [snip]
<info> vs. note
[snip]
> To me the semantics of the two are distinctly different. And 
> I reckon the reason for having both is that you can provide a 
> baseline PIDF compatible note as well as a URL. And watchers 
> won't have to guess links off of <note> elements, support 
> clicking the URLs in the GUI etc., when we provide a separate 
> element explicitly for URLs.
> 

Um... well, if you're just replicating the information from the URL within
the note, that begs the question of why you need the URL at all. Again, I'm
not sure what the requirement is that motivates breaking from baseline PIDF
compatibility - above, I'm not sure that you really articulate one.

This one is a case where I think we're needless turning our back on baseline
compatibility.

---

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 26 Jun 2003 17:25:14 -0400

[snip]

<info> vs. note
[snip]

---

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 26 Jun 2003 18:59:13 -0400

> and splitting documents rarely lowers the total resources consumed.

This is a good point - and thanks for speaking to this, I think this process
point is one of the more important ones for us to consider. From my
perspective, splitting and serializing the presence extensions makes it more
likely that we will achieve our modest goals in the short term, and reserve
harder problems for the long term. Combining them means we have to solve the
hard problems now before we get out the short term work. This is my primary
concern (one that I believe has been substantiated by our progress in
offline discussions, which still largely revolve around capabilities).

> document is not wise, in my opinion.

If we hope to automate the usage of these elements, and have applications
process them in some reasonable fashion, there will need to be semantics
associated with the elements and requirements for their usage. I think there
is probably a lot of work to be done there even for the simpler elements.

> in order to make progress.  That DOES increase our overall workload

Sacrificing it in favor of short-term returns, yes. As a chair, I'm willing
to make that trade.

> manually from a user won't.

I think my ambitions are even more modest. I think things like <idlesince>
would be a tremendous improvement on baseline PIDF, and that's not something
we get manually from a user. I think being able to set an away/status
message (which is how I see <category>) is also valuable - though in many
cases that is set manually, from the days of IRC forward, users have found
this acceptable in my experience.

Calendaring to me represents just a greater amount of complexity. In my
previous note, I pointed to issues surrounding the reconciliation of
calendar info with current presence data - the discussion of this consumed a
significant amount of our time in Ottawa, and seemed like a reasonably
complex issue.

But as I said, I'm happy to do calendar stuff, I would just prefer to do it
in a separate doc, after we finish with more fundamental work.

[calendar example snipped, and accepted]
> derived is more valuable than anything which must be determined by

I definitely agree with this second proposition. I think calendaring should
be the next thing we do after <category> and <idlesince>.

[snip]
> and there isn't any other place they are being standardized.

The Call-Info header can already carry a reference to a vCard, per RFC3261
20.9.

> which is the argument for sending the actual time.

I was saying, yes, that based on <idlesince>, the watcher could derive a
value for <activity>. The only motivation for <activity> seems to be that
the presentity gets to derive it and dictate it to the watcher. But I think
this property is still achievable without <activity>, because the presentity
can choose the threshold at which it begins to incorporate <idlesince> into
its publications, which basically has the same effect.

> I just don't know yet how best to use it.

Well, I was arguing strongly for <idlesince>, and claiming that the current
<activity> parameter seems largely derivative of <idlesince>. I'm not sure
from the above if you agree - it sounds like you agree that <idlesince> is
good, and that we need more than a binary <activity> indicator in presence.
I don't think <activity> necessarily needs to be folded into <category>, but
I do note that the <category>away</category> might be a substitute for some
of the meaning of <activity>. 

> You can also use calendar information for it.

Well, I think it's pretty unlikely that, say, geoloc will be able to be
transformed into a <placetype> anytime soon, and even setting cell-phone
profiles is user entry. It seems to me that these have a realistic
dependency on user provisioning. 

But my argument above was really that the specific use for which <placetype>
and <privacy> were defined in the current document is irrelevant to
automatons - basically, that if all these indicators tell you is what sorts
of communications with the presentity might be appropriate, automatons
aren't going to be able to help you much with that. So sure, if there were
registered values, an automaton might understand them, but then what would
it do, exactly? Probably just render them to you, so you can see what kind
of communication is appropriate. Same thing it would do with a note. 

If we change the motivation for these elements, we might draw a different
conclusion, of course. I'm only speaking to the current motivation in the
draft, not any other usage of these elements. 

> This information is/should be in the vCard.

I think the security/authorization issues, and baseline PIDF compatibility,
are not insignificant.

Thanks again.

- J