Subject: RE: [Simple] comments on rpids-01

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

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

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

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

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

> 
> 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'm going to agree, but for a different reason.
This information is/should be in the vCard.

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 26 Jun 2003 15:52:05 -0400

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

Agreed.

Also, as a minor issue, splitting the document into many namespaces 
increases the presence (not I-D) document size, since each namespace 
needs to be referenced. The namespace length could easily exceed the 
'payload' length. I doubt that compression would help much here.

I also fail to see the value of dividing the presence information into 
numerous tiny bits since senders and receivers can ignore information 
that they do not have, do not want to reveal or do not want to present. 
All information in RPIDS (or any of its sub-cousins) is optional and 
complementary.

The only valid reason that I can see for splitting the document is if 
there are vastly different levels of maturity, i.e., where one element 
is very well understood, while others are considered worthwhile, but the 
general feeling is that their representation would change drastically 
given another year of thinktime.

Having one document makes it much more likely, in my view, that 
implementations will implement all of it, at least to the extent of 
rendering information sensibly.

> manually from a user won't.

That is one of the guiding principles of RPIDS.

> nicely.  These are some of the most important parts of RPIDS (past

I also strongly disagree with Jon here. These were discussed extensively 
among the authors as being useful and easily derivable. I believe they 
pass the "well understood" test.

>>communications info. I think that for the time being, there isn't any

RPIDS does not include the vCard, it includes a reference to it.

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

Since not all systems will use SIP, I don't see how there is an existing 
mechanism for these. Among the mechanisms, the icon is probably the most 
useful, since it can change fairly frequently and belongs to the 
application (while vCards are more generic and indeed may well be 
deferable). One motivation is that this allows an easy mapping from SIP 
information to presence document information. With merging of multiple 
tuples, the information can't be included directly in the SIP NOTIFY 
request.

> The recipient would ask for it if it wanted/needed it.  Just dumping

I agree that a 'last changed' timestamp would be useful and trivially 
added. Checksums don't work since there are HTTP objects that have 
multiple representations (e.g., GIF, JPEG or PNG), depending on the 
Accept headers.

Since this is getting rather long, I'll split the rest into separate 
messages.

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 26 Jun 2003 15:52:05 -0400

Agreed.