RE: Last Call: Access Control Protocol

1)  I agree that the xmlns:D="DAV:" is kind of off-putting.  "DAV:" is a URL
with the "DAV:" protocol identifier, which is never used anywhere else, not
another namespace.  This is the way RFC2518 is defined, and I guess the goal
was to define the shortest possible namespace URL
for the "D" namespace prefix.  You get used to it.

2)  Are you complaining about the lack of mapping between the ACL privileges
and HTTP methods?  Would you be happier if it were specified that the "GET"
method for example must be restricted by "DAV:read" and the "PUT" method
must be restricted by "DAV:write"?  This issue has come up
before, and while I remember that there was some reason not to do so
(because I think some HTTP methods may be restricted by different privileges
depending on other context, e.g. POST), I'm not sure that's not a good
reason to specify things for the methods that we do map.

3)  POST is not necessarily appending to a resource.  I consider it more of
an "execute" command than anything else.

I think access control in the scenarios you describe may well be constrained
by server-defined privileges, and the general intent of the protocol is that
this is what would be done.  I can define privileges like "Sign GuestBook"
for a particular resource if I want to restrict that.

--Eric

> -----Original Message-----
> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Roy T. Fielding
> Sent: Friday, November 09, 2001 6:46 PM
> To: Jim Whitehead
> Cc: WebDAV
> Subject: Re: Last Call: Access Control Protocol
>
>
> Some general comments:
>
>  1) Why does every example use xmlns:D="DAV:"?  That seems to be
> a pointless
>     exercise in indirection that will ultimately lead to clients that
>     parse on D:whatever instead of the actual spec.  Besides, DAV itself
>     is an xmlns that needs to be defined somewhere.  If the goal is to
>     simply show that it is possible, then only one or two of the examples
>     should use the shorter short name.
>
>  2) This protocol has departed from the Web interface of access
> control being
>     set on a per-method basis.  The effect of this change is that access
>     control will now have to be governed by both the Web server
> and whatever
>     handler within the Web server is interpreting WebDAV methods,
> resulting
>     in a pointless duplication of code (and effort, if the resource
>     requires both forms be active).  Eventually, someone will have to
>     define an HTTP access control protocol.
>
>  3) The protocol does not differentiate between writing to a
> resource (PUT)
>     and appending to a resource (POST), and thus cannot be used to control
>     shared access for things like guest-books, log files, or
> collection-like
>     bulletin-board resources.
>
> The first is a matter of editorial choice.  The second prevents
> this protocol
> from being generally useful outside webdav.  The third leads from
> the second.
> I don't think any of them would necessarily prevent it from becoming a
> proposed standard for WebDAV, but I wouldn't call it access control for
> the Web.
>
> ....Roy
>
>

Received on Friday, 9 November 2001 22:21:44 UTC