presence spec

[David Arnold]

sorry this has taken so long, but i've finally got some comments on
draft two of the presence spec.

this morning i hacked up a Python/GTK presence client.  

    ftp://ftp.dstc.edu.au/DSTC/elvin/epm-0.1.tar.gz

you'll need Python1.6 or later, pe-4.0b1 or later, and PyGTK (i used
0.6.6 happily).  this is a slightly difficult combination, since many
Linux distributions still use Python1.5, and pe4 needs 1.6, but ...

for those unable/unwilling to install the required stuff, it's a very
simple UI: a multiple column list showing User, Time, Status and a
combo box below that for your own status text.

at this stage the time display is completely bogus: every 10 seconds,
it adds 10 to whatever value is displayed.  i couldn't be bothering
doing it better, since the real intention was to test the protocol.


so, i have a couple of comments to make on the draft spec:

- it's good.  thanks Matthew!

- section 3.1, says that the name and domain are case *in*sensitive
  strings.  are we sure that ignoring case differences are the best
  thing to do here?  it works for English, but i'm not sure how other
  languages/cultures deal with this.

  if we're to ignore case, all the example subscriptions later in the
  spec are incorrect, since they're not using the fold-case() sub-lang
  function.

- in section 3.2, i think the first paragraph could use some
  re-wording to make clear that the user's domain is their default
  group.  Matthew?  if you'd like me to send you some text, let me
  know.

- throughout the document, i think we would do well to adopt the
  IETF's terminology for requirements, as specified in RFC-2119.  i
  think this would help clarify statements of expectation from
  requirements of the spec, etc.

  see:  ftp://ftp.ietf.org/rfc/rfc2119.txt

- i think some explanation of the requirement for Status-Duration
  rather than a timestamp would be worthwhile.  the rationale of
  machines with broken clocks and timezone challenges is fine, but it
  should be in the document.

- section 3.4, step 1 of Frodo's client's actions.  the subscription
  shown does not illstrate the use of groups in addition to the
  default domain-group, nor direct subscriptions to a specified user.

  it'd be good to have an example of this more complete subscription
  in the spec.  one from epm --

  require(Presence-Info) && ( \
    contains(Groups, "|listen-group-1|") ||  \
    contains(Groups, "|listen-group-2|") ||  \
    contains(Groups, "|example-domain|") || \
    User == "extra-user at domain" \
  )

  note that this is a case-sensitive subscription!

- in section 3.4, in the Presence-Request event, the 'Groups' field is
  mandatory.

  when requesting information about a non-group buddy, what should i
  put in the 'Groups' field?  i could put the domain part of the user
  name, but that seems redundant?

- in section 3.4, in the Presence-Request event, the 'User' field is
  singlular.

  this means that i need to send one request for each of
  my non-group buddies.

  if the 'User' field were to become 'Users' with the same list syntax
  as the 'Groups' field, a starting presence client would only need to
  send 3 notifications: request for groups, request for users, and its
  own new status.

- in section 3.4, in the Presence-Request example subscription, the
  'User' field does not contain the domain part of the user's name.
  elsewhere in the spec, all 'User' fields contain the fully-qualified
  user name.

  in epm, i used the fully-qualified name here.

- in section 3.4, in the Presence-Request example subscription, the
  'User' field is conjoined with the 'Groups' field.  this means that
  the example subscription will not receive requests for a non-group
  user.

  in epm, i altered this subscription to be

  require(Presence-Request) && (  \
    User == "user at domain" || (  \
      User == "*" && (  \
        contains(Groups, "|domain|") ||  \
        contains(Groups, "|member-group-1|") ||  \
        contains(Groups, "|member-group-2|") ||  \
        contains(Groups, "|member-group-3|")  \
      )  \
    )  \
  )

- in section 3.4, in the sample Presence-Info reply, the value of the
  Presence-Info field contains both the word 'reply' and the unique
  reply tag.

  do we need the word 'reply' here?  i know it's easy enough to match
  using contains(unique-tag), but is a simple equality test better?

  this would require that the unique tag never be 'initial' or
  'update', which is faily easy to implement.

- in section 3.5, the 'User' field specification has issues as
  described above.

- in section 3.6, the 'User' field definition does not require the
  @-sign or domain to be included.  this should be clarified and made
  explicit.

- in section 3.6, the 'Status-Text' field definition doesn't
  explicitly state whether the example values must be supported by a
  client.

  as suggested in section 4.1.3, it might be useful to split the
  status into a semantic flag, and a displayed text.  this would
  possibly help with multi-lingual clients also, where, for example,
  the use of "Unavailable" as the status might be meaningless.

  i'd like to discuss this further.


sorry this is so late, and long.  hopefully it's useful!




d