Subject: RE: [Simple] comments on rpids-01 (general, vCard, predictive)

From: "Peterson, Jon" <[email-masked]>
Date: Sat, 28 Jun 2003 05:00:13 -0400

> 
> > 
> > True - but at some point I imagine there will be an injection of
normative
> > behavior into these schema descriptions.
> 
> I don't think it is realistic to assume that any of these elements will 
> ever be mandatory, simply because it's very clear that there will always 
> be circumstances where any one of the elements is either unknown or the 
> presentity has good reasons not to want to disclose that element. I 
> would agree that any RPIDS element that is mandatory should indeed be in 
> its own namespace (and probably document). I don't see any here, but 
> maybe you can provide an example?
> 

Well, I didn't say 'mandatory', I said 'normative'. So for example, I think
that <idlesince> (as given in rpids-00) should have normative behavior
associated with them. I think we should at least RECOMMEND the inclusion of
the <idlesince> parameter when the client is idle, and I think we should
RECOMMEND an idle threshold at which the <idlesince> parameter starts to
appears. A side point, not really material to how we group these elements, I
suppose.

> > 
> > The key issues seemed to be deciding which presence took priority when
> > calendar information conflicted with other information, deciding what
'human
> > authorization' of the "correct" presence information meant, sequencing
> > presence information when predictive presence is available (i.e. when
does a
> > calendar start publishing information), how to handle these cases with
> > aggregate presentities, handling dueling automata and/or calendars, and
so
> > on.
> 
> This is a generic issue, as soon as you have *any* automatically 
> generated data. I think these are either policy issues or configuration 
> issues. In other word, not requiring standardization. For example, the 
> 'lookahead' can be easily configured and is matter of choice for the 
> presentity. Interoperation is not endangered by whether I choose to 
> advertise my whereabouts for the next month or the next ten minutes.
> 

I think there is a qualitative difference between predictive presence and
'regular' presence - the etymological relationship of 'presence' to 'the
present' is important. Ordinarily, when I publish presence, that presence
expires in some amount of time (hopefully quite a small amount) if it is not
refreshed - it is forced to stay current. Ordinary presence eventually
expires when the device that it represents turns off; but calendars don't
behave that way, their state is static and isn't reinforced by refreshes.
Calendar publishers have an indirect relationship with a presentity's
devices, but for example, a purely calendar-driven presence would not
include an <idlesince> element; it isn't like a typical publisher that bases
its publications on the communications interface whose presence it
represents. Thus, I don't consider calendared presence to be 'automatically
generated data' - it isn't generated based on observation of the devices of
the user, it is entered manually into the calendar; the fact that it is then
published at a later time doesn't make the generation of this presence
information automatic. 

And even if it were automatically generated, in my opinion, the issues with
predictive presence aren't generic to all other forms of automatically
generated presence. A number of issues arise because there is a moment in
time (in the past) when a presentity (or someone entitled to publish on
their behalf) speculates on their future status - this creates issues with
when presence is published (should it be when the prediction is made, or
when the predicted time arrives?) how presence is timestamped (when a
publisher publishes, does it generate and timestamp a tuple then, or is the
tuple generated and timestamped when the prediction is made?), how
precedence is determined (i.e. do timestamps suffice for precedence of
presence information when comparing two published tuples that cover the same
resource?) and so on. 

Again, I defer to the conversation recorded in Ottawa - these did not appear
to be trivial or obvious issues, and some proposed solutions were
problematic. Given that, standardization of these things (such as when
predictive presence is published) seems appropriate, if not necessary - I
think these are real issues, and generic or no, they need to be accounted
for. I do not think we encounter these issues if our goals are only as
modest as, say, defining <category> and <idlesince> as given in rpids-00. 

Finally, let me stress once again I think predictive presence is
interesting, valuable, and something we should take on - I just think we
should take it on separately from our more modest goals. There is a
reasonable distinction to make, I think, between predictive presence and
'regular' presence.

> Similarly, as Brian and other have pointed out, any automatic 
> information will occasionally be wrong (but they believe, if I interpret 
> them correctly) that the probability of correctness is higher. In 
> general, I tend to favor "automatic with override" on all elements, but 
> that's again a policy issue. Others might want "automatic with mandatory 
> approval" or "hey, it's a guess anyway".
> 

I agree with Brian and virtually everyone else that automatically generated
presence is superior - I'm just not sure I group predictive presence into
that category, for the reasons given above. If dealing with predictive
presence is left totally to local policy, then dueling automatons are a real
possibility, I think.

> > 
> > In other words, the Call-Info method of delivering vCards and icons
> > shouldn't be ruled out on the grounds that some protocol other than SIP
> > can't available itself of it.
> 
> Agreed; as I noted, with composition, Call-Info won't do the trick, so 
> this is just another reason.
> 

And I noted that Call-Info w/ icon might appear in an INVITE, not a NOTIFY.
The requirement that the icon needs to be transmitted with presence data is
what I am questioning. If we grant that the icon should be transmitted with
presence data, I agree that the tuple is a better location that the
Call-Info header, because of the aforementioned composition issue.

Since we don't have any reference requirements to fall back, this may be a
tough issue to resolve (mind you, I'm NOT suggesting that we start some kind
of requirements phase for this). I suppose I tend to advocate removing
features much moreso than retaining them when they are borderline,
especially when I'm not sure they are necessary for the application we're
trying to enable.

> This is an element where I agree this can be considered borderline.
> 
> > I don't see why presence has to be the carrier of this reference.
> 
> Particularly for complicated presence documents, a presentity-supplied 
> icon may well be the best short-hand for a tuple since it can capture 
> information that is hard to express otherwise. (Well, beyond the "beach 
> with sunset" rubbing in that the presentity is on vacation and the 
> watcher is not...) Existing presence systems don't have multiple tuples 
> for each presentity, so this less of an issue. I don't see how a 
> message-based icon in messaging helps with rendering presence status in 
> a quick-to-grasp form.
> 

Again, commercial instant messaging systems, in my experience, don't use
presentity-provided icons to express a presentity's current state in a
watcher's buddylist screen. Apps might have predefined icons corresponding
to, say, your <category> state as given in rpids-00, but I don't think I've
seen user-supplied versions of those icons to date. The whole value of these
buddylist icons is that they're the same for all users in the same
<category> - if your used-defined icon for 'away' looks different from
somebody else icon for 'away', then icons aren't making the buddylist screen
any easier to interpret. The custom icons that are used in commercial IM&P
products today show up in a different context, afaik.

Jon Peterson
NeuStar, Inc.

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 28 Jun 2003 15:51:54 -0400

> appears. A side point, not really material to how we group these elements, I

I can see the value of the idle threshold (although I can't say I see 
any rational basis for favoring any particular value between 5  minutes 
and an hour; I'll randomly pick 10 minutes).

If I understand your normative language concern correctly, this 
basically decomposes into SHOULD/MAY-level inclusion decisions (my 
original interpretation) and sensible thresholds, where that is 
possible. (I think only <idlesince> has this; the only other policy 
constraint I can see right now is the 'look-ahead' in predictive elements.)

> presence is left totally to local policy, then dueling automatons are a real

I can't see how this can happen. The composer pulls the predictive data 
off the calendar, does whatever filtering is appropriate, done.

> Call-Info header, because of the aforementioned composition issue.

I randomly looked at GAIM, and it has icons for each presentity, as in
http://gaim.sourceforge.net/screenshots.php?file=newlist.png . Since 
there don't seem to be other systems that have the tuple notion, it's 
probably hard to find an exact analogue. (One could argue that we might 
want <icon> at both <tuple> and <presence> level.)

> especially when I'm not sure they are necessary for the application we're

No disagreement here, but low-complexity features that add value and are 
more than clone-of-AIM may spur adoption of technology...

> seen user-supplied versions of those icons to date. The whole value of these

See GAIM above, albeit provided by the watcher, given the lack of 
protocol support.

> products today show up in a different context, afaik.

I suspect that graphical clients will have at least two icons per user: 
an icon identifying the user and one identifying his or her state. 
Additional iconic representations for capabilities or placetype also 
seem likely.

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 28 Jun 2003 15:51:54 -0400