Document: draft-ietf-simple-presence-rules-08
Reviewer: Pasi Eronen
Review Date: 2006-11-17
IETF LC End Date: 2006-11-20

Summary: This draft is basically ready for publication, but has nits
that should be fixed before publication.

Comments: 

In general, this document looks quite good and well written.  However,
there is one issue that IMHO should be better highlighted in the
document, preferably in the security considerations section; and
one nit about references.

The procedures for combining permissions (while carefully designed)
can lead to consequences that might be unintuitive to a user.  Thus,
the actual policy being enforced is not necessarily what the user
intended, and more information can be revealed.

One particular case: if I understood the semantics right (which may
not be the case :-), it looks like a user agent should not allow the
user to create rules with sub-action "block", since they have no
effect on the actual policy (the whole rule could be omitted instead,
right?).  If this is indeed the case, including the whole sub-action
seems a bit questionable.

Even without the block sub-action, misunderstandings are possible.
For example, given two rules matching identities joe@example.com and
*@example.com, respectively, certain UI designs might lead a user to
assume "first match" or "most specific match" semantics for the rules.

While detailed UI design guidelines are of course beyond the scope of
this document, I think at least the fact that rules can have semantics
that are not immediately obvious, and user agent UI design can
influence the "obviousness" part, should be mentioned, along with a
recommendation to pay specific attention to UI design to ensure that
the actual policy is what the user intended. A more specific
recommendation would be e.g. to warn users if they create rules that
have no effect.

One additional nit: To me it looks like the reference to RFC 3325
should be normative rather than informative (and that would be a
downref, since RFC 3325 is Informational). My reasoning is that
this document depends on RFC 3325 in the same sense it depends 
on RFC 2617 and RFC 4474, both of which are listed as Normative.