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

From: [email-masked]
Date: Thu, 3 Jul 2003 10:10:59 +0300

Inline

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

Let me also restate what I said in Ottawa. I don't think there is really a problem for us to solve here beyond a mechanism which allows a publisher to get an indication when its state has been overridden by someone else. My personal presence model only includes PUAs - some of them may be automatons, some human beings, but all work in real time independent of whether the data from which they derive the publications is static or dynamic. Interactions between automatically derived presence and any other source ultimately need to be resolved by the system designer. Having said that, I may of course be missing the point about predictive presence - I just think we may be stepping too deep into implementation space here.
 
 > 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.

I do too, not sure there's much more to standardize though.
 
 > > 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.

The publish draft has an open issue on this exact point. In a case where the publisher is a human being, it is possible to ask for further actions if a collision occurs. But with automatons, this is of course trickier. However, I'm not sure we need to nail down any one way to resolve the error scenario. It could be that an automaton always steps down, but some automatons may also be authoritive on this. It really depends on the system, IMO.
 
[snip]
 > > 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.

As I've said before, there are commercial systems out there that do use graphics to describe a presentity's status. The provided icons are not meant to replace "away" icons on buddylists - I believe they are more akin to a personalized, graphical <note>.

And as long as we're aiming at enabling a SIMPLE application on par with the market, we might as well look at all commecial systems, not just some of them.

Cheers,
Aki

 > 
 > Jon Peterson
 > NeuStar, Inc.
 > 
 > _______________________________________________
 > Simple mailing list
 > [email-masked]
 > https://www1.ietf.org/mailman/listinfo/simple
 > 

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 13 Jul 2003 10:07:24 -0400

[email-masked] wrote:

>> 
>> 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.
> 
> As I've said before, there are commercial systems out there that do
> use graphics to describe a presentity's status. The provided icons
> are not meant to replace "away" icons on buddylists - I believe
> they are more akin to a personalized, graphical <note>.
> 
> And as long as we're aiming at enabling a SIMPLE application on par
> with the market, we might as well look at all commecial systems,
> not just some of them.

I agree that icon is useful, but I think we need to say a lot more 
about it. In particular, the assumption is, I think, that these icons 
will be used as part of a user interface. In that case, its not just 
merely rendered in a browser, but rather would assumed to meet some 
constraints in order to be used as part of an application UI. 
Certainly size is the most important one. At the very least, a certain 
aspect ration may need to exist, and perhaps a specific size, if the 
UI can't resize images.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 13 Jul 2003 10:07:24 -0400

-Jonathan R.

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 13 Jul 2003 11:10:54 -0400

Jonathan Rosenberg wrote:

> I agree that icon is useful, but I think we need to say a lot more about 
> it. In particular, the assumption is, I think, that these icons will be 
> used as part of a user interface. In that case, its not just merely 
> rendered in a browser, but rather would assumed to meet some constraints 
> in order to be used as part of an application UI. Certainly size is the 
> most important one. At the very least, a certain aspect ration may need 
> to exist, and perhaps a specific size, if the UI can't resize images.

Almost all web-browser based systems can resize images, from what I can 
tell. (I know there are certain Java-based desk phones which can/could 
not.) I will add a note as to its use, but I'm not sure that we should 
fix a pixel dimension or aspect ratio. In particular, with 
content-negotiation in HTTP, it might become feasible to have several 
different versions, from the high-res photo showing the cell phone to 
the 20x20 GIF.

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 13 Jul 2003 11:10:54 -0400