[ticker-dev] Re: Elvin presence spec draft - request for comments

[David Arnold]

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

  Matthew> All: I guess I'm actually proposing a spec-within-a-spec
  Matthew> for the presence RFC, namely that we adopt a unique user
  Matthew> naming scheme for ticker similar to email, where local
  Matthew> usernames are resolved using logical domains.

i had a late-night, in-bed, semi-conscious read of the draft last
night, and this was the point that struck me most.

the use of foo at location naming evolved (again, i think Rik Taylor
started it, or at least popularised it?) to add an extra dimension to
the awareness generated via ticker.  you could now, almost implicitly,
determine where someone was.

i like this a *lot*, but it has always clashed with my desire to
enable scalability of ticker to a larger audience, something that
simple names don't, and for a while, the use of foo at location competed
with foo at some.unique.domain as we attempted to encourage people to
adopt a globally useful naming scheme.

my guess is that the popularity of foo at location at DSTC is a result of
our multi-site groups, frequent use of ticker while travelling and the
popularity of working from home.

  Matthew> As Bill suggests, other information, such as where you are,
  Matthew> can go into the presence info.

yes.  and, no.

putting location info into a/the presence protocol is good, and right.

but i don't think a result where you need to have a presence client to
determine this is necessarily good.  i *like* the fact that tickertape
is currently able to give me location information as a side-benefit.

perhaps this comes back to the idea of tickertape events having both a
unique name for the sender, and a nickname that can be displayed?

i don't think (?) i would like to require support for the presence
protocol in all tickertape clients?

  Matthew> I really, really want to avoid having a binary crud unique
  Matthew> 'user id'.

agreed.  i think most of the presence systems have decided that an
email address is the best solution, since everyone has one already,
and it's already unique, and it's human-readable, textual and all that
nice stuff.

  Matthew> The other reason a domain is useful is that it gives you a
  Matthew> useful starting buddy list that is automatically populated
  Matthew> and maintained (note that being able to see everyone in the
  Matthew> whole of tickerland is unscalable).

i do like the idea of have my presence client have a default domain,
but i'm not sure it needs to be the domain part of my unique name.

for example, i would likely want to use `d at 0x1.org' as my unique name
because i have a network life outside my employer (well, kinda) and
because it is persistent across changes in employer.

but i would normally want to have `dstc.edu.au' or maybe
'dstc.monash.edu.au' as my default domain (given that i'm the only
person in the 0x1.org domain ;-)

i know this is mkaing things more complex.  i think that defaulting to
using the domain suffix of the user's name as their presence domain is
sensible.

perhaps we need to consider a generic concept of groups, rather than
domains?  this could work similarly to awareness of tickertape channel
subscriptions?

  Matthew> I'll have another look at IMPP and Jabber to see if there
  Matthew> is any wisdom to be found there.

perhaps the best place to start is the IMPP requirements RFC?  

    http://www.ietf.org/rfc/rfc2779.txt




d