Last Call comments on draft-sanchez-webdav-current-principal-01

Julian Reschke <julian.reschke@gmx.de> Fri, 25 July 2008 13:07 UTC

Return-Path: <ietf-bounces@ietf.org>
X-Original-To: ietf-archive@megatron.ietf.org
Delivered-To: ietfarch-ietf-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C40773A6999; Fri, 25 Jul 2008 06:07:48 -0700 (PDT)
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27E613A6867 for <ietf@core3.amsl.com>; Fri, 25 Jul 2008 06:07:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.37
X-Spam-Level:
X-Spam-Status: No, score=-3.37 tagged_above=-999 required=5 tests=[AWL=-1.371, BAYES_00=-2.599, J_CHICKENPOX_34=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ke7trydoRa8N for <ietf@core3.amsl.com>; Fri, 25 Jul 2008 06:07:47 -0700 (PDT)
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id EF8B33A6999 for <ietf@ietf.org>; Fri, 25 Jul 2008 06:07:46 -0700 (PDT)
Received: (qmail invoked by alias); 25 Jul 2008 13:07:47 -0000
Received: from mail.greenbytes.de (EHLO [192.168.1.106]) [217.91.35.233] by mail.gmx.net (mp038) with SMTP; 25 Jul 2008 15:07:47 +0200
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX19l9q5ingRlRhJEFEUWjBFhPNSRipK/AqlLNhYned SMb0rwSxBvuEdV
Message-ID: <4889D01C.80204@gmx.de>
Date: Fri, 25 Jul 2008 15:07:40 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666
MIME-Version: 1.0
To: IETF Discussion <ietf@ietf.org>
Subject: Last Call comments on draft-sanchez-webdav-current-principal-01
X-Y-GMX-Trusted: 0
X-FuHaFi: 0.57
Cc: WebDAV <w3c-dist-auth@w3.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Hi,

this is a good proposal and I support publication as a Proposed Standard.

Below are some comments, mostly editorial:

> Abstract
> 
>    This specification defines a new WebDAV property that allows clients
>    to quickly determine the principal corresponding to the current
>    authenticated user.

Nit: Expand WebDAV acronym on first use.

>    Some clients have a need to determine the [RFC3744] principal that a
>    server is associating with the currently authenticated HTTP user.
>    While [RFC3744] defines a DAV:current-user-privilege-set property for
>    retrieving the privileges granted to that principal, there is no
>    recommended way to do identify the principal in question, which is
>    necessary to perform other useful operations.  For example, a client
>    may wish to determine which groups the current user is a member of,
>    or modify a property of the principal resource associated with the
>    current user.

Nit: say "WebDAV ACL" instead of "[RFC3744]" most of the time.

>    The DAV:principal-match REPORT provides some useful functionality,
>    but there are common situations where the results from that query can
>    be ambiguous (e.g. not only is an individual user principal returned,
>    but also every group principal that the user is a member of, and
>    there is no clear way to distinguish which is which).

Nit: reference RFC3744, Section 9.3.

>    When XML element types in the namespace "DAV:" are referenced in this
>    document outside of the context of an XML fragment, the string "DAV:"
>    will be prefixed to the element type names.

Substantial: need to state how XML fragments are to be interpreted, what
the extensibility rule is, and why it's ok to put things into the "DAV:"
namespace (for the first points refer to RFC4918, for the last you may
want to claim consensus of the WebDAV community).

>    Value:  Single DAV:href element.
> 
>    Protected:  This property is computed on a per-request basis, and
>       therefore is protected.
> 
>    Description:  The DAV:current-user-principal property contains either
>       a DAV:href or DAV:unauthenticated XML element.  The DAV:href

Substantial: this contradicts what "Value:" says. Maybe just get rid of
that one.

>    Definition:
> 
>       <!ELEMENT current-user-principal (unauthenticated | href)>
>       <!-- href value: a URL to a principal resource -->

Nit: should state somewhere where unauthenticated and href come from.


BR, Julian
_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf