Document..........:  draft-sanchez-webdav-current-principal-01
Reviewer..........:  Christian Vogt
Review date.......:  September 24, 2008
IESG Telechat date:  September 25, 2008


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


This document explains the need for a new WebDAV property containing the principal of an online resource, and it specifies such a property.

The document is in good shape overall, and I think it can be published very soon.  However, I have one technical comment, which may either require some rethinking and rewriting, or some additional explanation in the document.  I have also identified a few editorial nits, which are easy to fix.


TECHNICAL

Section 3, 2nd paragraph of "description" field:

  This paragraph specifies the return value for the principal resource
  in case there are multiple possible values.  The return value is in
  this a case to be freely chosen by the server.  Why not return all
  possible values?

  The disadvantage of returning only a single principal resource value
  is that it may lead to consistency problems.  The paragraph attempts
  to prevent this by urging servers to /try/ to be consistent.  But
  since consistency cannot be guaranteed, consistency problems may
  still come up.  Always returning all possible values would fix this.

  The authors should consider changing the protocol behavior to always
  returning all available principal resource values.  If there are
  reasons to restrict the number of values returned to a single one,
  then these reasons should be explained in section 3 of the document.


EDITORIAL

Section 1, 1st paragraph:

  The acronym "ACL" appears here for the first time and should
  therefore be spelled out.

Section 1, 1st paragraph:

  "principal resource" which --> "principal" resource, which

Section 1, 2nd paragraph:

  recommended way to do identify --> recommended way to identify

Section 3, "purpose" field:

  current authenticated --> currently authenticated

Section 3, "value" field:

  The value is currently specified to always be a DAV:href element.
  But according to the description that follows, it could also be a
  DAV:unauthenticated element.  This inconsistency should be fixed.

Section 4:

  issues beyond those defined in HTTP --> issues beyond those
  identified for HTTP