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
- Last Call comments on draft-sanchez-webdav-curren… Julian Reschke