[ticker-dev] Presence specification draft 0.4

[Phillips, Matthew]

> i have a few remaining issues with this latest draft:
> 
> 1. i'd like to see some clarification (somewhere in 3.1 or 3.2?) of
>    the differences between the user's domain and groups.  is the
>    domain basically just another group (in terms of subscriptions)?

Good point.  I really intend that the domain simply be a namespace for
separating usernames in the same fashion as email domains.  I'll also add
that presence clients MAY put the user into a presence group with the same
name as their domain as a convention, but that there is no requirement for
this as part of the protocol spec.

> 2. the table entry for "Status" in 3.7 still provides "coffee" as a
>    valid status, but the discussion in 3.8 does not mention it (and
>    actually declares anything it doesn't mention as illegal).
> 
>    i think, following the separation of status and status-text, that a
>    coffee status is not needed anymore?

You're right in that "coffee" is not strictly needed, but it might be useful
for clients/bots that want to interpret coffee break events, for which
scanning the status text for the word coffee would be a lesser substitute.
As mentioned in the spec, it's really only there so that presence info can
subsume CoffeeBiff.   I have no problems with either taking it out, or
leaving it in and fixing the list in 3.8.

> 3. can we add a User-Agent field to Presence-Info?  i know it could be
>    done as x-User-Agent, but perhaps it's sufficiently common for
>    standardisation?

Shouldn't be too controversial, I'll add it in.

> 4. there's no discussion of security issues in the draft so far.
> 
>    i've been thinking about this, and the most disruptive thing i've
>    considered so far is that there might be a need to have different
>    visibility for different groups, requiring multiple notifications
>    for a single presence event.
> 
>    for example, if i'm prepared to reveal my subscribed ticker group
>    list to some people/groups, but not to others, then i might need to
>    send two notifications for each presence event, keyed
>    appropriately, one without the Chat-Groups.
> 
>    this then introduces the possibility that some clients could get
>    multiple notifications for a single presence event.  this might not
>    be a big deal, but perhaps we want to identify events, so that
>    clients can at least *detect* that the second and subsequent
>    notifications refer to the same event?

This sort of multiple presence info situation won't be a problem so long as
clients don't treat the absence of a field as meaning an empty value for
that field.  With this convention, in the case where a 'trusted' client
receives two presence info's, one with and one without the Chat-Groups
field, the client will not erase the correct values for the chat groups if
it gets the partial info after the full info.  This is a fairly natural way
to implement presence info handling in any case, however I will add some
discussion to the spec to the effect that clients should treat a missing
field as meaning "same value as last notification".

Matt.