presence spec

[Phillips, Matthew]

Hi David, all.

Finally found the time to do David's comments justice:

> - 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.

I've added a note on the reasons behind this.  Essentially, standardising on
case-insenstive groups, domains and user names avoids the confusion of not
seeing people just because you got the case of the username or group wrong.
It does make the subscriptions a little cruftier, but I think it's
manageable.

>   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.

Corrected.

> - 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.

I left this out as I think this is more of a client policy thing than a spec
thing.  Eg I don't think a presence client should force you to be in the
'0x1.org' group just because you are d at 0x1.org.  In Sticker I do intend, by
default, to put the user in a group that the same as their domain, but they
could later remove that group and add others.

> - 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

Good idea, I have revised some wording in light of this and added a note at
the top.

> - 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.

Note added to description of Status-Duration.

> - 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!

Agreed, but I want to start with a simple example to avoid freaking people
out with complicated expressions.  I've added section 3.5 that has a more
complex example.

> - 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?

Good point - in this case the Groups field is irrelevant, so I guess we use
"*".

> - 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.

Agreed, spec duly updated.

> - 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.

Yes, that was a typo - the full name should always be used.

> - 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|")  \
>       )  \
>     )  \
>   )

The examples have been updated for the change from User to Users.  One
impact of this is that clients no longer need to check for "*": they just
check to see if either they are in the requested user set, or one of their
groups is in the requested group set.

> - 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.

I have no strong feelings on this, and I guess an equality test is
marginally faster to match on the server, so I am happy to ditch it.

> - 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.

Done.

> - 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.

Your point about other languages is the decider on this one.  I've added a
Status field as well as the Status-Text field, which no longer has any
conventional meaning and can be any text.

I've also added an optional Requestor field to Presence-Request (see notes).

Phew, another major email epic completed.  Many thanks for your incisive
comments David.  Stay tuned for the 0.3 draft.

Matthew.