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

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 26 Jun 2003 18:59:13 -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.

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

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

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

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

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

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

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

> Specifics in line, and I did not comment on the items
> related to the "what is a tuple" discussion
>  
> 
[snip]
[on vCard]:
> 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.

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

[on <activity>]:
> 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.
> 

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.

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

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

[on <privacy> and <placetype>]:
> 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.
> 

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. 

[snip on relationship]:
> I'm going to agree, but for a different reason.
> This information is/should be in the vCard.
> 

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

Thanks again.

- J

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 27 Jun 2003 11:32:23 -0400

> dependency on user provisioning. 

In addition to the real-life BlueTooth example I gave in an earlier 
note, the transformation from geoloc into placetype isn't all that 
difficult, at least for the common cases. All I need is a trivial 
mapping that says "if geoloc is within polygon X, I'm at home; if in 
polygon Y (covering the area between 110 and 120th Street and Broadway 
and Amsterdam), I'm at my office; otherwise, default to public". This 
doesn't deal with all cases, such as visiting other places, but it will 
be correct at least 90% of the time, with no central database, new 
protocols or anything else beyond basic geoloc.

> of communication is appropriate. Same thing it would do with a note. 

We may have somewhat different models of end system behavior. In my 
model, end systems (watchers) can also have processing logic. (In 
addition, end systems don't need to be PDAs or PCs running an IM 
application with smiley buttons.) In that model of end system 
intelligence, structured information is far more useful than random 
notes in <note>. For example, my end system logic can prioritize tuples 
that offer private communications, they can assign suitable icons that 
allow me to quickly distinguish home from office addresses or they can 
include appropriate warnings before I make a call. All of these require 
structured information.

In addition, when publishing presence information, this allows to 
construct easy rules. For example: "only publish office contacts to my 
co-workers; only publish 'home' contacts to my friends list". Again, a 
<note> isn't going to do this reliably.

> draft, not any other usage of these elements. 

I've added some additional motivational wording for <placetype> and 
<privacy>.