On Tue, 2011-08-09 at 20:41 -0600, Peter Saint-Andre wrote:
> On 8/9/11 8:01 PM, Matthew Wild wrote:
> > On 9 August 2011 20:19, Peter Saint-Andre <[email protected]> wrote:
> >> On 8/9/11 4:59 PM, Matthew Wild wrote:
> >>> On 9 August 2011 18:53, Peter Saint-Andre <[email protected]> wrote:
> >>>> I've had several conversations recently with folks who indicate that
> >>>> they'd like a presence extension for what we could call communication
> >>>> context -- basically a machine-readable version of some of the strings
> >>>> that go into the <status/> element. Examples might include:
> >>>>
> >>>> 1. in-a-meeting (could be IRL or virtual)
> >>>>
> >>>> 2. on-mic (for audio chat)
> >>>>
> >>>> 3. on-camera (for video chat)
> >>>>
> >>>> 4. disconnected (cf. XEP-0198 when the stream hasn't been resumed yet)
> >>>>
> >>>> 5. something like "engaged IRL, can't communicate" (similar to but
> >>>> broader than parent-over-shoulder, e.g. things like being on stage)
>
> [..]
>
> > That makes perfect sense, but I guess my mental block is... isn't that
> > what PEP is for?
>
> I can't think of anything more appropriate for presence than
> communication context. As RFC 6121 says:
>
> Any extended content included in a presence stanza SHOULD represent
> aspects of an entity's availability for communication or provide
> information about communication-related capabilities.
>
> To my mind, PEP is for everything else -- tunes, activities, location,
> and other things that change more or less frequently than presence itself.
Funny you should say this, the first thing that came to mind when I read
your initial message was PEP, like Matthew, and more specifically User
Activity (XEP-0108). That covers most of the use cases you mention.
Let's go over the possible values, enclosed in the <activity/> element:
1. <working><in_a_meeting/></working>
<talking><in_real_life/></talking>
<talking><in_a_meeting/></talking>
2. <talking/>
<talking><on_the_phone/></talking>
3. <talking><on_video_phone/></talking>
For item 4, I would suggest using a custom extension element embedded in
the activity, although I am not sure if this is information that is
interesting enough for all your contacts and could maybe be arrived from
other information available to the client of the other participant(s).
Item 5 isn't really covered by User Activity, and Table 1 also shows a
gap for RPID's 'performance'. I don't see any problem adding a new
specific activity for this. Maybe in the 'talking' general activity
category?
As you are well aware, we invented this and other XEPs as *extended*
presence formats. I strongly believe they *are* part of the general
notion of presence. However, instead of shoving it in <presence/> we
decided that another, complementary, delivery method should be used
instead in the form of PEP:
* Contacts might not be very interested in the specifics on why
somebody is (not) available, or have no way to represent it in their
setting (e.g. a presence display in the physical world), so putting
it inside <presence/> would just send around a lot of data that
isn't consumed by the end user.
* This information is really orthogonal to availability presence: they
can both change independently. The fact that I am on the phone
doesn't necessarily mean I don't want to be disturbed.
I believe that a client like Gajim supports this really well: it shows
icons for extended presence in the roster and in the chat window banner.
It also allows one to define named presence combinations like 'On the
phone', which sets availability presence, user activity and user mood
when activated and configured.
Depending on what the expected behaviour should be, I could think of
alternative ways to set (manually, automatically or some combination of
those) and present this information. So, for now I think that the issues
are not really in the protocol but in the interaction design of the
client application being used.
--
ralphm
