Subject: [Simple] Link to external article: Presence application -- Employment status

From: Dean Willis <[email-masked]>
Date: Mon, 13 Jun 2005 16:38:08 -0500

So, do we need to account for this explicitly in RPID, or is this proof 
that codes lacking semantic specificity are still quite useful?

http://www.wired.com/news/culture/0,1284,67789,00.html

--
Dean

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

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 13 Jun 2005 18:10:36 -0400

I think it is fine for Note to be used for stuff like this, as long as 
the UIs actually display the note.

If this sort of thing becomes important enough that it be possible to 
translate it into another language or an icon then it will be time to 
define a new activity value or an entirely new element.

	Paul

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 13 Jun 2005 22:00:53 -0400

We will never be able to anticipate all of the use cases and information 
that people want to convey in their presence. I heard another example 
recently of teens setting their status to convey the topic of 
conversation in an IM conversation with their friends, almost like a 
form of multicast group chat through IM status.

This is what note is for. I continue to believe we need freeform text 
throughout the fields to enable this. If it becomes commonplace and 
mature enough in a particular area, then we can define specific 
extensions to convey semantics.

-Jonathan R.

Paul Kyzivat wrote:

>> So, do we need to account for this explicitly in RPID, or is this 
>> proof that codes lacking semantic specificity are still quite useful?
>>

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 14 Jun 2005 04:20:28 -0400

I think both - we have 'working', so 'looking-for-work' is a fairly  
natural counterpart. <activities> already has a notes element, but if  
folks believe that other elements missing notes need one, let me know  
(soon).

This should make SIMPLE and RPID the next must-have tool for  
Hollywood (or day laborers). In general, I think we'll see more use  
of presence for longer-term "keeping up" indications. The creative  
use of 'away' messages has been popular on college campuses for a  
number of years. See http://www.awaymessages.com/

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 14 Jun 2005 07:40:52 -0400

> folks believe that other elements missing notes need one, let me know  

I was looking at this recently, and I noticed one thing that may be 
worth consideration.

The Note in Activities may occur only once per instance of Activities. I 
can see usage models where it might be helpful if the Note element could 
appear multiple times.

This usage would be helpful if a client views the note as an extension 
mechanism for adding new values. If it views it this way, then it may 
just want to have a configuration option to define new elements, and 
then have those new elements appear in a pick list with the predefined 
elements.

As currently defined, each element that has a Note must treat it as a 
special case in the UI becuase it obeys different rules.

I don't feel stringly about this, but it is worth a moment of consideration.

	Paul

> This should make SIMPLE and RPID the next must-have tool for  Hollywood 
> (or day laborers). In general, I think we'll see more use  of presence 
> for longer-term "keeping up" indications. The creative  use of 'away' 
> messages has been popular on college campuses for a  number of years. 
> See http://www.awaymessages.com/
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 16 Jun 2005 07:22:41 -0400

> then have those new elements appear in a pick list with the predefined 

I'm not sure I'm getting what you're suggesting. Something like:

<activities>
   <note>First note</note>
   <note>Second note</note>
   <sleeping/>
</activities>

?

> special case in the UI becuase it obeys different rules.

At least the intent was to either have exactly one note element or none, 
  so the UI could be something like:

Activities:    [drop-down with multi-selection]   [... note ....]
Type of place: [drop-down with one selection]     [... note ....]
Relationship:  [drop-down with one selection]

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 16 Jun 2005 09:34:09 -0400

Henning Schulzrinne wrote:
> Paul Kyzivat wrote:
> 
>> The Note in Activities may occur only once per instance of Activities. 
>> I can see usage models where it might be helpful if the Note element 
>> could appear multiple times.
>>

Yes, something like that.

>> special case in the UI becuase it obeys different rules.

Right. I'm just questioning if those different rules are the best ones here.

> Relationship:  [drop-down with one selection]

Yes. An alternative might be:

  Activities:    [drop-down with multi-selection]

where one of the selections is "other" and leads to a dialog to define 
"other". This would then be remembered and appear in the drop down list 
in the future. This would give the end user extensibility.

Now the same thing could be done even if only one note is permitted. But 
then the UI is odd, because it will permit multi-selection of the 
predefined elements and any one of the extensions, but not two of the 
extensions. An implementation like that would probably get a lot of 
support calls from confused users.

It is not a big deal, but I think it is worth thinking about the kind of 
UIs will and won't be facilitated.

	Paul

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 16 Jun 2005 17:09:40 -0400

Paul Kyzivat wrote:
> 
>> At least the intent was to either have exactly one note element or 
>> none,  so the UI could be something like:
>>

There are really two different things that you're applying 'notes' to, 
namely as a means of providing additional context for an enumerated 
value, explaining or adding detail, or as a way to add user-defined 
values without extending the schema. I'm not sure it's a good idea to 
commingle the two.

Different solutions have been proposed, along the lines of

<activities>
   <note>The grass is 2' high</note>
   <other>Moving lawn</other>
</activities>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 16 Jun 2005 18:32:37 -0400

Henning,

OK - I like what you suggest! (Wish I had thought of it.)

	Paul

Henning Schulzrinne wrote:
>> "other". This would then be remembered and appear in the drop down 
>> list in the future. This would give the end user extensibility.
> 
> 
>> Now the same thing could be done even if only one note is permitted. 
>> But then the UI is odd, because it will permit multi-selection of the 
>> It is not a big deal, but I think it is worth thinking about the kind 
>> of UIs will and won't be facilitated.
>>
>>     Paul
>>