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: [email-masked]
Date: Fri, 4 Jul 2003 13:46:09 +0300

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

After looking at this thread a bit more carefully, I agree with this distinction made about predictive presence, i.e., that publishing a prediction is different from making a prediction and then publishing the event as it was actually predicted to occur.

I agree that both ways are probably equally valid ways but do have different properties. When I was saying there is probably nothing more to standardize, I was only thinking of the latter one.
 
[snip]
 > reasonable distinction to make, I think, between predictive 

Agreed.

Cheers,
Aki
 
 > > > 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.
 >

---

From: [email-masked]
Date: Fri, 4 Jul 2003 13:46:09 +0300

[snip]

 
[snip]

Agreed.

Cheers,
Aki

---

From: Adam Roach <[email-masked]>
Date: Mon, 14 Jul 2003 08:47:11 -0500

> > watcher's buddylist screen. Apps might have predefined 
> icons corresponding
> See GAIM above, albeit provided by the watcher, given the lack of 
> protocol support.

I'm really going to have to agree strongly with Jon here.
Allowing the presentity to provide icons to represent any
kind of state -- and especially presence state -- is going
to result in nothing but an inscrutable mish-mash of angry
fruit salad in your buddy-list window.

It would be a real black eye if all or even most SIMPLE-based
IM systems ended up being thematically similar to the typical
poorly-designed amateur web page that consists primarily of
jarringly mismatched graphics found elsewhere on the web.

/a

---

From: "Chris Boulton" <[email-masked]>
Date: Mon, 14 Jul 2003 16:53:58 +0100

It really does seem sensible to me to maybe include optional attributes for teh size of an icon.  By making it optional, you give licence to clients to 'do as they wish' BUT you do give them the oppertunity to render correctly.
 
Chris.

	-----Original Message-----
	From: Adam Roach [mailto:[email-masked]] 
	Sent: Mon 14/07/2003 14:47 
	To: Henning Schulzrinne; Peterson, Jon 
	Cc: Simpletons (E-mail) 
	Subject: RE: [Simple] comments on rpids-01 (general, vCard, predictive)

	
	
	/a

J)��隊X��X��(��W�z��m��?�0�'�~���f��f��X��)ߣ�"��^

---

From: "Chris Boulton" <[email-masked]>
Date: Mon, 14 Jul 2003 16:53:58 +0100

Chris.

	-----Original Message-----
	From: Adam Roach [mailto:[email-masked]] 
	Sent: Mon 14/07/2003 14:47 
	To: Henning Schulzrinne; Peterson, Jon 
	Cc: Simpletons (E-mail) 
	Subject: RE: [Simple] comments on rpids-01 (general, vCard, predictive)

	
	
	/a

---

From: [email-masked]
Date: Tue, 15 Jul 2003 13:26:39 +0300

> From: ext Henning Schulzrinne [mailto:[email-masked]]
> Sent: Tuesday, July 15, 2003 12:16 PM
> To: Ben Campbell
> Cc: Simpletons (E-mail)
> Subject: Re: [Simple] comments on rpids-01 (general, vCard, 
> predictive)
> 
> 
> Ben Campbell wrote:
> 
> > 
> >>From a user interface perspective, I have to concur. The 
> whole point of
> > icons representing state is to give me a quick visual way 
> to determine
> > that state. This only works if the icons are consistent. If every
> > presentity I watch uses a different set of icons, then they 
> are useless
> > to me for that purpose. They become nothing but vanity 
> plates for the
> > presentities, or worse, a form of advertising. (In the same sense, I
> > consider HTML favicons to be evil.)
> 
> I don't see why we need to mandate UI preferences. Sure, you 
> should have 
> the possibility of turning off favicons (or RPIDS icons), but 
> they work 
> well enough to be considered useful by people who build browsers that 
> didn't have to implement them. I think noting that UA UIs 
> should allow 
> turning them off is a reasonable statements.

The watcher can also filter them out.

With mobile phones having cameras these days, sending a picture of the bar I'm at is a much more fun and probably quicker and more accurate way of describing where I am at this instance. A picture says a 1000 words.

/Hisham

---

From: [email-masked]
Date: Tue, 15 Jul 2003 13:26:39 +0300

/Hisham

---

From: [email-masked]
Date: Tue, 15 Jul 2003 18:20:45 +0300

Inline.

 > From: ext Ben Campbell [mailto:[email-masked]]
 > Sent: 15 July, 2003 12:08
 > To: Adam Roach
 > Cc: Henning Schulzrinne; Jon Peterson; Simpletons (E-mail)
 > On Mon, 2003-07-14 at 08:47, Adam Roach wrote:
 > icons representing state is to give me a quick visual way to 
 > determine
 > to me for that purpose. They become nothing but vanity plates for the

Even with an <icon> element present, you can still map whatever status the tuple carries into a local icon. An <icon> is really a graphical <note>. The fact that watchers will probably have a wide variety of different graphics to describe their tuples in different situations is a feature, not a bug. This information isn't meant to be mapped to a finite set of local icons, much like the note isn't.

Also, I don't think the current <icon> description in RPIDS even suggests that it be used to iconify a buddy in a buddy list window, so maybe this really boils down to the name of the element. So perhaps a <logo> describes this type of element better?

Cheers,
Aki

---

From: [email-masked]
Date: Tue, 15 Jul 2003 18:20:45 +0300

Inline.

Cheers,
Aki