[ticker-dev] Presence specification draft 0.4

[David Arnold]

-->"Matthew" == Phillips, Matthew <Matthew.Phillips at dsto.defence.gov.au> writes:

  Matthew> due to lack of any opposition and finally getting some free
  Matthew> time for fun stuff, I've updated the Elvin presence spec to
  Matthew> add definition for Client-Id to support overloaded clients
  Matthew> (multiple clients for the same user).  

thanks for the update 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)?

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?

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?

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?


i'll be releasing a new, 0.4-compliant, version of epm shortly.





d