From w3c-dist-auth-request@w3.org Mon Oct 1 13:25:59 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24201 for ; Mon, 1 Oct 2001 13:25:59 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA03459; Mon, 1 Oct 2001 13:16:30 -0400 (EDT) Resent-Date: Mon, 1 Oct 2001 13:16:30 -0400 (EDT) Resent-Message-Id: <200110011716.NAA03459@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id NAA03439 for ; Mon, 1 Oct 2001 13:16:27 -0400 (EDT) Received: from cats.ucsc.edu (rumpleteazer.ucsc.edu [128.114.129.45]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id NAA26168 for ; Mon, 1 Oct 2001 13:16:27 -0400 Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177]) by cats.ucsc.edu (8.9.3/8.8.4.cats-athena) with SMTP id KAA23487 for ; Mon, 1 Oct 2001 10:16:15 -0700 (PDT) From: "Jim Whitehead" To: "WebDAV" Date: Mon, 1 Oct 2001 10:12:51 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: Adding a new Co-Chair: Lisa Dusseault Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5380 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit As I enter my second year of service as an Assistant Professor at UC Santa Cruz, it is becoming increasingly clear to me that I can no longer handle all of the duties of being Chair of the WebDAV Working Group as effectively as I would like. To remedy this, I intend to add a Co-Chair to this working group, and henceforth WebDAV WG will have two Co-Chairs. My choice for Co-Chair is Lisa Dusseault. Lisa is a long standing member of this working group who has made numerous substantive contributions to our work, and has been involved in multiple implementations of the protocol. Additionally, Lisa has led WebDAV meetings at past IETF conferences, and she is familiar with IETF procedures. I personally have great confidence that Lisa will be an excellent Co-Chair. Though IETF working groups follow an open and transparent process, the process by which working group chairs are selected is not democratic; no voting is involved. On the other hand, Chairs do not act as chairs without the consent of their working groups either. So, if you have any objection to my intention to add Lisa Dusseault as a Co-Chair of the WebDAV Working Group, please send an email to myself, and the two Application Area Directors, Patrik Faltstrom and Ned Freed , outlining your concerns. Please do so by October 8, 2001. In terms of a division of responsibilities, my intent is to take the work of the WebDAV WG and divvy it up amongst Lisa and myself. The Co-Chair with that responsibility will then be the final authority on that matter, though the expectation is that we will be consulting each other frequently. Shortly, I will send out a message detailing this division of responsibilities. If you have any other questions on how this will work, please feel free to ask. - Jim Whitehead Chair, WebDAV Working Group From w3c-dist-auth-request@w3.org Mon Oct 1 14:13:52 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25762 for ; Mon, 1 Oct 2001 14:13:52 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA06982; Mon, 1 Oct 2001 14:02:18 -0400 (EDT) Resent-Date: Mon, 1 Oct 2001 14:02:18 -0400 (EDT) Resent-Message-Id: <200110011802.OAA06982@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id OAA06940 for ; Mon, 1 Oct 2001 14:02:10 -0400 (EDT) Received: from cats.ucsc.edu (rumpleteazer.ucsc.edu [128.114.129.45]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id OAA00838; Mon, 1 Oct 2001 14:02:10 -0400 Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177]) by cats.ucsc.edu (8.9.3/8.8.4.cats-athena) with SMTP id LAA07189; Mon, 1 Oct 2001 11:01:59 -0700 (PDT) From: "Jim Whitehead" To: , "WebDAV" Date: Mon, 1 Oct 2001 10:58:35 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <200110011333.JAA21583@tux.w3.org> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: RE: Protocol Action: Versioning Extensions to WebDAV to Proposed Standard Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5381 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Yes!!! What excellent news. Five and a half years ago we began working on the vision of the Web as a writeable medium, one that could be used for remote collaborative development of software projects, large documentation efforts, and other large clusters of inter-related documents. With the approval of the DeltaV protocol as a Proposed Standard, we have taken a large step forward towards making this vision a tangible reality. Geoff Clemm receives my thanks and respect for the key role he played in the design of the DeltaV protocol, and in pushing it forward for so long. However, it was clearly a collaborative effort, involving the Chair, Jim Amsden, the document authors, the DeltaV design team, and the DeltaV working group. All of your tireless work, sending posts, making reviews, clarifying points, led to a high quality technical standard. Specification in hand, we are now well along the rough road to the common byte. I look forward to working with you all in the months and years ahead to ensure this specification leads to broad interoperability. - Jim > The IESG has approved the Internet-Draft 'Versioning Extensions to > WebDAV' as a Proposed Standard. > This document is the product of the Web Versioning and Configuration > Management Working Group. The IESG contact persons are Ned Freed and > Patrik Faltstrom From w3c-dist-auth-request@w3.org Tue Oct 2 09:16:12 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09517 for ; Tue, 2 Oct 2001 09:16:12 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id JAA06635; Tue, 2 Oct 2001 09:13:38 -0400 (EDT) Resent-Date: Tue, 2 Oct 2001 09:13:38 -0400 (EDT) Resent-Message-Id: <200110021313.JAA06635@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id JAA06611 for ; Tue, 2 Oct 2001 09:13:30 -0400 (EDT) Received: from greenbytes.de (mail.greenbytes.de [217.5.201.10] (may be forged)) by tux.w3.org (8.9.3/8.9.3) with ESMTP id JAA24591 for ; Tue, 2 Oct 2001 09:13:29 -0400 Received: from apu [192.168.1.2] by greenbytes.de [217.5.201.11] with SMTP (MDaemon.v3.5.3.R) for ; Tue, 02 Oct 2001 15:13:49 +0200 From: "Stefan Eissing" To: "Webdav WG" Date: Tue, 2 Oct 2001 15:13:48 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: <3906C56A7BD1F54593344C05BD1374B104652BD7@SUS-MA1IT01> X-MDRemoteIP: 192.168.1.2 X-Return-Path: stefan.eissing@greenbytes.de X-MDaemon-Deliver-To: w3c-dist-auth@w3c.org Subject: RE: Locking, moving and deleting Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5382 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff > > From: Lisa Dusseault [mailto:lisa@xythos.com] > > On Behalf Of Clemm, Geoff > > The best way to explain the defined MOVE semantics for a LOCK > > is to say that a LOCK is on a URL, but that it is deleted > > when the resource mapped to that URL is deleted. > > So far I can follow; it's not a bad model. I'd append "or moved" > to the end; most people will consider this different than "deleted" > because we have different methods for MOVE and DELETE. > > I agree that is worth making explicit to avoid any confusion. > > I don't follow your example as well (reproduced below) because WebDAV > doesn't specifically allow for one resource to be mapped by > several URLs. > > WebDAV allows for one resource to be mapped to multiple > URL's because HTTP specifically allows for one resource to be mapped > to multiple URL's. In particular, section 9.6 of RFC 2616: > > "A single resource MAY be identified by many different URIs. For > example, an article might have a URI for identifying "the current > version" which is separate from the URI identifying each particular > version." > > Therefore the locking protocol (and the rest of WebDAV) must have > well defined behavior in those cases where multiple URL's do identify > the same resource. > > Let's keep it simple and assume that a WebDAV system only maps URLs to > resources 1:1. > > That's fine, but it is good to keep the multiple mapping scenario in > mind for when someone suggests a "simpler" model that does > not handle the multiple mapping scenario. Well, RFC 2518 Ch. 6 says: "The ability to lock a resource provides a mechanism for serializing access to that resource. Using a lock, an authoring client can provide a reasonable guarantuee that another principal will not modify a resource while it is being edited..." This gave me the impression that locks are on a resource and not on one particular URL of that resource. I agree that multiple URL and deep locks on collections provide some interesting challenges to define consistent behaviour. But I find it a little bit hard to give up the assumption locking resource == locking resource content + properties So, maybe I have misunderstood this thread? //Stefan From w3c-dist-auth-request@w3.org Tue Oct 2 10:18:19 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12878 for ; Tue, 2 Oct 2001 10:18:19 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id KAA10520; Tue, 2 Oct 2001 10:16:11 -0400 (EDT) Resent-Date: Tue, 2 Oct 2001 10:16:11 -0400 (EDT) Resent-Message-Id: <200110021416.KAA10520@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id KAA10500 for ; Tue, 2 Oct 2001 10:16:06 -0400 (EDT) Received: from sus-ma1it00.rational.com (ext-37016.rational.com [192.229.37.16]) by tux.w3.org (8.9.3/8.9.3) with SMTP id KAA02042 for ; Tue, 2 Oct 2001 10:16:03 -0400 Received: from 192.168.215.70 by sus-ma1it00.rational.com (InterScan E-Mail VirusWall NT); Tue, 02 Oct 2001 10:15:26 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id <4D3CL8ZJ>; Tue, 2 Oct 2001 10:15:26 -0400 Message-ID: <3906C56A7BD1F54593344C05BD1374B10465301E@SUS-MA1IT01> From: "Clemm, Geoff" To: Webdav WG Date: Tue, 2 Oct 2001 10:15:24 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Locking, moving and deleting Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5383 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: From: Stefan Eissing [mailto:stefan.eissing@greenbytes.de] RFC 2518 Ch. 6 says: "The ability to lock a resource provides a mechanism for serializing access to that resource. Using a lock, an authoring client can provide a reasonable guarantuee that another principal will not modify a resource while it is being edited..." This gave me the impression that locks are on a resource and not on one particular URL of that resource. The purpose of a lock is serializing access to a resource, but that is not incompatible with saying "the lock is on a URI and controls access to the resource mapped to that URI". I agree that multiple URL and deep locks on collections provide some interesting challenges to define consistent behaviour. But I find it a little bit hard to give up the assumption locking resource == locking resource content + properties So, maybe I have misunderstood this thread? You just need to expand your equivalence as follows: locking resource == locking URL == locking resource mapped to that URL. Cheers, Geoff From w3c-dist-auth-request@w3.org Wed Oct 3 11:22:58 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18267 for ; Wed, 3 Oct 2001 11:22:58 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id LAA02999; Wed, 3 Oct 2001 11:20:22 -0400 (EDT) Resent-Date: Wed, 3 Oct 2001 11:20:22 -0400 (EDT) Resent-Message-Id: <200110031520.LAA02999@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id LAA02943 for ; Wed, 3 Oct 2001 11:20:14 -0400 (EDT) Received: from greenbytes.de (mail.greenbytes.de [217.5.201.10] (may be forged)) by tux.w3.org (8.9.3/8.9.3) with ESMTP id LAA11715 for ; Wed, 3 Oct 2001 11:20:14 -0400 Received: from lisa [192.168.1.2] by greenbytes.de [217.5.201.11] with SMTP (MDaemon.v3.5.3.R) for ; Wed, 03 Oct 2001 17:20:09 +0200 From: "Julian F. Reschke" To: "Webdav WG" , Date: Wed, 3 Oct 2001 17:20:07 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-reply-to: <3906C56A7BD1F54593344C05BD1374B104653341@SUS-MA1IT01> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal X-MDRemoteIP: 192.168.1.2 X-Return-Path: julian.reschke@greenbytes.de X-MDaemon-Deliver-To: w3c-dist-auth@w3c.org Subject: Content-Type / charset in RFC2518, deltaV and ACL specs Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5384 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi, I just noticed that in their examples, all these specs specify: Content-type: text/xml; charset="utf-8" However, as far as I understand RFC2616 (section 3.6 and section 3.7), and from experience when setting the encoding in Java servlets, it should be Content-type: text/xml; charset=utf-8 (so the value is not quoted). In general, I think it really doesn't make sense to specify character sets in specs (unless the spec is talking about encodings, of course). The spec contains characters after all (not an octet stream). Of course this also affects XML declarations in the specs. Julian From w3c-dist-auth-request@w3.org Wed Oct 3 12:57:37 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22219 for ; Wed, 3 Oct 2001 12:57:37 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA08951; Wed, 3 Oct 2001 12:54:43 -0400 (EDT) Resent-Date: Wed, 3 Oct 2001 12:54:43 -0400 (EDT) Resent-Message-Id: <200110031654.MAA08951@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id MAA08926 for ; Wed, 3 Oct 2001 12:54:39 -0400 (EDT) Received: from sus-ma1it00.rational.com (ext-37016.rational.com [192.229.37.16]) by tux.w3.org (8.9.3/8.9.3) with SMTP id MAA24617 for ; Wed, 3 Oct 2001 12:54:39 -0400 Received: from 192.168.215.70 by sus-ma1it00.rational.com (InterScan E-Mail VirusWall NT); Wed, 03 Oct 2001 12:53:34 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id <4D3CPFKY>; Wed, 3 Oct 2001 12:53:34 -0400 Message-ID: <3906C56A7BD1F54593344C05BD1374B103F8AC2D@SUS-MA1IT01> From: "Clemm, Geoff" To: Webdav WG , ietf-dav-versioning@w3.org Date: Wed, 3 Oct 2001 12:53:32 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Content-Type / charset in RFC2518, deltaV and ACL specs Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5385 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Actually, section 3.6 states that a "value" is either a "token" or a "quoted-string", so the examples in 2518 are syntactically valid. But that doesn't mean that they are acceptable to common implementations, so it's a fair question. There is time to strip off the quotes in the DeltaV spec in the final editing pass, but that is likely to be soon, so if anyone feels strongly about this, please let me know ASAP. I don't follow your rationale for why examples in specs should not contain encoding information. An example is supposed to accurately reflect what the client should send and expect to receive, and a client should send encoding information in a charset parameter in the Content-Type header. Cheers, Geoff -----Original Message----- From: Julian F. Reschke [mailto:julian.reschke@greenbytes.de] Sent: Wednesday, October 03, 2001 11:20 AM To: Webdav WG; ietf-dav-versioning@w3.org Subject: Content-Type / charset in RFC2518, deltaV and ACL specs Hi, I just noticed that in their examples, all these specs specify: Content-type: text/xml; charset="utf-8" However, as far as I understand RFC2616 (section 3.6 and section 3.7), and from experience when setting the encoding in Java servlets, it should be Content-type: text/xml; charset=utf-8 (so the value is not quoted). In general, I think it really doesn't make sense to specify character sets in specs (unless the spec is talking about encodings, of course). The spec contains characters after all (not an octet stream). Of course this also affects XML declarations in the specs. Julian From w3c-dist-auth-request@w3.org Wed Oct 3 13:38:57 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23456 for ; Wed, 3 Oct 2001 13:38:57 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA10948; Wed, 3 Oct 2001 13:35:58 -0400 (EDT) Resent-Date: Wed, 3 Oct 2001 13:35:58 -0400 (EDT) Resent-Message-Id: <200110031735.NAA10948@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id NAA10928 for ; Wed, 3 Oct 2001 13:35:54 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id NAA29701 for ; Wed, 3 Oct 2001 13:35:54 -0400 Received: (qmail 5165 invoked by uid 0); 3 Oct 2001 17:35:31 -0000 Received: from pd953575a.dip.t-dialin.net (HELO lisa) (217.83.87.90) by mail.gmx.net (mp007-rz3) with SMTP; 3 Oct 2001 17:35:31 -0000 From: "Julian Reschke" To: "Webdav WG" Date: Wed, 3 Oct 2001 19:36:27 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-reply-to: <3906C56A7BD1F54593344C05BD1374B103F8AC2D@SUS-MA1IT01> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Subject: RE: Content-Type / charset in RFC2518, deltaV and ACL specs Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5386 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 8bit Geoff, maybe it's obvious for people who constantly deal with these issues, but many people blindly copy from examples, not knowing exactly what they do... Of course properly declaring the charset is a Good Thing (and often necessary), but then maybe the spec should come with a warning that the charset declarations in the examples are just that -- examples -- and must match the *actual* encoding used for the request/response bodies. For instance: Münster may look completely innocent -- until it appears within something which actually is encoded in a different (and incompatible) charset. I guess this mail will be transferred in some ISO encoding, so the XML fragment wouldn't parse when given byte-by-byte to an XML parser, right?. The examples in the specs generally don't need anything outside the ASCII range, so maybe it would be wiser to leave out the encoding declarations (and have a separate paragraph in RFC2518++ explain the issue). (sorry for cross-posting to "both" lists). Julian > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff > Sent: Wednesday, October 03, 2001 6:54 PM > To: Webdav WG; ietf-dav-versioning@w3.org > Subject: RE: Content-Type / charset in RFC2518, deltaV and ACL specs > > > Actually, section 3.6 states that a "value" is either a "token" or > a "quoted-string", so the examples in 2518 are syntactically valid. > But that doesn't mean that they are acceptable to common implementations, > so it's a fair question. > > There is time to strip off the quotes in the DeltaV spec in the final > editing pass, but that is likely to be soon, so if anyone feels strongly > about this, please let me know ASAP. > > I don't follow your rationale for why examples in specs should not > contain encoding information. An example is supposed to accurately > reflect what the client should send and expect to receive, and a client > should send encoding information in a charset parameter in the > Content-Type header. > > Cheers, > Geoff > > > -----Original Message----- > From: Julian F. Reschke [mailto:julian.reschke@greenbytes.de] > Sent: Wednesday, October 03, 2001 11:20 AM > To: Webdav WG; ietf-dav-versioning@w3.org > Subject: Content-Type / charset in RFC2518, deltaV and ACL specs > > > Hi, > > I just noticed that in their examples, all these specs specify: > > Content-type: text/xml; charset="utf-8" > > However, as far as I understand RFC2616 (section 3.6 and section 3.7), and > >from experience when setting the encoding in Java servlets, it should be > > Content-type: text/xml; charset=utf-8 > > (so the value is not quoted). > > In general, I think it really doesn't make sense to specify character sets > in specs (unless the spec is talking about encodings, of course). The spec > contains characters after all (not an octet stream). Of course this also > affects XML declarations in the specs. > > Julian > > From w3c-dist-auth-request@w3.org Wed Oct 3 14:01:50 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAB24252 for ; Wed, 3 Oct 2001 14:01:50 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA11732; Wed, 3 Oct 2001 13:59:58 -0400 (EDT) Resent-Date: Wed, 3 Oct 2001 13:59:58 -0400 (EDT) Resent-Message-Id: <200110031759.NAA11732@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id NAA11712 for ; Wed, 3 Oct 2001 13:59:54 -0400 (EDT) Received: from sus-ma1it00.rational.com (ext-37016.rational.com [192.229.37.16]) by tux.w3.org (8.9.3/8.9.3) with SMTP id NAA00506 for ; Wed, 3 Oct 2001 13:59:53 -0400 Received: from 192.168.215.70 by sus-ma1it00.rational.com (InterScan E-Mail VirusWall NT); Wed, 03 Oct 2001 13:58:54 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id <4D3CPL6P>; Wed, 3 Oct 2001 13:58:54 -0400 Message-ID: <3906C56A7BD1F54593344C05BD1374B103F8AC33@SUS-MA1IT01> From: "Clemm, Geoff" To: Webdav WG Date: Wed, 3 Oct 2001 13:58:52 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www19.w3.org id NAA11712 Subject: RE: Content-Type / charset in RFC2518, deltaV and ACL specs Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5387 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 8bit I think there are good arguments on either side, but I personally believe that the risk of someone blindly copying the example and leaving out a needed charset parameter or an encoding attribute are higher than the risk of someone using a non-UTF-8 encoding, but leaving in the UTF-8 charset parameter and encoding attributes from the example. But I don't feel strongly about this, so if there is working group consensus that these charset/encoding info should be stripped from the examples (or have their values be replaced by "xxxx"), I'm happy to make that change to the DeltaV spec (assuming that consensus is reached before the author 48 hour period has expired :-). Cheers, Geoff -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de] Sent: Wednesday, October 03, 2001 1:36 PM To: Webdav WG Subject: RE: Content-Type / charset in RFC2518, deltaV and ACL specs Geoff, maybe it's obvious for people who constantly deal with these issues, but many people blindly copy from examples, not knowing exactly what they do... Of course properly declaring the charset is a Good Thing (and often necessary), but then maybe the spec should come with a warning that the charset declarations in the examples are just that -- examples -- and must match the *actual* encoding used for the request/response bodies. For instance: Münster may look completely innocent -- until it appears within something which actually is encoded in a different (and incompatible) charset. I guess this mail will be transferred in some ISO encoding, so the XML fragment wouldn't parse when given byte-by-byte to an XML parser, right?. The examples in the specs generally don't need anything outside the ASCII range, so maybe it would be wiser to leave out the encoding declarations (and have a separate paragraph in RFC2518++ explain the issue). (sorry for cross-posting to "both" lists). Julian > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff > Sent: Wednesday, October 03, 2001 6:54 PM > To: Webdav WG; ietf-dav-versioning@w3.org > Subject: RE: Content-Type / charset in RFC2518, deltaV and ACL specs > > > Actually, section 3.6 states that a "value" is either a "token" or > a "quoted-string", so the examples in 2518 are syntactically valid. > But that doesn't mean that they are acceptable to common implementations, > so it's a fair question. > > There is time to strip off the quotes in the DeltaV spec in the final > editing pass, but that is likely to be soon, so if anyone feels strongly > about this, please let me know ASAP. > > I don't follow your rationale for why examples in specs should not > contain encoding information. An example is supposed to accurately > reflect what the client should send and expect to receive, and a client > should send encoding information in a charset parameter in the > Content-Type header. > > Cheers, > Geoff > > > -----Original Message----- > From: Julian F. Reschke [mailto:julian.reschke@greenbytes.de] > Sent: Wednesday, October 03, 2001 11:20 AM > To: Webdav WG; ietf-dav-versioning@w3.org > Subject: Content-Type / charset in RFC2518, deltaV and ACL specs > > > Hi, > > I just noticed that in their examples, all these specs specify: > > Content-type: text/xml; charset="utf-8" > > However, as far as I understand RFC2616 (section 3.6 and section 3.7), and > >from experience when setting the encoding in Java servlets, it should be > > Content-type: text/xml; charset=utf-8 > > (so the value is not quoted). > > In general, I think it really doesn't make sense to specify character sets > in specs (unless the spec is talking about encodings, of course). The spec > contains characters after all (not an octet stream). Of course this also > affects XML declarations in the specs. > > Julian > > From w3c-dist-auth-request@w3.org Wed Oct 3 14:06:47 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24452 for ; Wed, 3 Oct 2001 14:06:46 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA12057; Wed, 3 Oct 2001 14:04:56 -0400 (EDT) Resent-Date: Wed, 3 Oct 2001 14:04:56 -0400 (EDT) Resent-Message-Id: <200110031804.OAA12057@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id OAA12034 for ; Wed, 3 Oct 2001 14:04:49 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id OAA01542 for ; Wed, 3 Oct 2001 14:04:48 -0400 Received: (qmail 24153 invoked by uid 0); 3 Oct 2001 18:04:14 -0000 Received: from pd953575a.dip.t-dialin.net (HELO lisa) (217.83.87.90) by mail.gmx.net (mp007-rz3) with SMTP; 3 Oct 2001 18:04:14 -0000 From: "Julian Reschke" To: "Clemm, Geoff" , "Webdav WG" Date: Wed, 3 Oct 2001 20:05:10 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-reply-to: <3906C56A7BD1F54593344C05BD1374B103F8AC33@SUS-MA1IT01> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Subject: RE: Content-Type / charset in RFC2518, deltaV and ACL specs Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5388 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 8bit I think making it "xxx" is an excellent idea. > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff > Sent: Wednesday, October 03, 2001 7:59 PM > To: Webdav WG > Subject: RE: Content-Type / charset in RFC2518, deltaV and ACL specs > > > I think there are good arguments on either side, but I personally > believe that the risk of someone blindly copying the example and > leaving out a needed charset parameter or an encoding attribute are > higher than the risk of someone using a non-UTF-8 encoding, but leaving > in the UTF-8 charset parameter and encoding attributes from the example. > > But I don't feel strongly about this, so if there is working > group consensus > that these charset/encoding info should be stripped from the examples > (or have their values be replaced by "xxxx"), I'm happy to make > that change > to the DeltaV spec (assuming that consensus is reached before the > author 48 hour period has expired :-). > > Cheers, > Geoff > > -----Original Message----- > From: Julian Reschke [mailto:julian.reschke@gmx.de] > Sent: Wednesday, October 03, 2001 1:36 PM > To: Webdav WG > Subject: RE: Content-Type / charset in RFC2518, deltaV and ACL specs > > > Geoff, > > maybe it's obvious for people who constantly deal with these issues, but > many people blindly copy from examples, not knowing exactly what > they do... > Of course properly declaring the charset is a Good Thing (and often > necessary), but then maybe the spec should come with a warning that the > charset declarations in the examples are just that -- examples -- and must > match the *actual* encoding used for the request/response bodies. > > For instance: > > > Münster > > may look completely innocent -- until it appears within something which > actually is encoded in a different (and incompatible) charset. I > guess this > mail will be transferred in some ISO encoding, so the XML > fragment wouldn't > parse when given byte-by-byte to an XML parser, right?. > > The examples in the specs generally don't need anything outside the ASCII > range, so maybe it would be wiser to leave out the encoding declarations > (and have a separate paragraph in RFC2518++ explain the issue). > > (sorry for cross-posting to "both" lists). > > Julian > > > -----Original Message----- > > From: w3c-dist-auth-request@w3.org > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff > > Sent: Wednesday, October 03, 2001 6:54 PM > > To: Webdav WG; ietf-dav-versioning@w3.org > > Subject: RE: Content-Type / charset in RFC2518, deltaV and ACL specs > > > > > > Actually, section 3.6 states that a "value" is either a "token" or > > a "quoted-string", so the examples in 2518 are syntactically valid. > > But that doesn't mean that they are acceptable to common > implementations, > > so it's a fair question. > > > > There is time to strip off the quotes in the DeltaV spec in the final > > editing pass, but that is likely to be soon, so if anyone feels strongly > > about this, please let me know ASAP. > > > > I don't follow your rationale for why examples in specs should not > > contain encoding information. An example is supposed to accurately > > reflect what the client should send and expect to receive, and a client > > should send encoding information in a charset parameter in the > > Content-Type header. > > > > Cheers, > > Geoff > > > > > > -----Original Message----- > > From: Julian F. Reschke [mailto:julian.reschke@greenbytes.de] > > Sent: Wednesday, October 03, 2001 11:20 AM > > To: Webdav WG; ietf-dav-versioning@w3.org > > Subject: Content-Type / charset in RFC2518, deltaV and ACL specs > > > > > > Hi, > > > > I just noticed that in their examples, all these specs specify: > > > > Content-type: text/xml; charset="utf-8" > > > > However, as far as I understand RFC2616 (section 3.6 and > section 3.7), and > > >from experience when setting the encoding in Java servlets, it > should be > > > > Content-type: text/xml; charset=utf-8 > > > > (so the value is not quoted). > > > > In general, I think it really doesn't make sense to specify > character sets > > in specs (unless the spec is talking about encodings, of > course). The spec > > contains characters after all (not an octet stream). Of course this also > > affects XML declarations in the specs. > > > > Julian > > > > > From w3c-dist-auth-request@w3.org Wed Oct 3 15:20:20 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26929 for ; Wed, 3 Oct 2001 15:20:19 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA16803; Wed, 3 Oct 2001 15:17:05 -0400 (EDT) Resent-Date: Wed, 3 Oct 2001 15:17:05 -0400 (EDT) Resent-Message-Id: <200110031917.PAA16803@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id PAA16755 for ; Wed, 3 Oct 2001 15:16:57 -0400 (EDT) Received: from cats.ucsc.edu (rumpleteazer.ucsc.edu [128.114.129.45]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id PAA11054 for ; Wed, 3 Oct 2001 15:16:57 -0400 Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177]) by cats.ucsc.edu (8.9.3/8.8.4.cats-athena) with SMTP id MAA07598; Wed, 3 Oct 2001 12:16:46 -0700 (PDT) From: "Jim Whitehead" To: "Webdav WG" , Date: Wed, 3 Oct 2001 12:13:15 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-reply-to: <3906C56A7BD1F54593344C05BD1374B103F8AC33@SUS-MA1IT01> Importance: Normal Subject: RE: Content-Type / charset in RFC2518, deltaV and ACL specs Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5389 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > I think there are good arguments on either side, but I personally > believe that the risk of someone blindly copying the example and > leaving out a needed charset parameter or an encoding attribute are > higher than the risk of someone using a non-UTF-8 encoding, but leaving > in the UTF-8 charset parameter and encoding attributes from the example. Before we placed the charset parameter in *every* example of the specification, I found that implementations were not including the charset parameter at all. Since this would make it very difficult to correctly implement i18n features later, I added the charset parameter to all examples. I still don't think that all implementations use the charset parameter, or use it correctly, but I do believe it helped. One thing I learned from the DAV specification was the large normative effect the examples have. Developers sometimes code to the examples, not the specification. > But I don't feel strongly about this, so if there is working > group consensus > that these charset/encoding info should be stripped from the examples > (or have their values be replaced by "xxxx"), I'm happy to make > that change > to the DeltaV spec (assuming that consensus is reached before the > author 48 hour period has expired :-). I feel very strongly that the charset values should be left in the DeltaV specification, with their current values. This is the form the specification was approved as, and the form in which it passed last call. I would have raised an issue during last call if these values were not in the specification. Furthermore, RFC 3023 ("XML Media Types") states that use of the charset parameter is STRONGLY RECOMMENDED, and so if we do not use the charset parameter, the burden of explanation clearly rests on showing why it is better to omit it, than to include it. - Jim From w3c-dist-auth-request@w3.org Wed Oct 3 15:42:40 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27344 for ; Wed, 3 Oct 2001 15:42:40 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA17555; Wed, 3 Oct 2001 15:40:44 -0400 (EDT) Resent-Date: Wed, 3 Oct 2001 15:40:44 -0400 (EDT) Resent-Message-Id: <200110031940.PAA17555@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id PAA17521 for ; Wed, 3 Oct 2001 15:40:39 -0400 (EDT) Received: from greenbytes.de (mail.greenbytes.de [217.5.201.10] (may be forged)) by tux.w3.org (8.9.3/8.9.3) with ESMTP id PAA13432 for ; Wed, 3 Oct 2001 15:40:39 -0400 Received: from lisa [192.168.1.2] by greenbytes.de [217.5.201.11] with SMTP (MDaemon.v3.5.3.R) for ; Wed, 03 Oct 2001 21:40:53 +0200 From: "Julian F. Reschke" To: "Jim Whitehead" , "Webdav WG" , Date: Wed, 3 Oct 2001 21:40:53 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-reply-to: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal X-MDRemoteIP: 192.168.1.2 X-Return-Path: julian.reschke@greenbytes.de X-MDaemon-Deliver-To: w3c-dist-auth@w3c.org Subject: RE: Content-Type / charset in RFC2518, deltaV and ACL specs Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5390 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: ietf-dav-versioning-request@w3.org > [mailto:ietf-dav-versioning-request@w3.org]On Behalf Of Jim Whitehead > Sent: Wednesday, October 03, 2001 9:13 PM > To: Webdav WG; ietf-dav-versioning@w3.org > Subject: RE: Content-Type / charset in RFC2518, deltaV and ACL specs > > > > > I think there are good arguments on either side, but I personally > > believe that the risk of someone blindly copying the example and > > leaving out a needed charset parameter or an encoding attribute are > > higher than the risk of someone using a non-UTF-8 encoding, but leaving > > in the UTF-8 charset parameter and encoding attributes from the example. > > Before we placed the charset parameter in *every* example of the > specification, I found that implementations were not including the charset > parameter at all. Since this would make it very difficult to correctly > implement i18n features later, I added the charset parameter to all > examples. I still don't think that all implementations use the charset > parameter, or use it correctly, but I do believe it helped. Wait-a-second. Do you say that there is a *requirement* to declare the charset if we have text/xml, and the actual encoding is UTF-8 (or a subset of that)? That would be new to me. > One thing I learned from the DAV specification was the large normative > effect the examples have. Developers sometimes code to the examples, not > the specification. Correct. Therefore I'd say put in an "xxx" both in the header and in the XML declaration, and add a clear description about when and how it needs to be set (the answer doesn't seem to be obvious after all...). > I feel very strongly that the charset values should be left in the DeltaV > specification, with their current values. This is the form the > specification > was approved as, and the form in which it passed last call. I would have > raised an issue during last call if these values were not in the > specification. A good point, but this shouldn't stop us from discussing it for future specs. > Furthermore, RFC 3023 ("XML Media Types") states that use of the charset > parameter is STRONGLY RECOMMENDED, and so if we do not use the charset > parameter, the burden of explanation clearly rests on showing why it is > better to omit it, than to include it. I agree that the specs should conform to RFC3023. It seems that RFC3023 uses the quoted charset value as well. This seems to conflict with my experience what the servlet API expects... From w3c-dist-auth-request@w3.org Thu Oct 4 02:40:19 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27909 for ; Thu, 4 Oct 2001 02:40:19 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id CAA11512; Thu, 4 Oct 2001 02:38:22 -0400 (EDT) Resent-Date: Thu, 4 Oct 2001 02:38:22 -0400 (EDT) Resent-Message-Id: <200110040638.CAA11512@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id CAA11471 for ; Thu, 4 Oct 2001 02:38:12 -0400 (EDT) Received: from adobe.com (smtp-relay-2.adobe.com [192.150.11.2]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id CAA04710 for ; Thu, 4 Oct 2001 02:38:11 -0400 Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by adobe.com (1.0.0/8.11.4) with ESMTP id f946b2517354 for ; Wed, 3 Oct 2001 23:37:02 -0700 (PDT) Received: from mailsj-v1.corp.adobe.com (mailsj-dev.corp.adobe.com [153.32.1.192]) by inner-relay-1.corp.adobe.com (8.11.4/8.11.4) with ESMTP id f946bmS10804 for ; Wed, 3 Oct 2001 23:37:48 -0700 (PDT) Received: from larrypad ([130.248.188.118]) by mailsj-v1.corp.adobe.com (Netscape Messaging Server 4.15 v1 Jul 11 2001 16:32:57) with SMTP id GKO52N00.3YF; Wed, 3 Oct 2001 23:37:35 -0700 From: "Larry Masinter - LMM@acm.org" To: "Clemm, Geoff" , "Webdav WG" , Date: Wed, 3 Oct 2001 23:37:12 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <3906C56A7BD1F54593344C05BD1374B103F8AC2D@SUS-MA1IT01> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Subject: RE: Content-Type / charset in RFC2518, deltaV and ACL specs Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5391 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit I think that you should limit unnecessary changes. Quoted parameters are valid, and removing things in examples that might not work in some broken implementations doesn't seem like it's a "necessary change". > In general, I think it really doesn't make sense to specify character sets > in specs (unless the spec is talking about encodings, of course). The spec > contains characters after all (not an octet stream). Of course this also > affects XML declarations in the specs. The charset parameter is strongly recommended in RFC 3023. From w3c-dist-auth-request@w3.org Thu Oct 4 04:15:28 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01460 for ; Thu, 4 Oct 2001 04:15:28 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id EAA14217; Thu, 4 Oct 2001 04:13:18 -0400 (EDT) Resent-Date: Thu, 4 Oct 2001 04:13:18 -0400 (EDT) Resent-Message-Id: <200110040813.EAA14217@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id EAA14166 for ; Thu, 4 Oct 2001 04:13:07 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id EAA12251 for ; Thu, 4 Oct 2001 04:13:06 -0400 Received: (qmail 25910 invoked by uid 0); 4 Oct 2001 07:52:47 -0000 Received: from pd9535f3c.dip.t-dialin.net (HELO lisa) (217.83.95.60) by mail.gmx.net (mp006-rz3) with SMTP; 4 Oct 2001 07:52:47 -0000 From: "Julian Reschke" To: "Larry Masinter - LMM@acm.org" , "Clemm, Geoff" , "Webdav WG" , Date: Thu, 4 Oct 2001 09:53:37 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Subject: RE: Content-Type / charset in RFC2518, deltaV and ACL specs Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5392 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Larry Masinter - > LMM@acm.org > Sent: Thursday, October 04, 2001 8:37 AM > To: Clemm, Geoff; Webdav WG; ietf-dav-versioning@w3.org > Subject: RE: Content-Type / charset in RFC2518, deltaV and ACL specs > > > I think that you should limit unnecessary changes. Quoted > parameters are valid, and removing things in examples that > might not work in some broken implementations doesn't > seem like it's a "necessary change". So, could you please clarify some more? 1) Both unquoted and quoted parameters are valid (according to HTTP 1.1)? 2) RFC3023 uses quoted parameters in it's examples, but unquoted parameters would be OK as well? 3) Known broken implementations regarding quoted parameters are: ... > > In general, I think it really doesn't make sense to specify > character sets > > in specs (unless the spec is talking about encodings, of > course). The spec > > contains characters after all (not an octet stream). Of course this also > > affects XML declarations in the specs. > > The charset parameter is strongly recommended in > RFC 3023. Yes. But my point is that an encoding declaration is only meaningful for a given octet stream -- which we don't have in an example in an RFC. If these declarations are in, they should come with a warning that this example assumes that the request/response body actually *is* encoded in UTF-8 (or a subset of it), and that otherwise it must match the actual encoding. BTW: as XML parsers may reject any encoding other than Unicode (and subsets), I'd also propose to add wording that request/response bodies SHOULD be encoded in one of the standard XML encodings (or refer to a section in RFC3023 that says that). I've seen "WebDAV" implementations that send reponse bodies in (properly-declared) Windows encodings (it is Hotmail) :-) From w3c-dist-auth-request@w3.org Thu Oct 4 07:06:33 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05603 for ; Thu, 4 Oct 2001 07:06:32 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id HAA20813; Thu, 4 Oct 2001 07:04:40 -0400 (EDT) Resent-Date: Thu, 4 Oct 2001 07:04:40 -0400 (EDT) Resent-Message-Id: <200110041104.HAA20813@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id HAA20793 for ; Thu, 4 Oct 2001 07:04:31 -0400 (EDT) Received: from kurgan.lyra.org (test.webdav.org [198.144.203.199]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id HAA26980 for ; Thu, 4 Oct 2001 07:04:30 -0400 Received: (from gstein@localhost) by kurgan.lyra.org (8.9.3/8.9.3) id EAA31552; Thu, 4 Oct 2001 04:08:45 -0700 X-Authentication-Warning: kurgan.lyra.org: gstein set sender to gstein@lyra.org using -f Date: Thu, 4 Oct 2001 04:08:45 -0700 From: Greg Stein To: dav-dev@lyra.org, w3c-dist-auth@w3.org Message-ID: <20011004040844.K24906@lyra.org> Mail-Followup-To: dav-dev@lyra.org, w3c-dist-auth@w3.org References: <228C5EBB26701542946C14D5205AE6D5011F7189@pnlmse08.pnl.gov> <200110032117.RAA21205@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <200110032117.RAA21205@localhost.localdomain>; from bswihart@timesnews.net on Wed, Oct 03, 2001 at 05:08:40PM -0400 X-URL: http://www.lyra.org/greg/ Subject: new mailing list? (was: [dav-dev] Collaborative Environments) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5393 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: On Wed, Oct 03, 2001 at 05:08:40PM -0400, Ben Swihart wrote: >... > I would gladly join and participate in this new list. > > dav-ideas@lyra.org? >... > On Wednesday, October 3, 2001, at 04:03 PM, Stephan, Eric G wrote: > > > I agree that it would be nice to have another mail list for WebDAV idea > > sharing. > > To us, WebDAV is a tremendous gift and opens many doors for the scientific > > community. I think it would be a blast to exchange these types of ideas. >... Well, the use of @lyra.org is completely historical. At that magical point in the future, when I have all the time needed, I'd be moving dav-dev@lyra.org to mod_dav@webdav.org or something. dav-announce@lyra.org will become announce@webdav.org. So... I'd say the mailing list should really be: ideas@webdav.org That said: I'm a bit unclear on its charter, purpose, etc. But then again, I don't need to be. :-) A *volunteer* can be that person. Ben, Eric? Somebody else? I would create a Mailman mailing list, set you to be the admin for it, and let you set up the description and other parameters for the mailing list. Further, it would be great for somebody to maintain a subsection on webdav.org that contains this information. Maybe /papers/ideas or /other/ideas or something. Suggestions and volunteers? Lastly, I need to add a link/page on webdav.org to the various mailing lists related to webdav. This would be included among those. Cheers, -g -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Thu Oct 4 07:23:55 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05909 for ; Thu, 4 Oct 2001 07:23:55 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id HAA21780; Thu, 4 Oct 2001 07:22:12 -0400 (EDT) Resent-Date: Thu, 4 Oct 2001 07:22:12 -0400 (EDT) Resent-Message-Id: <200110041122.HAA21780@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id HAA21757 for ; Thu, 4 Oct 2001 07:22:02 -0400 (EDT) Received: from Mail.MeepZor.Com (IDENT:root@i.meepzor.com [204.146.167.214]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id HAA28444 for ; Thu, 4 Oct 2001 07:22:02 -0400 Received: from Golux.Com (dsl-64-192-128-105.telocity.com [64.192.128.105]) by Mail.MeepZor.Com (8.8.7/8.8.7) with ESMTP id HAA25065; Thu, 4 Oct 2001 07:21:44 -0400 Message-ID: <3BBC464C.307CF0AF@Golux.Com> Date: Thu, 04 Oct 2001 07:21:48 -0400 From: Rodent of Unusual Size Organization: The Apache Software Foundation X-Mailer: Mozilla 4.76 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Greg Stein CC: dav-dev@lyra.org, w3c-dist-auth@w3.org References: <228C5EBB26701542946C14D5205AE6D5011F7189@pnlmse08.pnl.gov> <200110032117.RAA21205@localhost.localdomain> <20011004040844.K24906@lyra.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: new mailing list? (was: [dav-dev] Collaborative Environments) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5394 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Greg Stein wrote: > > I would create a Mailman mailing list Just as long as you set Reply-to as the list address.. (ducks and covers ;-) -- #ken P-)} Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/ Author, developer, opinionist http://Apache-Server.Com/ "All right everyone! Step away from the glowing hamburger!" From w3c-dist-auth-request@w3.org Fri Oct 5 01:59:27 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04442 for ; Fri, 5 Oct 2001 01:59:27 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id BAA19555; Fri, 5 Oct 2001 01:57:27 -0400 (EDT) Resent-Date: Fri, 5 Oct 2001 01:57:27 -0400 (EDT) Resent-Message-Id: <200110050557.BAA19555@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id BAA19501 for ; Fri, 5 Oct 2001 01:57:14 -0400 (EDT) Received: from infonuovo.com (ntmail1.lightrealm.com [216.122.10.2]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id BAA17881 for ; Fri, 5 Oct 2001 01:57:13 -0400 Received: from centro (ts015d09.sea-wa.concentric.net [209.31.210.213]) by infonuovo.com (8.8.7/8.8.5) with SMTP id WAA06238 for ; Thu, 4 Oct 2001 22:57:11 -0700 (PDT) X-Authentication-Warning: infonuovo.com: orcmid owned process doing -bs Reply-To: From: "Dennis E. Hamilton" To: "WebDAV Working Group" Date: Thu, 4 Oct 2001 22:57:10 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: PropReg: Probing for Property-Registration Requirements Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5395 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 8bit Me again! I have been lurking (well, cowering) while wondering exactly what is called for in terms of WebDAV Property Registrations. Although my search for relevant materials in the WebDAV archives is incomplete, here is how it looks to me: A. IDEAS FOR SOLUTIONS 1. There are ideas about how to store information about properties. 2. There are ideas and some effort on how to store property information in a database or similar collection. 3. There are ideas about marshalling property values that might have crossover to the description of property values. There are also ideas about constraints on property registration (e.g., it should be simple, not require central authority, etc.). There are also existing metadata description, interchange, and repository standards which might have to be accommodated in some way. B. WHAT PROBLEM IS SUPPOSED TO BE SOLVED? What I haven't found is the community thinking on *WHY* one would register properties, what would be registered, and who would use it (people and machines), and for what. That is, what problem(s) is property registration intended to solve, and is there consensus on the problem set? I invite discussion at this level before going too far into formulating an approach. C. A REQUIREMENTS SURVEY Here are survey questions. I've sketched characteristics of a property registration scheme in terms of end-to-end use (registrant to user). Please say what you consider required and what you consider unnecessary, along with any other thoughts you have. I will distill a requirements sketch from the responses and echo the key ideas for further consideration and refinement. I am not being rigorous about requirements versus constraints and solutions. I haven't looked for metrics on satisfaction of requirements. I'm probing for informal use cases as a point of departure for now. - - - THE QUESTIONS - - - D. REGISTERING A WEBDAV PROPERTY 1. Registration identifies the property and the authoritative source of further information? The source is located by URI? The source is located by non-Internet means? Is it necessary to associate a property with some authority over its definition? The authoritative source and the property are identified independently? 2. Does the registration make available a definition of the property? Is the definition amenable to human use? Mechanical usage? Both? In combination? What purpose is served by making the definition available? 3. Is the registration information submitted to third parties for retention and retrieval by anyone who chooses to discover the established use of the identified property? Might it be found on WebDAV servers that support the property? 4. What groups of people (by rôle) are required to be able to create and submit/register property-registration information? (This is distinct from being able to configure a server and/or client to support such a property.) E. USING REGISTRATION INFORMATION 1. Are property registrations intended to be useable by clients while interacting with a DAV server that supports a particular property? 2. If a property can be set by a client (even if live), does the property registration provide a. format conditions (syntax) for the value of the property? b. descriptive or other information with regard to the semantics of the value? c. indication of interdependencies with other properties? I think the key question is how far should the property description go to equip a knowledgeable person, in conjunction with flexible client software, to be able to specify a value for the property that (i) will be accepted by the server and (ii) is appropriate in the context of the semantics of the property? 3. Is it important to provide, in the registration information, customization descriptive presentations for users who are competent in different native languages? 4. How important is it to have the property-registration information provide sufficient information so that an user can intelligibly interpret a value for that property as presented by a flexible client? (By flexible is meant a client that allows use of properties other than ones it was specifically designed to accommodate.) 5. What groups of people (by rôle) are required to be able to find and use property-registration information? 6. Is property registration information to be attractive for configuration of a server to support the property (apart from mapping to an implementation and recognizing that no DAV server is required to support such an approach)? F. INTERCHANGE OF PROPERTY-REGISTRATION INFORMATION [This seems to be all about constraints. Ah well ...] a. Should the property-registration information be in a structured, mechanically-processable form? b. Must the property-registration information be easily rendered for human comprehension and review? c. Should property registrations be a resource type for storage in DAV itself? An existing resource type? d. How easy must it be to carry the property-registration information in plain text, in files, and in simple serial data streams? Embedded in structured information? -- Dennis Dennis E. Hamilton AIIM DMware Technical Coordinator ------------------ mailto:dennis.hamilton@acm.org tel. +1-206-932-6970 http://www.dmware.org cel. +1-206-779-9430 ODMA Support http://www.infonuovo.com/odma From w3c-dist-auth-request@w3.org Fri Oct 5 05:41:18 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17747 for ; Fri, 5 Oct 2001 05:41:18 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id FAA27484; Fri, 5 Oct 2001 05:38:49 -0400 (EDT) Resent-Date: Fri, 5 Oct 2001 05:38:49 -0400 (EDT) Resent-Message-Id: <200110050938.FAA27484@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id FAA27460 for ; Fri, 5 Oct 2001 05:38:38 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id FAA02655 for ; Fri, 5 Oct 2001 05:38:37 -0400 Received: (qmail 11143 invoked by uid 0); 5 Oct 2001 09:38:24 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mp005-rz3) with SMTP; 5 Oct 2001 09:38:24 -0000 From: "Julian Reschke" To: "WebDAV Working Group" Date: Fri, 5 Oct 2001 11:39:18 +0200 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0000_01C14D92.5E1409A0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Subject: PROPFIND/allprop/include proposal Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5396 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0000_01C14D92.5E1409A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Hi, below is a formalized version of the allprop extension we discussed some weeks ago (to include ACL/deltaV properties that would not be reported otherwise). The intent is to have a working paper that a) can be developed for RFC2518++, b) can be used for documentation purposes. Julian -- Network Working Group J. Reschke Internet-Draft S. Eissing Expires: April 5, 2002 greenbytes October 5, 2001 Including additional properties in WebDAV PROPFIND/allprop requests draft-reschke-webdav-allprop-include-00 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 5, 2002. Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved. Abstract Recent specifications extending the Web Distributed Authoring Protocol (WebDAV) restrict the set of properties returned automatically upon a PROPFIND/allprop request. This specification defines a method to add specific properties to the set of properties returned upon PROPFIND/allprop. Distribution of this document is unlimited. Please send comments to the Distributed Authoring and Versioning (WebDAV) working group at w3c-dist-auth@w3.org[1], which may be joined by sending a message with subject "subscribe" to w3c-dist-auth-request@w3.org[2]. Reschke & Eissing Expires April 5, 2002 [Page 1] Internet-Draft WebDAV PROPFIND/allprop/include October 2001 Discussions of the WEBDAV working group are archived at URL: http:// lists.w3.org/Archives/Public/w3c-dist-auth/. Table of Contents 1. Notational Conventions . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Extensions to PROPFIND/allprop . . . . . . . . . . . . . . . . 5 3.1 Example for PROPFIND/allprop/include with extended server . . 5 3.2 Example for PROPFIND/allprop/include with non-extended server 7 4. Changes to WebDAV DTD . . . . . . . . . . . . . . . . . . . . 9 5. Compatibility Considerations . . . . . . . . . . . . . . . . . 10 6. Internationalization Considerations . . . . . . . . . . . . . 11 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 8. Copyright . . . . . . . . . . . . . . . . . . . . . . . . . . 13 9. Intellectual Property . . . . . . . . . . . . . . . . . . . . 14 References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 15 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 16 Reschke & Eissing Expires April 5, 2002 [Page 2] Internet-Draft WebDAV PROPFIND/allprop/include October 2001 1. Notational Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Reschke & Eissing Expires April 5, 2002 [Page 3] Internet-Draft WebDAV PROPFIND/allprop/include October 2001 2. Introduction Recent specifications extending the "Web Distributed Authoring Protocol" (WebDAV, [RFC2518]) like "Versioning Extensions to WebDAV" [deltaV] and "WebDAV Access Control Protocol" [ACL] restrict the set of properties returned automatically upon a PROPFIND/allprop request in order to avoid the expensive computation of properties that the client in many cases isn't interested in. However, this change from the behaviour defined in WebDAV can lead to situations where clients need to perform two requests to retrieve all properties they are interested in (one using PROPFIND/allprop, then PROPFIND/prop enumerating the new properties that weren't reported upon the first request). This specification defines a backward- compatible extension to add specific properties to the set of properties returned upon PROPFIND/allprop, thus saving at least one PROPFIND request. Reschke & Eissing Expires April 5, 2002 [Page 4] Internet-Draft WebDAV PROPFIND/allprop/include October 2001 3. Extensions to PROPFIND/allprop The "allprop" version of PROPFIND is extended to take an optional element (with namespace-URI "DAV:"). When present, it contains a set of property names that shall be reported in addition to those properties that the server usually would return upon PROPFIND/allprop. 3.1 Example for PROPFIND/allprop/include with extended server >>Request PROPFIND /container/front.html HTTP/1.1 Host: www.foo.bar Depth: 1 Content-Type: text/xml Content-Length: xxxx >>Response HTTP/1.1 207 Multi-Status Content-Type: text/xml Content-Length: xxxx http://www.foo.bar/container/front.html Box type B 1997-12-01T18:27:21-08:00 Example HTML resource 4525 text/html zzyzx Monday, 12-Jan-98 09:25:56 GMT Reschke & Eissing Expires April 5, 2002 [Page 5] Internet-Draft WebDAV PROPFIND/allprop/include October 2001 http://www.foo.bar/versions/container/front.html-1 HTTP/1.1 200 OK HTTP/1.1 404 NOT FOUND In this example, the server has recognized the extension element and included the DAV: properties and (as defined in [deltaV]). Reschke & Eissing Expires April 5, 2002 [Page 6] Internet-Draft WebDAV PROPFIND/allprop/include October 2001 3.2 Example for PROPFIND/allprop/include with non-extended server >>Request PROPFIND /container/front.html HTTP/1.1 Host: www.foo.bar Depth: 1 Content-Type: text/xml Content-Length: xxxx >>Response HTTP/1.1 207 Multi-Status Content-Type: text/xml Content-Length: xxxx http://www.foo.bar/container/front.html Box type B 1997-12-01T18:27:21-08:00 Example HTML resource 4525 text/html zzyzx Monday, 12-Jan-98 09:25:56 GMT Reschke & Eissing Expires April 5, 2002 [Page 7] Internet-Draft WebDAV PROPFIND/allprop/include October 2001 HTTP/1.1 200 OK In this case the element was simply ignored. The client can detect this situation by checking for the presence of the requested properties and will have to issue an additional PROPFIND/ prop request (to retrieve the missing properties). Reschke & Eissing Expires April 5, 2002 [Page 8] Internet-Draft WebDAV PROPFIND/allprop/include October 2001 4. Changes to WebDAV DTD Note that the WebDAV DTD is informal only and cannot be used to validate request or response bodies (due to the inability to properly work with XML namespaces). Reschke & Eissing Expires April 5, 2002 [Page 9] Internet-Draft WebDAV PROPFIND/allprop/include October 2001 5. Compatibility Considerations This specification introduces a new child element for the element, defined in Section 4. Old servers will ignore this element (see [RFC2518], chapter 14). Clients can detect this situation as outlined in Section 3.2. Clients not aware of this specification will not be affected at all, because they will never use the new element in PROPFIND requests. Reschke & Eissing Expires April 5, 2002 [Page 10] Internet-Draft WebDAV PROPFIND/allprop/include October 2001 6. Internationalization Considerations This proposal builds on [RFC2518], and inherits its internationalizability. Reschke & Eissing Expires April 5, 2002 [Page 11] Internet-Draft WebDAV PROPFIND/allprop/include October 2001 7. IANA Considerations This proposal does not introduce any new IANA considerations, since it does not specify any new namespaces (in the general sense), but merely uses existing ones. Reschke & Eissing Expires April 5, 2002 [Page 12] Internet-Draft WebDAV PROPFIND/allprop/include October 2001 8. Copyright To be supplied by the RFC Editor. Reschke & Eissing Expires April 5, 2002 [Page 13] Internet-Draft WebDAV PROPFIND/allprop/include October 2001 9. Intellectual Property To be supplied by the RFC Editor. Reschke & Eissing Expires April 5, 2002 [Page 14] Internet-Draft WebDAV PROPFIND/allprop/include October 2001 References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2518] Goland, Y., Whitehead, E., Faizi, A., Carter, S. and D. Jensen, "HTTP Extensions for Distributed Authoring -- WEBDAV", RFC 2518, February 1999. [deltaV] Clemm, G., Amsden, J., Ellison, T., Kaler, C. and J. Whitehead, "Versioning Extensions to WebDAV", ID draft- ietf-deltav-versioning-18, September 2001, . [ACL] Clemm, G., Hopkins, A., Sedlar, E. and J. Whitehead, "WebDAV Access Control Protocol", ID draft-ietf-webdav- acl-06, June 2001, . [1] [2] Authors' Addresses Julian F. Reschke greenbytes GmbH Salzmannstrasse 152 Muenster, NW 48159 Germany EMail: julian.reschke@greenbytes.de Stefan Eissing greenbytes GmbH Salzmannstrasse 152 Muenster, NW 48159 Germany EMail: stefan.eissing@greenbytes.de Reschke & Eissing Expires April 5, 2002 [Page 15] Internet-Draft WebDAV PROPFIND/allprop/include October 2001 Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Reschke & Eissing Expires April 5, 2002 [Page 16] ------=_NextPart_000_0000_01C14D92.5E1409A0 Content-Type: text/xml; name="draft-reschke-webdav-allprop-include-latest.xml" Content-Disposition: attachment; filename="draft-reschke-webdav-allprop-include-latest.xml" Content-Transfer-Encoding: quoted-printable Including = additional properties in WebDAV PROPFIND/allprop requests greenbytes GmbH
Salzmannstrasse 152 MuensterNW48159 Germany julian.reschke@greenbytes.de=09
greenbytes GmbH
Salzmannstrasse 152 MuensterNW48159 Germany stefan.eissing@greenbytes.de=09
Recent specifications extending the Web Distributed Authoring Protocol = (WebDAV) restrict the set of properties returned automatically upon a = PROPFIND/allprop request. This specification defines a method to add specific properties = to the set of properties returned upon PROPFIND/allprop. Distribution of this document is unlimited. Please send comments to the=20 Distributed Authoring and Versioning (WebDAV) working group at w3c-dist-auth@w3.org, = which may be joined by sending a message with subject=20 "subscribe" to w3c-di= st-auth-request@w3.org. Discussions of the WEBDAV working group are archived at URL:=20 http://list= s.w3.org/Archives/Public/w3c-dist-auth/. =20 =20
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",=20 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this=20 document are to be interpreted as described in .
Recent specifications extending the "Web Distributed Authoring = Protocol" (WebDAV, ) like "Versioning Extensions to WebDAV" = and "WebDAV Access Control Protocol" restrict = the set of properties returned automatically upon a PROPFIND/allprop request = in order to avoid the expensive computation of properties that the client = in many cases isn't interested in. However, this change from the behaviour defined in WebDAV can lead to situations where clients need to perform two requests to retrieve all = properties they are interested in (one using PROPFIND/allprop, then PROPFIND/prop enumerating the new properties that weren't reported upon the first = request). This specification defines a backward-compatible extension to add = specific properties to the set of properties returned upon PROPFIND/allprop, = thus saving at least one PROPFIND request.
The "allprop" version of PROPFIND is extended to take an optional = <include> element (with namespace-URI "DAV:"). When present, it contains a set of property names that shall be = reported in addition to those properties that the server usually would return = upon PROPFIND/allprop.
>>Request ]]>
>>Response http://www.foo.bar/container/front.html Box type B 1997-12-01T18:27:21-08:00 Example HTML resource 4525 text/html zzyzx Monday, 12-Jan-98 09:25:56 = GMT = http://www.foo.bar/versions/container/front.html-1 HTTP/1.1 200 OK HTTP/1.1 404 NOT FOUND ]]>
In this example, the server has recognized the extension element <include> and included the DAV: properties <checked-in> and <checked-out> (as defined in ).
>>Request ]]>
>>Response http://www.foo.bar/container/front.html Box type B 1997-12-01T18:27:21-08:00 Example HTML resource 4525 text/html zzyzx Monday, 12-Jan-98 09:25:56 = GMT HTTP/1.1 200 OK ]]>
In this case the <include> element was simply ignored. The client can detect this situation by checking for the presence of the = requested properties and will have to issue an additional PROPFIND/prop request (to retrieve the missing properties).=20
]]>
Note that the WebDAV DTD is informal only and cannot be used to validate request or response bodies (due to the inability to properly work with XML namespaces).
This specification introduces a new child element for the = <propfind> element, defined in . Old servers will ignore = this element (see , chapter 14). Clients can = detect this situation as outlined in . Clients not aware of this specification will not be affected at all, because they will never use the new <include> element in = PROPFIND requests. =20
This proposal builds on , and inherits its = internationalizability.
This proposal does not introduce any new IANA considerations, since=20 it does not specify any new namespaces (in the general sense), but=20 merely uses existing ones.
To be supplied by the RFC Editor.
To be supplied by the RFC Editor.
=09 Key words for use in RFCs to Indicate = Requirement Levels Harvard University
1350 Mass. Ave. Cambridge MA 02138 - +1 617 495 3864 -
 General keyword In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. Authors who follow these guidelines should incorporate this phrase near the beginning of their document: The key words "MUST", "MUST NOT", = "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", = "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as = described in RFC 2119. Note that the force of these words is modified by the requirement level of the document in which they are used. HTTP Extensions for Distributed Authoring -- WEBDAV Versioning Extensions to WebDAV WebDAV Access Control Protocol ------=_NextPart_000_0000_01C14D92.5E1409A0-- From w3c-dist-auth-request@w3.org Fri Oct 5 11:48:08 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24604 for ; Fri, 5 Oct 2001 11:48:08 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id LAA24830; Fri, 5 Oct 2001 11:45:34 -0400 (EDT) Resent-Date: Fri, 5 Oct 2001 11:45:34 -0400 (EDT) Resent-Message-Id: <200110051545.LAA24830@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id LAA24798 for ; Fri, 5 Oct 2001 11:45:26 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id LAA15960 for ; Fri, 5 Oct 2001 11:45:25 -0400 Received: (qmail 11273 invoked by uid 0); 5 Oct 2001 15:44:54 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mp003-rz3) with SMTP; 5 Oct 2001 15:44:54 -0000 From: "Julian Reschke" To: , "WebDAV Working Group" Date: Fri, 5 Oct 2001 17:45:48 +0200 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0013_01C14DC5.91898750" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Subject: REPORT vs SEARCH Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5397 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0013_01C14DC5.91898750 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, due to the recent discussion on the ACL list, I have done a comparison of PROPFIND, (ACL/deltaV) REPORT and (DASL) SEARCH. My conclusions are: - There are three methods with partly overlapping features: PROPFIND (defined in RFC2518), REPORT (defined in the soon-to-appear deltaV RFC) and SEARCH (expired draft). REPORT and SEARCH seem to be almost identical in features -- both just define frameworks into which query/report grammars can be plugged in. - There doesn't seem to be anything in the DASL framework that couldn't be done with REPORT. In fact, query grammar (REPORT) discovery seems to have a more elegant solution. Proposal: drop work on DASL. Instead define an (extensible) equivalent of DAV:basicseach, with the following additional features: - discovery of searchable properties - discovery of supported constructs in the grammar - better signaling of execution errors (non-searchable properties, not recognized grammar constructs) - definition of a mandatory subset of query grammar features Publish this as separate RFC, or possibly move it into RFC2518++. (the actual tabular comparison is attached as HTML). Julian ------=_NextPart_000_0013_01C14DC5.91898750 Content-Type: text/xml; name="basicsearch2reports.xslt" Content-Disposition: attachment; filename="basicsearch2reports.xslt" Content-Transfer-Encoding: quoted-printable =20 =20 =20 =20 ------=_NextPart_000_0013_01C14DC5.91898750-- From w3c-dist-auth-request@w3.org Fri Oct 5 11:57:18 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24714 for ; Fri, 5 Oct 2001 11:57:18 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id LAA28012; Fri, 5 Oct 2001 11:55:44 -0400 (EDT) Resent-Date: Fri, 5 Oct 2001 11:55:44 -0400 (EDT) Resent-Message-Id: <200110051555.LAA28012@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id LAA27967 for ; Fri, 5 Oct 2001 11:55:36 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id LAA17617 for ; Fri, 5 Oct 2001 11:55:35 -0400 Received: (qmail 4554 invoked by uid 0); 5 Oct 2001 15:55:04 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mp002-rz3) with SMTP; 5 Oct 2001 15:55:04 -0000 From: "Julian Reschke" To: "Julian Reschke" , , "WebDAV Working Group" Date: Fri, 5 Oct 2001 17:55:58 +0200 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_001A_01C14DC6.FD098F10" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Subject: RE: REPORT vs SEARCH Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5398 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_001A_01C14DC6.FD098F10 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit (sorry: wrong attachment) > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Julian Reschke > Sent: Friday, October 05, 2001 5:46 PM > To: ACL@webdav.org; WebDAV Working Group > Subject: REPORT vs SEARCH > > > Hi, > > due to the recent discussion on the ACL list, I have done a comparison of > PROPFIND, (ACL/deltaV) REPORT and (DASL) SEARCH. My conclusions are: > > - There are three methods with partly overlapping features: PROPFIND > (defined in RFC2518), REPORT (defined in the soon-to-appear > deltaV RFC) and > SEARCH (expired draft). > REPORT and SEARCH seem to be almost identical in features -- both just > define frameworks into which query/report grammars can be plugged in. > - There doesn't seem to be anything in the DASL framework that couldn't be > done with REPORT. In fact, query grammar (REPORT) discovery seems > to have a > more elegant solution. > > Proposal: drop work on DASL. Instead define an (extensible) equivalent of > DAV:basicseach, with the following additional features: > > - discovery of searchable properties > - discovery of supported constructs in the grammar > - better signaling of execution errors (non-searchable properties, not > recognized grammar constructs) > - definition of a mandatory subset of query grammar features > > Publish this as separate RFC, or possibly move it into RFC2518++. > > (the actual tabular comparison is attached as HTML). > > Julian > ------=_NextPart_000_001A_01C14DC6.FD098F10 Content-Type: text/html; name="report-vs-dasl.html" Content-Disposition: attachment; filename="report-vs-dasl.html" Content-Transfer-Encoding: quoted-printable Searching in WebDAV =20 =20
PROPFIND REPORT SEARCH
grammar discovery n/a Using computed property DAV:supported-report-set. Using OPTIONS method ("DASL" header).
selection Using PROPFIND with DAV:prop. Depends on the report type. For instance, DAV:version-tree works similar to PROPFIND. Depends on the search grammar. For instance, DAV:basicsearch = works similar to PROPFIND.
sorting PROPFIND preserves the sort order of collection members (if = the collection is sorted). Depends on the report type. Depends on the search grammar. For instance, DAV:basicsearch = allows sorting by property values (ascending and descending).
scoping and depth PROPFIND supports depth 0, 1 and infinity (using the D= epth header). The scope if defined by the request URI. Depends on the report type. Depends on the search grammar. For instance, DAV:basicsearch = allows=20 specification of both a search resource and depth (meaning = that the SEARCH request can be sent to a resource different from = the search scope).
restricting result size n/a Depends on the report type. Depends on the search grammar. For instance, DAV:basicsearch = allows restricting the number of results.
discovery of searchable properties n/a Depends on the report type. Depends on the search grammar. Older versions of the DASL = spec attempted to define query schemas, but this was dropped.
=20

Conclusions:

  • There are three methods with partly overlapping features: = PROPFIND (defined in RFC2518), REPORT (defined in the=20 soon-to-appear deltaV RFC) and SEARCH (expired draft).
  • REPORT and SEARCH seem to be almost identical in features -- = both just define frameworks into which query/report grammars can be plugged = in.
  • There doesn't seem to be anything in the DASL framework that couldn't be done with REPORT. In fact, query grammar (REPORT) = discovery seems to have a more elegant solution.

=20

Proposal: drop work on DASL. Instead define an (extensible) = equivalent of DAV:basicseach, with the following additional features:

  • discovery of searchable properties
  • discovery of supported constructs in the grammar
  • better signaling of execution errors (non-searchable = properties, not recognized grammar constructs)
  • definition of a mandatory subset of query grammar = features
Publish this as separate RFC, or possibly move it into RFC2518++.

------=_NextPart_000_001A_01C14DC6.FD098F10-- From w3c-dist-auth-request@w3.org Fri Oct 5 13:33:06 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27055 for ; Fri, 5 Oct 2001 13:33:06 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA07576; Fri, 5 Oct 2001 13:29:23 -0400 (EDT) Resent-Date: Fri, 5 Oct 2001 13:29:23 -0400 (EDT) Resent-Message-Id: <200110051729.NAA07576@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id NAA07552 for ; Fri, 5 Oct 2001 13:29:15 -0400 (EDT) Received: from cats.ucsc.edu (rumpleteazer.ucsc.edu [128.114.129.45]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id NAA30193 for ; Fri, 5 Oct 2001 13:29:16 -0400 Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177]) by cats.ucsc.edu (8.9.3/8.8.4.cats-athena) with SMTP id KAA09204; Fri, 5 Oct 2001 10:29:14 -0700 (PDT) From: "Jim Whitehead" To: , "WebDAV Working Group" Date: Fri, 5 Oct 2001 10:25:32 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: RE: [ACL] REPORT vs SEARCH Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5399 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Julian Reschke writes: > due to the recent discussion on the ACL list, I have done a comparison of > PROPFIND, (ACL/deltaV) REPORT and (DASL) SEARCH. My conclusions are: > > - There are three methods with partly overlapping features: PROPFIND > (defined in RFC2518), REPORT (defined in the soon-to-appear > deltaV RFC) and SEARCH (expired draft). > REPORT and SEARCH seem to be almost identical in features -- both just > define frameworks into which query/report grammars can be plugged in. > - There doesn't seem to be anything in the DASL framework that couldn't be > done with REPORT. In fact, query grammar (REPORT) discovery seems > to have a more elegant solution. My view on the distinction between the three methods (PROPFIND, SEARCH, REPORT) is as follows: * PROPFIND is useful when the client knows exactly which properties, on which resources, it wants to retrieve. It is also useful for discovering what properties are defined on a resource. * SEARCH is useful when the client knows what property values it wishes to retrieve, but it cannot compute ahead of time the set of resources for which it wants those property values. While the client could just retrieve the properties from all resources, and then perform a comparison in-memory, this is *extremely* inefficient from a network resources standpoint. SEARCH can perform an unconstrained number of different kinds of searches on the server, and so it is very difficult for the server to optimize specific, frequently-occurring searches. * REPORT is useful when the protocol designers can predict that a specific search will be very useful, and will occur frequently. This allows a server to optimize the performance of these queries. Additionally, REPORT allows complex search semantics to be defined that might not be expressable using SEARCH. But, REPORT was never desgined to accommodate a wide range of fairly unconstrained queries (such as those expressable using SQL). In my view, each of these methods has its niche, and each has value. As a result, I favor: a) continued development on the DASL specification. Lisa Dusseault has volunteered to edit this specification, and I'm expecting a new draft from her in the near future. b) the addition of specialized REPORTs into protocol specifications, as needed. > Proposal: drop work on DASL. I think this is a bad idea. A general purpose search mechanism is necessary to unlock the value of properties. Instead define an (extensible) equivalent of > DAV:basicseach, with the following additional features: > > - discovery of searchable properties > - discovery of supported constructs in the grammar > - better signaling of execution errors (non-searchable properties, not > recognized grammar constructs) > - definition of a mandatory subset of query grammar features > > Publish this as separate RFC, or possibly move it into RFC2518++. These look like a useful set of requirements for DASL. - Jim From w3c-dist-auth-request@w3.org Fri Oct 5 13:40:17 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27197 for ; Fri, 5 Oct 2001 13:40:17 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA08329; Fri, 5 Oct 2001 13:38:45 -0400 (EDT) Resent-Date: Fri, 5 Oct 2001 13:38:45 -0400 (EDT) Resent-Message-Id: <200110051738.NAA08329@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id NAA08309 for ; Fri, 5 Oct 2001 13:38:41 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id NAA31688 for ; Fri, 5 Oct 2001 13:38:41 -0400 Received: (qmail 1282 invoked by uid 0); 5 Oct 2001 17:38:09 -0000 Received: from pd9535213.dip.t-dialin.net (HELO lisa) (217.83.82.19) by mail.gmx.net (mp020-rz3) with SMTP; 5 Oct 2001 17:38:09 -0000 From: "Julian Reschke" To: "Jim Whitehead" , , "WebDAV Working Group" Date: Fri, 5 Oct 2001 19:39:02 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: Importance: Normal Subject: RE: [ACL] REPORT vs SEARCH Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5400 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: acl-admin@webdav.org [mailto:acl-admin@webdav.org]On Behalf Of Jim > Whitehead > Sent: Friday, October 05, 2001 7:26 PM > To: ACL@webdav.org; WebDAV Working Group > Subject: RE: [ACL] REPORT vs SEARCH > > > Julian Reschke writes: > ... > > In my view, each of these methods has its niche, and each has value. As a > result, I favor: > > a) continued development on the DASL specification. Lisa Dusseault has > volunteered to edit this specification, and I'm expecting a new draft from > her in the near future. > > b) the addition of specialized REPORTs into protocol specifications, as > needed. > > > Proposal: drop work on DASL. > > I think this is a bad idea. A general purpose search mechanism > is necessary > to unlock the value of properties. Yes, that is why I proposed to make DAV:basicsearch a REPORT. > Instead define an (extensible) equivalent of > > DAV:basicseach, with the following additional features: > > > > - discovery of searchable properties > > - discovery of supported constructs in the grammar > > - better signaling of execution errors (non-searchable properties, not > > recognized grammar constructs) > > - definition of a mandatory subset of query grammar features > > > > Publish this as separate RFC, or possibly move it into RFC2518++. > > These look like a useful set of requirements for DASL. I think you partly missed my point. Both REPORT and SEARCH define frameworks for pluggable query grammars / reports. I really can't see where the distinction between reports and searches you made is reflected in the specs. However, the framework for REPORT is already there (almost in RFC form), and I think it's technically superior (regarding discovery of query grammars / reports). So my proposal is to drop the DASL *framework* and re-use the one used in REPORT, and to update / modify DAV:basicsearch to become a report. By dropping the requirement to define a framework for SEARCH, we save a lot of time that can be invested much better on the actual DAV:basicsearch grammar. If you disagree, I'd like to understand why we need the SEARCH framework when we already have REPORT. Regards, Julian From w3c-dist-auth-request@w3.org Fri Oct 5 13:53:31 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27336 for ; Fri, 5 Oct 2001 13:53:30 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA09694; Fri, 5 Oct 2001 13:51:59 -0400 (EDT) Resent-Date: Fri, 5 Oct 2001 13:51:59 -0400 (EDT) Resent-Message-Id: <200110051751.NAA09694@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id NAA09674 for ; Fri, 5 Oct 2001 13:51:54 -0400 (EDT) Received: from sus-ma1it00.rational.com (ext-38237.rational.com [192.229.38.237]) by tux.w3.org (8.9.3/8.9.3) with SMTP id NAA01266 for ; Fri, 5 Oct 2001 13:51:54 -0400 Received: from 192.168.215.70 by sus-ma1it00.rational.com (InterScan E-Mail VirusWall NT); Fri, 05 Oct 2001 13:48:21 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id <4D3CT008>; Fri, 5 Oct 2001 13:48:17 -0400 Message-ID: <3906C56A7BD1F54593344C05BD1374B103F8AC50@SUS-MA1IT01> From: "Clemm, Geoff" To: ACL@webdav.org, WebDAV Working Group Date: Fri, 5 Oct 2001 13:48:15 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [ACL] REPORT vs SEARCH Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5401 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: I agree with Julian that a special kind of REPORT (e.g. DAV:basic-search) makes more sense than introducing a SEARCH method. Cheers, Geoff -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de] Sent: Friday, October 05, 2001 1:39 PM To: Jim Whitehead; ACL@webdav.org; WebDAV Working Group Subject: RE: [ACL] REPORT vs SEARCH > From: acl-admin@webdav.org [mailto:acl-admin@webdav.org]On Behalf Of Jim > Whitehead > Sent: Friday, October 05, 2001 7:26 PM > To: ACL@webdav.org; WebDAV Working Group > Subject: RE: [ACL] REPORT vs SEARCH > > > Julian Reschke writes: > ... > > In my view, each of these methods has its niche, and each has value. As a > result, I favor: > > a) continued development on the DASL specification. Lisa Dusseault has > volunteered to edit this specification, and I'm expecting a new draft from > her in the near future. > > b) the addition of specialized REPORTs into protocol specifications, as > needed. > > > Proposal: drop work on DASL. > > I think this is a bad idea. A general purpose search mechanism > is necessary > to unlock the value of properties. Yes, that is why I proposed to make DAV:basicsearch a REPORT. > Instead define an (extensible) equivalent of > > DAV:basicseach, with the following additional features: > > > > - discovery of searchable properties > > - discovery of supported constructs in the grammar > > - better signaling of execution errors (non-searchable properties, not > > recognized grammar constructs) > > - definition of a mandatory subset of query grammar features > > > > Publish this as separate RFC, or possibly move it into RFC2518++. > > These look like a useful set of requirements for DASL. I think you partly missed my point. Both REPORT and SEARCH define frameworks for pluggable query grammars / reports. I really can't see where the distinction between reports and searches you made is reflected in the specs. However, the framework for REPORT is already there (almost in RFC form), and I think it's technically superior (regarding discovery of query grammars / reports). So my proposal is to drop the DASL *framework* and re-use the one used in REPORT, and to update / modify DAV:basicsearch to become a report. By dropping the requirement to define a framework for SEARCH, we save a lot of time that can be invested much better on the actual DAV:basicsearch grammar. If you disagree, I'd like to understand why we need the SEARCH framework when we already have REPORT. Regards, Julian _______________________________________________ acl mailing list acl@webdav.org http://mailman.webdav.org/mailman/listinfo/acl From w3c-dist-auth-request@w3.org Fri Oct 5 14:24:27 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28067 for ; Fri, 5 Oct 2001 14:24:27 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA11852; Fri, 5 Oct 2001 14:22:10 -0400 (EDT) Resent-Date: Fri, 5 Oct 2001 14:22:10 -0400 (EDT) Resent-Message-Id: <200110051822.OAA11852@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id OAA11828 for ; Fri, 5 Oct 2001 14:22:05 -0400 (EDT) Received: from cats.ucsc.edu (rumpleteazer.ucsc.edu [128.114.129.45]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id OAA03931 for ; Fri, 5 Oct 2001 14:22:05 -0400 Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177]) by cats.ucsc.edu (8.9.3/8.8.4.cats-athena) with SMTP id LAA28906 for ; Fri, 5 Oct 2001 11:22:08 -0700 (PDT) From: "Jim Whitehead" To: "WebDAV Working Group" Date: Fri, 5 Oct 2001 11:18:25 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: RE: PropReg: Probing for Property-Registration Requirements Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5402 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 8bit Thank you Dennis for taking the lead on the issue of property registration. Your set of questions is excellent -- they made me think about several issues I hadn't considered before, and do a good job of exposing the complexity of property registration. Let me take a whack at answering these questions to get discussion rolling. > - - - THE QUESTIONS - - - > > D. REGISTERING A WEBDAV PROPERTY > > 1. Registration identifies the property and the authoritative source of > further information? Yes to both. Registration identifies the property (its "name", which includes its "namespace") and the human organization or person to contact for further information. > The source is located by URI? The source is located > by non-Internet means? Since *people*, often working within some organization, define properties, I would expect the contact information to be a person, and their organizational affiliation at the time they defined the property. > Is it necessary to associate a property with some > authority over its definition? The authoritative source and the property > are identified independently? I think it would be a good thing to identify which person or organization has change control over the properties. In the case of a standards development organization (SDO), it may be the case that a specific working group developed a property, but the SDO as a whole has change control (since the WG may go away long before the end of the lifetime of the property). > 2. Does the registration make available a definition of the > property? Is the definition amenable to human use? Mechanical usage? > Both? In combination? What purpose is served by making the definition available? In my view, the ultimate purpose of the registration is to enhance interoperability of these properties. There are multiple consumers of property information: system designers, end users, and computational agents (i.e., programs, such as a client or server implementation). A good definition satisfies all consumers. There are a couple of aspects to each property definition: * A human-readable description of the property contents ("what" does the property contain?") ("The property will record the address of the copyright holder of the resource") * A human-readable description of some expected uses of the property ("why" might someone use this property) * The machine-readable syntax of the property. This includes the XML DTD, as well as the syntax of the contents of each XML element and attribute used. ("The property MUST start with an
XML element, defined with the following DTD, with the following sub-elements (and their definition) ..."). * The semantics and standard schemas used for the contents of the property. ("For addresses in the United States, the XML element MUST have a value that corresponds to one of the postal state codes defined in ...") ("The value of this field is unconstrained...") * Is the property live or dead? Writeable or protected? ("how" does a client interact with this property?) * Does the property form part of a protocol? ("typically a client should write property X, then read property Y...") It is my opinion that the current state of the art is not far enough advanced that providing *only* a machine-readable definition of a property is sufficient. That is, while a definition in a language like RDF Schema would be helpful, if available, such a definition does not, by itself, provide sufficient information to a client developer to understand and use that property. > 3. Is the registration information submitted to third parties > for retention and retrieval by anyone who chooses to discover the > established use of the identified property? Might it be found on > WebDAV servers that support the property? Registraion information should be submitted to an organization that is expected to be long-lived (~25+ years) and that has, as part of their mission, archival storage. Property registration information should be retrievable by anyone on the Internet without fee. Unless previously copyrighted, people submitting property information should make it available under standard IETF copyright policy. Patents and copyrights that apply to properties themselves, or to the contents of properties, should be noted in the registration of the property. Just as most HTTP servers do not have a copy of RFC 2616 available on the server, there should be no expectation that servers implementing a specific property will have a copy of the registration information on that server. > 4. What groups of people (by rôle) are required to be able to > create and> submit/register property-registration information? > (This is distinct from being able to configure a server and/or > client to support such a property.) Anyone should be able to submit property registration information. It woould be useful to have a low-overhead vetting process, to ensure that property registrations are of reasonable quality, and address all issues. MIME types in the vnd. tree are sent to a mailing list, and typically receive feedback within a few days. The entire registration process typically takes under two weeks. > E. USING REGISTRATION INFORMATION > > 1. Are property registrations intended to be useable by clients while > interacting with a DAV server that supports a particular property? No. > 2. If a property can be set by a client (even if live), does > the property registration provide > a. format conditions (syntax) for the value of the property? > b. descriptive or other information with regard to the > semantics of the > value? > c. indication of interdependencies with other properties? > I think the key question is how far should the property > description go to > equip a knowledgeable person, in conjunction with flexible client > software, to be able to specify a value for the property that > (i) will be accepted by the server and (ii) is appropriate in the > context of the semantics of the property? It should provide sufficient information that a developer, working from the property description alone, can implement a client or server using the property, and have reasonable assurance that their implementation will interoperate with other implementations of the same property. It should also provide sufficient information that an expert end-user, when presented with the value of this property, can understand it. > 3. Is it important to provide, in the registration information, > customization descriptive presentations for users who are competent in > different native languages? Well, in general I think we need to provide more guidance on i18n of properties. The best approach here would be to develop a specification giving guidance on how to handle some common i18n scenarios with properties, and then have the property registration identify which of the common mechanisms it is using. > 4. How important is it to have the property-registration > information provide sufficient information so that an user can > intelligibly interpret a value for that property as presented > by a flexible client? (By flexible is meant a client that allows > use of properties other than ones it was specifically designed > to accommodate.) It would be nice if the property registration gave some suggestions on how a user interface should present the value of the property. This is especially useful for properties with RDF values. I believe the property registration should describe the property well enough that an expert end-user can understand the value of the property. I'm shying away from a more expansive definition that would be sufficient for "most" end-users, since this might involve giving background tutorials on the nature of metadata itself, background on the nature of the problem the metadata schema is addressing, etc. > 5. What groups of people (by rôle) are required to be able to > find and use property-registration information? All developers and end-users should be able to find and use property registration information, if they desire. However, the presentation of property registration information should not be a requirement on implementations. I liken this to the RFC series. Developers are by far the primary consumers of the specifications. But, it is often the case that sophisticated end-users and students have an interest in reading the specifications to have a deep understanding of the techology. Certainly no HTTP browser provides the ability to read the HTTP specifications. > 6. Is property registration information to be attractive for > configuration of a server to support the property (apart from > mapping to an implementation and recognizing that no DAV server > is required to support such an approach)? Server configuration strikes me as out-of-scope, since it will vary widely by server. > F. INTERCHANGE OF PROPERTY-REGISTRATION INFORMATION > [This seems to be all about constraints. Ah well ...] > a. Should the property-registration information be in > a structured, mechanically-processable form? I view this as a bonus, not a requirement. > b. Must the property-registration information be > easily rendered for human comprehension and review? Yes. I view humans as the primary, and most important consumers of the registration information. > c. Should property registrations be a resource type > for storage in DAV itself? An existing resource type? I see no need to define a new MIME type, or DAV resource type for these registrations. > d. How easy must it be to carry the > property-registration information in > plain text, in files, and in simple serial data streams? > Embedded in structured information? I view this as being very unimportant. - Jim From w3c-dist-auth-request@w3.org Fri Oct 5 15:01:25 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28865 for ; Fri, 5 Oct 2001 15:01:25 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA15805; Fri, 5 Oct 2001 14:59:28 -0400 (EDT) Resent-Date: Fri, 5 Oct 2001 14:59:28 -0400 (EDT) Resent-Message-Id: <200110051859.OAA15805@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id OAA15782 for ; Fri, 5 Oct 2001 14:59:23 -0400 (EDT) Received: from cats.ucsc.edu (rumpleteazer.ucsc.edu [128.114.129.45]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id OAA08645 for ; Fri, 5 Oct 2001 14:59:23 -0400 Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177]) by cats.ucsc.edu (8.9.3/8.8.4.cats-athena) with SMTP id LAA10140; Fri, 5 Oct 2001 11:59:25 -0700 (PDT) From: "Jim Whitehead" To: , "WebDAV Working Group" Date: Fri, 5 Oct 2001 11:55:42 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: RE: [ACL] REPORT vs SEARCH Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5403 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Julian Reschke writes: > Both REPORT and SEARCH define frameworks for pluggable query grammars / > reports. I really can't see where the distinction between reports and > searches you made is reflected in the specs. Many design considerations never make it into specifications. > However, the framework for REPORT is already there (almost in RFC > form) For the case of DAV:basicsearch, this doesn't count for much. The definition of the "SEARCH" method is not the difficult part of DASL. The core complexity comes from specifying the search grammar, and correctly specifying how to do an i18n ordering of search results. These complexities are these whether you use REPORT or SEARCH. >, and I think it's technically superior (regarding discovery > of query grammars / reports). Huh? REPORT tells you what reports are available via DAV:supported-report-set. DASL tells you what search grammars are available via the DASL response header. These are equivalent in expressive power. > So my proposal is to drop the DASL *framework* and re-use the one > used in REPORT, and to update / modify DAV:basicsearch to become a report. This isn't a shift of framework, it's a shift of marshalling mechanism, REPORT vs. SEARCH, DAV:supported-report-set vs. OPTIONS and the DASL header. > If you disagree, I'd like to understand why we need the SEARCH framework > when we already have REPORT. While I will freely admit that you *could* marshall DAV:basicsearch using REPORT, here are my reasons for why I think you should have both REPORT and SEARCH: - Reports have very specialized and limited query specifications. Search grammars are expected to be much more complex (DAV:basicsearch, XML query, Z39.50, etc.) - Reports have a reasonable expectation of being specified in XML. Queries submitted using SEARCH may not be. - Error reporting mechanisms for REPORT may not be appropriate for SEARCH. In particular, it may not be safe to assume that returning an XML tag in the body is OK for all search grammars, yet this is the current case for REPORT. - REPORT is currently limited to using the Depth mechanism for scoping. While this is also the current case for DASL, I believe that DASL will need to provide a definition for how to perform a "server"-wide search. Separating the two will free DASL to develop better scoping rules. - Some queries grammars using DASL may not even require DAV extensions to be present. For example, XML query via DASL should reasonably work against both HTTP+DAV+DASL servers and plain HTTP+DASL servers. REPORT is intimately tied to the DAV object model (it requires properties). Basically, these all boil down to a separation of concerns argument. By separating REPORT and SEARCH, you allow each to more precisely meet their respective requirements. - Jim From w3c-dist-auth-request@w3.org Fri Oct 5 15:20:47 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29543 for ; Fri, 5 Oct 2001 15:20:47 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA17673; Fri, 5 Oct 2001 15:18:35 -0400 (EDT) Resent-Date: Fri, 5 Oct 2001 15:18:35 -0400 (EDT) Resent-Message-Id: <200110051918.PAA17673@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id PAA17650 for ; Fri, 5 Oct 2001 15:18:31 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id PAA10994 for ; Fri, 5 Oct 2001 15:18:31 -0400 Received: (qmail 658 invoked by uid 0); 5 Oct 2001 19:18:18 -0000 Received: from pd9535213.dip.t-dialin.net (HELO lisa) (217.83.82.19) by mail.gmx.net (mp007-rz3) with SMTP; 5 Oct 2001 19:18:18 -0000 From: "Julian Reschke" To: "Jim Whitehead" , , "WebDAV Working Group" Date: Fri, 5 Oct 2001 21:19:11 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: Importance: Normal Subject: RE: [ACL] REPORT vs SEARCH Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5404 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jim Whitehead > Sent: Friday, October 05, 2001 8:56 PM > To: ACL@webdav.org; WebDAV Working Group > Subject: RE: [ACL] REPORT vs SEARCH > > > Julian Reschke writes: > > Both REPORT and SEARCH define frameworks for pluggable query grammars / > > reports. I really can't see where the distinction between reports and > > searches you made is reflected in the specs. > > Many design considerations never make it into specifications. > > > However, the framework for REPORT is already there (almost in RFC > > form) > > For the case of DAV:basicsearch, this doesn't count for much. The > definition of the "SEARCH" method is not the difficult part of DASL. The > core complexity comes from specifying the search grammar, and correctly > specifying how to do an i18n ordering of search results. These > complexities > are these whether you use REPORT or SEARCH. > > >, and I think it's technically superior (regarding discovery > > of query grammars / reports). > > Huh? > > REPORT tells you what reports are available via DAV:supported-report-set. > > DASL tells you what search grammars are available via the DASL response > header. > > These are equivalent in expressive power. Not really. a) DASL defines an HTTP header, so it occupies a token in the HTTP namespace, while DAV:supported-report-set is only visible to clients issueing WebDAV requests (so we don't unnecessarily occupy a place in somebody else's namespace), b) The way OPTIONS is defined in DASL, you can't use the header information to *directly* identify which grammars available. The way it's defined for DAV:basicsearch *only* works because DAV: happens to be the prefix and the namespace name at the same time. Given a DASL header of what is the name of the grammar (so how do you *generally* split the namespace from the grammar name?). > > So my proposal is to drop the DASL *framework* and re-use the one > > used in REPORT, and to update / modify DAV:basicsearch to > become a report. > > This isn't a shift of framework, it's a shift of marshalling mechanism, > REPORT vs. SEARCH, DAV:supported-report-set vs. OPTIONS and the > DASL header. Fine with me :-) > > If you disagree, I'd like to understand why we need the SEARCH framework > > when we already have REPORT. > > While I will freely admit that you *could* marshall DAV:basicsearch using > REPORT, here are my reasons for why I think you should have both > REPORT and > SEARCH: > > - Reports have very specialized and limited query specifications. Search > grammars are expected to be much more complex (DAV:basicsearch, XML query, > Z39.50, etc.) *The currently defined* reports: yes. But why should this restrict us in what new reports we define? And why do we need two frameworks if the one we have can do everything we need? > - Reports have a reasonable expectation of being specified in XML. Queries > submitted using SEARCH may not be. Can you back that up by anything which is either in ACL, deltaV or DASL? > - Error reporting mechanisms for REPORT may not be appropriate for SEARCH. > In particular, it may not be safe to assume that returning an XML > tag in the > body is OK for all search grammars, yet this is the current case > for REPORT. "If an error occurred that prevented execution of the query, the server MUST indicate the failure with the appropriate status code and SHOULD include a DAV:multistatus element to point out errors associated with scopes." OK, so why is this "should" rather than "must"? Do we really non-XML based query protocols? > - REPORT is currently limited to using the Depth mechanism for scoping. > While this is also the current case for DASL, I believe that DASL > will need > to provide a definition for how to perform a "server"-wide search. > Separating the two will free DASL to develop better scoping rules. Interesting, but this isn't really an argument in favor for SEARCH. > - Some queries grammars using DASL may not even require DAV > extensions to be > present. For example, XML query via DASL should reasonably work > against both > HTTP+DAV+DASL servers and plain HTTP+DASL servers. REPORT is > intimately tied > to the DAV object model (it requires properties). Where does it require properties? I see your point that SEARCH can be something separate from WebDAV. Is this a purely theoretical requirement, or did somebody specifically ask for it? While I link DAV:supported-report-set, grammar discovery could also be done through REPORT itself (it would be just another report, so it wouldn't have to rely on PROPFIND). > Basically, these all boil down to a separation of concerns argument. By > separating REPORT and SEARCH, you allow each to more precisely meet their > respective requirements. > > - Jim > From w3c-dist-auth-request@w3.org Sat Oct 6 22:06:59 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03235 for ; Sat, 6 Oct 2001 22:06:59 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id WAA17492; Sat, 6 Oct 2001 22:04:58 -0400 (EDT) Resent-Date: Sat, 6 Oct 2001 22:04:58 -0400 (EDT) Resent-Message-Id: <200110070204.WAA17492@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id WAA17472 for ; Sat, 6 Oct 2001 22:04:55 -0400 (EDT) Received: from mail0.rawbw.com (mail0.rawbw.com [198.144.192.41]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id WAA09349 for ; Sat, 6 Oct 2001 22:04:54 -0400 Received: from beaver ([198.144.203.248]) by mail0.rawbw.com (8.11.3/8.11.3) with SMTP id f9724qk33495 for ; Sat, 6 Oct 2001 19:04:52 -0700 (PDT) (envelope-from lisa@xythos.com) From: "Lisa Dusseault" To: "Webdav WG" Date: Sat, 6 Oct 2001 19:04:22 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Subject: REPORT vs SEARCH Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5405 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Jim's argument that DASL could be implemented on top of an existing Web Server, without any DAV features, I find compelling. In addition, I thought of a few other reasons: - DASL is rather big, and rather 'primary'. It's not just a part of another feature, like the reports are part of ACL and part of DeltaV. As such, I believe servers will want to advertise support for search directly in the OPTIONS response. If Search is just another report, it would seem wierd to treat it differently. - REPORT could become too much of a catch-all. It shouldn't be. We need to resist making REPORT the POST of DAV. - It's already implemented as SEARCH in a couple places (including, I admit, Xythos' implementation). While I don't consider that argument to trump the issue, it's certainly a consideration. If there were real problems with a separate method with SEARCH I'd agree and push to change existing implementations -- but there aren't any problems. Overall, since the arguments for replacing SEARCH with REPORT aren't very strong arguments, I'd say keep it the way it is. Lisa From w3c-dist-auth-request@w3.org Sun Oct 7 12:32:14 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24444 for ; Sun, 7 Oct 2001 12:32:14 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA13554; Sun, 7 Oct 2001 12:29:36 -0400 (EDT) Resent-Date: Sun, 7 Oct 2001 12:29:36 -0400 (EDT) Resent-Message-Id: <200110071629.MAA13554@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id MAA13532 for ; Sun, 7 Oct 2001 12:29:31 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id MAA01759 for ; Sun, 7 Oct 2001 12:29:32 -0400 Received: (qmail 9071 invoked by uid 0); 7 Oct 2001 16:29:30 -0000 Received: from pd9535d9d.dip.t-dialin.net (HELO lisa) (217.83.93.157) by mail.gmx.net (mp001-rz3) with SMTP; 7 Oct 2001 16:29:30 -0000 From: "Julian Reschke" To: "Lisa Dusseault" , "Webdav WG" Date: Sun, 7 Oct 2001 18:30:14 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-reply-to: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Subject: RE: REPORT vs SEARCH Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5406 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault > Sent: Sunday, October 07, 2001 4:04 AM > To: Webdav WG > Subject: REPORT vs SEARCH > > > > Jim's argument that DASL could be implemented on top of an existing Web > Server, without any DAV features, I find compelling. In > addition, I thought > of a few other reasons: > > - DASL is rather big, and rather 'primary'. It's not just a part of > another feature, like the reports are part of ACL and part of DeltaV. As > such, I believe servers will want to advertise support for search directly > in the OPTIONS response. If Search is just another report, it would seem > wierd to treat it differently. Well, I wouldn't *want* to treat it differently. > - REPORT could become too much of a catch-all. It shouldn't be. We need > to resist making REPORT the POST of DAV. :-) So instead we're doing this with SEARCH? I understand Jim's argument about SEARCH being independant of other WebDAV features. I just fail to see why we couldn't use REPORT's framework which already does what we need fopr XML-based query grammars. SEARCH currently doesn't say anything specific about non-XML based query grammars. It would be trivial to do the same with REPORT. > - It's already implemented as SEARCH in a couple places (including, I > admit, Xythos' implementation). While I don't consider that argument to > trump the issue, it's certainly a consideration. If there were real > problems with a separate method with SEARCH I'd agree and push to change > existing implementations -- but there aren't any problems. However, everybody who *did* implement SEARCH and DAV:basicsearch should keep in mind that - drafts are work-in-progress and - that DASL will need to be fixed in some areas, so I don't think that a finalized draft can be completely compatible to the one that's published. > Overall, since the arguments for replacing SEARCH with REPORT aren't very > strong arguments, I'd say keep it the way it is. In my opinion, DASL's way to do grammar discovery is broken (it reports grammars as URIs, while they are really Qualified (XML) names). So this needs to be replaced with something else anyway. The framework used for REPORT doesn't have this problem, so why not use it? From w3c-dist-auth-request@w3.org Mon Oct 8 11:51:08 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24204 for ; Mon, 8 Oct 2001 11:51:08 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id LAA25709; Mon, 8 Oct 2001 11:48:41 -0400 (EDT) Resent-Date: Mon, 8 Oct 2001 11:48:41 -0400 (EDT) Resent-Message-Id: <200110081548.LAA25709@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id LAA25689 for ; Mon, 8 Oct 2001 11:48:37 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id LAA10364 for ; Mon, 8 Oct 2001 11:48:37 -0400 Received: (qmail 12926 invoked by uid 0); 8 Oct 2001 15:48:06 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mp007-rz3) with SMTP; 8 Oct 2001 15:48:06 -0000 From: "Julian Reschke" To: "Webdav WG" , Date: Mon, 8 Oct 2001 17:49:00 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: Subject: RE: [ACL] Searching principal properties proposal Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5407 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: acl-admin@webdav.org [mailto:acl-admin@webdav.org]On Behalf Of > Keith Wannamaker > Sent: Monday, October 08, 2001 5:26 PM > To: ACL@webdav.org > Subject: RE: [ACL] Searching principal properties proposal > > > ... > > | In WebDAV, properties *may* have an xml:lang attribute. > However, a property > | always has a single value -- you can't have both xml:lang="de" /> > | and on the same resource. > | > | In theory, the language could be selected based on the request, > but I don't > | think that it would be a good idea to introduce this kind of > semantics for > | properties. > | > | REPORT however doesn't need to use properties to do the reporting, so we > | don't have this restrictrion. > > In this case, since the principal-search-property element can only contain > a single description element, I would think the server could safely use > an xml:lang attribute. Thinking of it: would it be legal for a server to make the content of a computed property depend on additional (language) information from the request? (crossposted to the WebDAV list because it's a general RFC2518 issue). Julian From w3c-dist-auth-request@w3.org Mon Oct 8 18:57:28 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03754 for ; Mon, 8 Oct 2001 18:57:27 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAA16392; Mon, 8 Oct 2001 18:54:03 -0400 (EDT) Resent-Date: Mon, 8 Oct 2001 18:54:03 -0400 (EDT) Resent-Message-Id: <200110082254.SAA16392@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id SAA16369 for ; Mon, 8 Oct 2001 18:53:53 -0400 (EDT) Received: from front1.mail.megapathdsl.net (front1.mail.megapathdsl.net [66.80.60.31]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id SAA19528 for ; Mon, 8 Oct 2001 18:53:53 -0400 Received: from [64.139.0.223] (HELO beaver) by front1.mail.megapathdsl.net (CommuniGate Pro SMTP 3.4.8a) with SMTP id 8273669 for w3c-dist-auth@w3c.org; Mon, 08 Oct 2001 15:46:29 -0700 From: "Lisa Dusseault" To: "Webdav WG" Date: Mon, 8 Oct 2001 15:52:48 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Subject: Drafts of interest to WebDAV... Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5408 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Two drafts on compression and delta transfers have been in progress for a while. Both are potentially useful for WebDAV software. In case you haven't seen them, I thought I'd forward the links and abstracts to the DAV list. http://www.ietf.org/internet-drafts/draft-mogul-http-digest-05.txt http://www.ietf.org/internet-drafts/draft-mogul-http-delta-10.txt Lisa ---- A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Instance Digests in HTTP Author(s) : J. Mogul, A. van Hoff Filename : draft-mogul-http-digest-05.txt Pages : 12 Date : 04-Oct-01 HTTP/1.1 defines a Content-MD5 header that allows a server to include a digest of the response body. However, this is specifically defined to cover the body of the actual message, not the contents of the full file (which might be quite different, if the response is a Content-Range, or uses a delta encoding). Also, the Content-MD5 is limited to one specific digest algorithm; other algorithms, such as SHA-1, may be more appropriate in some circumstances. Finally, HTTP/1.1 provides no explicit mechanism by which a client may request a digest. This document proposes HTTP extensions that solve these problems. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-mogul-http-digest-05.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Delta encoding in HTTP Author(s) : J. Mogul, B. Krishnamurthy, F. Douglis, A. Feldmann, Y. Goland, A. van Hoff, D. Hellerstein Filename : draft-mogul-http-delta-10.txt Pages : 46 Date : 04-Oct-01 Many HTTP requests cause the retrieval of slightly modified instances of resources for which the client already has a cache entry. Research has shown that such modifying updates are frequent, and that the modifications are typically much smaller than the actual entity. In such cases, HTTP would make more efficient use of network bandwidth if it could transfer a minimal description of the changes, rather than the entire new instance of the resource. This is called 'delta encoding.' This document describes how delta encoding can be supported as a compatible extension to HTTP/1.1. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-mogul-http-delta-10.txt From w3c-dist-auth-request@w3.org Thu Oct 11 18:31:03 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27635 for ; Thu, 11 Oct 2001 18:31:03 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAA17462; Thu, 11 Oct 2001 18:27:26 -0400 (EDT) Resent-Date: Thu, 11 Oct 2001 18:27:26 -0400 (EDT) Resent-Message-Id: <200110112227.SAA17462@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id SAA17442 for ; Thu, 11 Oct 2001 18:27:18 -0400 (EDT) Received: from mail.covalent.net (162-39.84.64.covalent.net [64.84.39.162] (may be forged)) by tux.w3.org (8.9.3/8.9.3) with SMTP id SAA24043 for ; Thu, 11 Oct 2001 18:27:18 -0400 Received: (qmail 17145 invoked from network); 11 Oct 2001 22:27:17 -0000 Received: from dyn-249.sfo.covalent.net (HELO covalent.net) (10.0.0.249) by mail.covalent.net with SMTP; 11 Oct 2001 22:27:17 -0000 Message-ID: <3BC61CAD.DE36C05D@covalent.net> Date: Thu, 11 Oct 2001 15:26:53 -0700 From: Carlos Hung X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 To: w3c-dist-auth@w3.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: How to avoid a PROPFIND method Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5409 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit I'm using the WebdavResource APIs in my application. Instantiating a WebdavResource(HttpURL url) generates a PROPFIND method. I've tried to instantiate it using: WebdavResource(HttpURL, WebdavResource.NOACTION, DepthSupport.DEPTH_0); I do avoid the PROPFIND method; but I get this error message in the web server error.log: "... request failed: error reading the headers" And my Put method fails. It seems that WebdavResource depends on a PROPFIND before a PUT method. Could someone please tell me how I could invoke a PUT without doing a PROPFIND method? Thanks, Carlos Hung From w3c-dist-auth-request@w3.org Thu Oct 11 18:52:04 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28028 for ; Thu, 11 Oct 2001 18:52:04 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAA18705; Thu, 11 Oct 2001 18:50:16 -0400 (EDT) Resent-Date: Thu, 11 Oct 2001 18:50:16 -0400 (EDT) Resent-Message-Id: <200110112250.SAA18705@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id SAA18685 for ; Thu, 11 Oct 2001 18:50:11 -0400 (EDT) Received: from mail.covalent.net (162-39.84.64.covalent.net [64.84.39.162] (may be forged)) by tux.w3.org (8.9.3/8.9.3) with SMTP id SAA26193 for ; Thu, 11 Oct 2001 18:50:10 -0400 Received: (qmail 29066 invoked from network); 11 Oct 2001 22:50:09 -0000 Received: from dyn-249.sfo.covalent.net (HELO covalent.net) (10.0.0.249) by mail.covalent.net with SMTP; 11 Oct 2001 22:50:09 -0000 Message-ID: <3BC6220A.73E7D394@covalent.net> Date: Thu, 11 Oct 2001 15:49:46 -0700 From: Carlos Hung X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 To: w3c-dist-auth@w3.org References: <3BC61CAD.DE36C05D@covalent.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: How to avoid a PROPFIND method Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5410 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit I'd like to add: I'd still like to use the WebdavResource APIs. Carlos Carlos Hung wrote: > I'm using the WebdavResource APIs in my application. > > Instantiating a WebdavResource(HttpURL url) generates a PROPFIND > method. > > I've tried to instantiate it using: > WebdavResource(HttpURL, WebdavResource.NOACTION, > DepthSupport.DEPTH_0); > > I do avoid the PROPFIND method; but I get this error message in the web > server error.log: > "... request failed: error reading the headers" > > And my Put method fails. > > It seems that WebdavResource depends on a PROPFIND before a PUT method. > > Could someone please tell me how I could invoke a PUT without doing a > PROPFIND method? > > Thanks, > Carlos Hung From w3c-dist-auth-request@w3.org Fri Oct 12 07:41:37 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22277 for ; Fri, 12 Oct 2001 07:41:37 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id HAA15290; Fri, 12 Oct 2001 07:32:35 -0400 (EDT) Resent-Date: Fri, 12 Oct 2001 07:32:35 -0400 (EDT) Resent-Message-Id: <200110121132.HAA15290@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id HAA15269 for ; Fri, 12 Oct 2001 07:32:27 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id HAA30676 for ; Fri, 12 Oct 2001 07:32:27 -0400 Received: (qmail 3411 invoked by uid 0); 12 Oct 2001 11:31:55 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mp004-rz3) with SMTP; 12 Oct 2001 11:31:55 -0000 From: "Julian Reschke" To: "Webdav WG" Date: Fri, 12 Oct 2001 13:32:47 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: Subject: PROPFIND behaviour regarding collections with non-listable members Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5411 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit I think we have identified something that needs to be clarified in RFC2518: Given a collection X, where the principal does have rights to list the collection itself, but not it's members. Currently our server will distinguish between depth 0 and 1, that is a PROPFIND with depth 0 will report the collection (and it's properties) OK, while a PROPFIND with depth 1 will result in something like: X HTTP/1.1 403 Forbidden This is because once a response element for X is available, there's no other way to distinguish between the case where the collection actually is empty, or the collection is non-empty, but the principal doesn't have the right to list it's members. Feedback appreciated. Julian From w3c-dist-auth-request@w3.org Fri Oct 12 08:10:57 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23251 for ; Fri, 12 Oct 2001 08:10:57 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id IAA16752; Fri, 12 Oct 2001 08:02:02 -0400 (EDT) Resent-Date: Fri, 12 Oct 2001 08:02:02 -0400 (EDT) Resent-Message-Id: <200110121202.IAA16752@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id IAA16724 for ; Fri, 12 Oct 2001 08:01:54 -0400 (EDT) Received: from greenbytes.de (mail.greenbytes.de [217.5.201.10] (may be forged)) by tux.w3.org (8.9.3/8.9.3) with ESMTP id IAA02776 for ; Fri, 12 Oct 2001 08:01:53 -0400 Received: from apu [192.168.1.2] by greenbytes.de [217.5.201.11] with SMTP (MDaemon.v3.5.3.R) for ; Fri, 12 Oct 2001 14:02:14 +0200 From: "Stefan Eissing" To: Date: Fri, 12 Oct 2001 14:02:44 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-MDRemoteIP: 192.168.1.2 X-Return-Path: stefan.eissing@greenbytes.de X-MDaemon-Deliver-To: w3c-dist-auth@w3.org Subject: COPY/MOVE and live properties Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5412 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Partly as result of the WebDAV interop event, I have the impression that no client or server does really care if live properties are kept or omitted when COPYing/MOVEing resources. Everyone does best effort. Furthermore, I suspect a server, respecting live property copying as defined in RFC2518, will have serious trouble interworking with any client. This will be especially true if the server supports deltaV (copy of version controlled/version resources on "plain" resource will lose a hell of a lot of live properties). Are my assumptions correct? Is this an issue for 2518++? //Stefan From w3c-dist-auth-request@w3.org Fri Oct 12 14:56:06 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07004 for ; Fri, 12 Oct 2001 14:56:06 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA04424; Fri, 12 Oct 2001 14:54:23 -0400 (EDT) Resent-Date: Fri, 12 Oct 2001 14:54:23 -0400 (EDT) Resent-Message-Id: <200110121854.OAA04424@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id OAA04404 for ; Fri, 12 Oct 2001 14:54:17 -0400 (EDT) Received: from sus-ma1it00.rational.com (ext-37055.rational.com [192.229.37.55]) by tux.w3.org (8.9.3/8.9.3) with SMTP id OAA20499 for ; Fri, 12 Oct 2001 14:54:17 -0400 Received: from 192.168.215.70 by sus-ma1it00.rational.com (InterScan E-Mail VirusWall NT); Fri, 12 Oct 2001 14:53:42 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id <4D3DDQ8Y>; Fri, 12 Oct 2001 14:53:42 -0400 Message-ID: <3906C56A7BD1F54593344C05BD1374B103F8AC97@SUS-MA1IT01> From: "Clemm, Geoff" To: Webdav WG Date: Fri, 12 Oct 2001 14:53:40 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: PROPFIND behaviour regarding collections with non-listable me mbers Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5413 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Depends on what you mean by "has the right to list the collection but not its members". If the client does not have the right to even see the names of the members, then the collection should just look empty, since the client should not be able to even know it has members. If the client has the right to see the name of members but not to see the properties of members, then listing their names with the Forbidden status seems reasonable to me. Cheers, Geoff -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de] Sent: Friday, October 12, 2001 7:33 AM To: Webdav WG Subject: PROPFIND behaviour regarding collections with non-listable members I think we have identified something that needs to be clarified in RFC2518: Given a collection X, where the principal does have rights to list the collection itself, but not it's members. Currently our server will distinguish between depth 0 and 1, that is a PROPFIND with depth 0 will report the collection (and it's properties) OK, while a PROPFIND with depth 1 will result in something like: X HTTP/1.1 403 Forbidden This is because once a response element for X is available, there's no other way to distinguish between the case where the collection actually is empty, or the collection is non-empty, but the principal doesn't have the right to list it's members. Feedback appreciated. Julian From w3c-dist-auth-request@w3.org Fri Oct 12 15:06:04 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07214 for ; Fri, 12 Oct 2001 15:06:03 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA04908; Fri, 12 Oct 2001 15:03:48 -0400 (EDT) Resent-Date: Fri, 12 Oct 2001 15:03:48 -0400 (EDT) Resent-Message-Id: <200110121903.PAA04908@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id PAA04885 for ; Fri, 12 Oct 2001 15:03:43 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id PAA21536 for ; Fri, 12 Oct 2001 15:03:43 -0400 Received: (qmail 23191 invoked by uid 0); 12 Oct 2001 19:02:47 -0000 Received: from pd953546f.dip.t-dialin.net (HELO lisa) (217.83.84.111) by mail.gmx.net (mp009-rz3) with SMTP; 12 Oct 2001 19:02:47 -0000 From: "Julian Reschke" To: "Clemm, Geoff" , "Webdav WG" Date: Fri, 12 Oct 2001 21:03:39 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <3906C56A7BD1F54593344C05BD1374B103F8AC97@SUS-MA1IT01> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Subject: RE: PROPFIND behaviour regarding collections with non-listable me mbers Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5414 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Well, that's something we could do, but that would hide the difference between a collection that's empty and a collection where you don't have "list" permission to. I'm not sure this is a good idea. > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff > Sent: Friday, October 12, 2001 8:54 PM > To: Webdav WG > Subject: RE: PROPFIND behaviour regarding collections with non-listable > me mbers > > > Depends on what you mean by "has the right to list the collection > but not its members". If the client does not have the right to even > see the names of the members, then the collection should just look > empty, since the client should not be able to even know it has > members. If the client has the right to see the name of members > but not to see the properties of members, then listing their names > with the Forbidden status seems reasonable to me. > > Cheers, > Geoff > > -----Original Message----- > From: Julian Reschke [mailto:julian.reschke@gmx.de] > Sent: Friday, October 12, 2001 7:33 AM > To: Webdav WG > Subject: PROPFIND behaviour regarding collections with non-listable > members > > > I think we have identified something that needs to be clarified > in RFC2518: > > Given a collection X, where the principal does have rights to list the > collection itself, but not it's members. > > Currently our server will distinguish between depth 0 and 1, that is a > PROPFIND with depth 0 will report the collection (and it's properties) OK, > while a PROPFIND with depth 1 will result in something like: > > > X > HTTP/1.1 403 Forbidden > > > This is because once a response element for X is available, > there's no other > way to distinguish between the case where the collection actually > is empty, > or the collection is non-empty, but the principal doesn't have > the right to > list it's members. > > Feedback appreciated. > > Julian > From w3c-dist-auth-request@w3.org Fri Oct 12 16:30:59 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08960 for ; Fri, 12 Oct 2001 16:30:58 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA09030; Fri, 12 Oct 2001 16:29:16 -0400 (EDT) Resent-Date: Fri, 12 Oct 2001 16:29:16 -0400 (EDT) Resent-Message-Id: <200110122029.QAA09030@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id QAA09006 for ; Fri, 12 Oct 2001 16:29:08 -0400 (EDT) Received: from front1.mail.megapathdsl.net (front1.mail.megapathdsl.net [66.80.60.31]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id QAA32196 for ; Fri, 12 Oct 2001 16:29:09 -0400 Received: from [64.139.0.223] (HELO beaver) by front1.mail.megapathdsl.net (CommuniGate Pro SMTP 3.4.8a) with SMTP id 8641795; Fri, 12 Oct 2001 13:21:37 -0700 From: "Lisa Dusseault" To: "Clemm, Geoff" , "Webdav WG" Date: Fri, 12 Oct 2001 13:28:03 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <3906C56A7BD1F54593344C05BD1374B103F8AC97@SUS-MA1IT01> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Subject: RE: PROPFIND behaviour regarding collections with non-listable me mbers Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5415 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit The Xythos WFS approach to this problem is the former described by Geoff. If you don't have permission to view anything inside a directory but you do have permission to view the directory, then the directory will appear empty. lisa > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff > Sent: Friday, October 12, 2001 11:54 AM > To: Webdav WG > Subject: RE: PROPFIND behaviour regarding collections with non-listable > me mbers > > > Depends on what you mean by "has the right to list the collection > but not its members". If the client does not have the right to even > see the names of the members, then the collection should just look > empty, since the client should not be able to even know it has > members. If the client has the right to see the name of members > but not to see the properties of members, then listing their names > with the Forbidden status seems reasonable to me. > > Cheers, > Geoff > > -----Original Message----- > From: Julian Reschke [mailto:julian.reschke@gmx.de] > Sent: Friday, October 12, 2001 7:33 AM > To: Webdav WG > Subject: PROPFIND behaviour regarding collections with non-listable > members > > > I think we have identified something that needs to be clarified > in RFC2518: > > Given a collection X, where the principal does have rights to list the > collection itself, but not it's members. > > Currently our server will distinguish between depth 0 and 1, that is a > PROPFIND with depth 0 will report the collection (and it's properties) OK, > while a PROPFIND with depth 1 will result in something like: > > > X > HTTP/1.1 403 Forbidden > > > This is because once a response element for X is available, > there's no other > way to distinguish between the case where the collection actually > is empty, > or the collection is non-empty, but the principal doesn't have > the right to > list it's members. > > Feedback appreciated. > > Julian From w3c-dist-auth-request@w3.org Fri Oct 12 19:01:00 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10742 for ; Fri, 12 Oct 2001 19:00:59 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAA13442; Fri, 12 Oct 2001 18:58:19 -0400 (EDT) Resent-Date: Fri, 12 Oct 2001 18:58:19 -0400 (EDT) Resent-Message-Id: <200110122258.SAA13442@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id SAA13422 for ; Fri, 12 Oct 2001 18:58:10 -0400 (EDT) Received: from adobe.com (smtp-relay-2.adobe.com [192.150.11.2]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id SAA13578 for ; Fri, 12 Oct 2001 18:58:10 -0400 Received: from inner-relay-2.corp.adobe.com ([153.32.1.52]) by adobe.com (1.0.0/8.11.4) with ESMTP id f9CMuvP19075 for ; Fri, 12 Oct 2001 15:56:57 -0700 (PDT) Received: from mailsj-v1.corp.adobe.com (mailsj-dev.corp.adobe.com [153.32.1.192]) by inner-relay-2.corp.adobe.com (8.11.4/8.11.4) with ESMTP id f9CMuw111186 for ; Fri, 12 Oct 2001 15:56:58 -0700 (PDT) Received: from [153.32.159.137] ([130.248.184.86]) by mailsj-v1.corp.adobe.com (Netscape Messaging Server 4.15 v1 Jul 11 2001 16:32:57) with ESMTP id GL47RX00.UW9; Fri, 12 Oct 2001 15:57:33 -0700 Mime-Version: 1.0 X-Sender: dbrotsky@mailsj.corp.adobe.com Message-Id: In-Reply-To: References: Date: Fri, 12 Oct 2001 15:56:45 -0700 To: "Julian Reschke" From: Daniel Brotsky Cc: "Clemm, Geoff" , "Webdav WG" Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: RE: PROPFIND behaviour regarding collections with non-listable me mbers Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5416 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: At 9:03 PM +0200 10/12/01, Julian Reschke wrote: >Well, > >that's something we could do, but that would hide the difference between a >collection that's empty and a collection where you don't have "list" >permission to. When security is so tight that people aren't allowed to even know about the existence or non-existence of members, these cases (a collection that's empty versus one that contains members "invisible to you") aren't supposed to be distinguishable. To see this, consider the case where a collection has some visible and some invisible members (from a particular user's point of view): just the visible members should be listed. But I think there's an entirely different spec issue here: whether or not DAV collections can hide the existence of members at all. Section 8.1 on PROPFIND says: Consequently, the multistatus XML element for a collection resource with member URIs MUST include a response XML element for each member URI of the collection, to whatever depth was requested. Each response XML element MUST contain an href XML element that gives the URI of the resource on which the properties in the prop XML element are defined. This seems to require you either: a. to list the members and then say 403 for any properties, or b. to return 403 for any PROPFIND with depth > 0 on the containing collection. Note that neither of these options meets the security requirements of "a user must not be able to determine whether or not a collection has a given member," but I don't think that 2518 intended to make it illegal for servers to enforce this kind of security. So I think there is a spec issue here. dan > I'm not sure this is a good idea. > >> -----Original Message----- >> From: w3c-dist-auth-request@w3.org >> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff >> Sent: Friday, October 12, 2001 8:54 PM >> To: Webdav WG >> Subject: RE: PROPFIND behaviour regarding collections with non-listable >> me mbers >> >> >> Depends on what you mean by "has the right to list the collection >> but not its members". If the client does not have the right to even >> see the names of the members, then the collection should just look >> empty, since the client should not be able to even know it has >> members. If the client has the right to see the name of members >> but not to see the properties of members, then listing their names >> with the Forbidden status seems reasonable to me. >> >> Cheers, >> Geoff >> >> -----Original Message----- >> From: Julian Reschke [mailto:julian.reschke@gmx.de] >> Sent: Friday, October 12, 2001 7:33 AM >> To: Webdav WG >> Subject: PROPFIND behaviour regarding collections with non-listable >> members >> >> >> I think we have identified something that needs to be clarified >> in RFC2518: >> >> Given a collection X, where the principal does have rights to list the >> collection itself, but not it's members. >> >> Currently our server will distinguish between depth 0 and 1, that is a >> PROPFIND with depth 0 will report the collection (and it's properties) OK, >> while a PROPFIND with depth 1 will result in something like: >> >> >> X >> HTTP/1.1 403 Forbidden >> >> >> This is because once a response element for X is available, >> there's no other >> way to distinguish between the case where the collection actually >> is empty, >> or the collection is non-empty, but the principal doesn't have >> the right to >> list it's members. >> >> Feedback appreciated. >> >> Julian >> -- Daniel Brotsky, Adobe Systems tel 408-536-4150, pager 877-704-4062 2-way pager email: From w3c-dist-auth-request@w3.org Sat Oct 13 05:39:00 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02386 for ; Sat, 13 Oct 2001 05:39:00 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id FAA24013; Sat, 13 Oct 2001 05:36:56 -0400 (EDT) Resent-Date: Sat, 13 Oct 2001 05:36:56 -0400 (EDT) Resent-Message-Id: <200110130936.FAA24013@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id FAA23993 for ; Sat, 13 Oct 2001 05:36:46 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id FAA19614 for ; Sat, 13 Oct 2001 05:36:46 -0400 Received: (qmail 3831 invoked by uid 0); 13 Oct 2001 09:36:15 -0000 Received: from pd9e51dae.dip.t-dialin.net (HELO lisa) (217.229.29.174) by mail.gmx.net (mp003-rz3) with SMTP; 13 Oct 2001 09:36:15 -0000 From: "Julian Reschke" To: "Daniel Brotsky" , "Julian Reschke" Cc: "Clemm, Geoff" , "Webdav WG" Date: Sat, 13 Oct 2001 11:37:06 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-reply-to: Importance: Normal Subject: RE: PROPFIND behaviour regarding collections with non-listable me mbers Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5417 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Daniel Brotsky > Sent: Saturday, October 13, 2001 12:57 AM > To: Julian Reschke > Cc: Clemm, Geoff; Webdav WG > Subject: RE: PROPFIND behaviour regarding collections with non-listable > me mbers > > > At 9:03 PM +0200 10/12/01, Julian Reschke wrote: > >Well, > > > >that's something we could do, but that would hide the difference > between a > >collection that's empty and a collection where you don't have "list" > >permission to. > > When security is so tight that people aren't allowed to even know > about the existence or non-existence of members, these cases (a > collection that's empty versus one that contains members "invisible > to you") aren't supposed to be distinguishable. To see this, > consider the case where a collection has some visible and some > invisible members (from a particular user's point of view): just the > visible members should be listed. > > But I think there's an entirely different spec issue here: whether or > not DAV collections can hide the existence of members at all. > Section 8.1 on PROPFIND says: I think this is exactly the reason why I got to my current approach. > Consequently, the multistatus XML element for a collection resource > with member URIs MUST include a response XML element for each member > URI of the collection, to whatever depth was requested. Each response > XML element MUST contain an href XML element that gives the URI of > the resource on which the properties in the prop XML element are > defined. > > This seems to require you either: > > a. to list the members and then say 403 for any properties, or ...I think I remember this will break existing clients like Adobe GoLive ([1]) that expect the (live) property to be either returned *with* value, or to be silently dropped. > > b. to return 403 for any PROPFIND with depth > 0 on the > containing collection. > > Note that neither of these options meets the security requirements of > "a user must not be able to determine whether or not a collection has > a given member," but I don't think that 2518 intended to make it > illegal for servers to enforce this kind of security. So I think > there is a spec issue here. So obviously we've got a spec issue here, and it probably should be resolved together with: [1] From w3c-dist-auth-request@w3.org Mon Oct 15 17:49:02 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13001 for ; Mon, 15 Oct 2001 17:49:02 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA14312; Mon, 15 Oct 2001 17:41:39 -0400 (EDT) Resent-Date: Mon, 15 Oct 2001 17:41:39 -0400 (EDT) Resent-Message-Id: <200110152141.RAA14312@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id RAA14271 for ; Mon, 15 Oct 2001 17:41:31 -0400 (EDT) Received: from mail0.rawbw.com (mail0.rawbw.com [198.144.192.41]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id RAA07483 for ; Mon, 15 Oct 2001 17:41:30 -0400 Received: from beaver ([198.144.203.248]) by mail0.rawbw.com (8.11.3/8.11.3) with SMTP id f9FLfIk60906 for ; Mon, 15 Oct 2001 14:41:18 -0700 (PDT) (envelope-from lisa@xythos.com) From: "Lisa Dusseault" To: Date: Mon, 15 Oct 2001 14:40:39 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Subject: Re: Possible bug mod_dav 1.0.2 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5418 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Julian, you've reported a bug for mod_dav and Xythos WFS: "a) Set a dead property with no namespace, for instance by: 123 This works, no error is reported." Is it your contention that an error SHOULD be reported? That was unclear from the mail and posting. I've taken a look at the primary sources: From http://www.w3.org/TR/1999/REC-xml-names-19990114/#NT-NCName: "The attribute's value, a URI reference, is the namespace name identifying the namespace. The namespace name, to serve its intended purpose, should have the characteristics of uniqueness and persistence. It is not a goal that it be directly usable for retrieval of a schema (if any exists). An example of a syntax that is designed with these goals in mind is that for Uniform Resource Names [RFC2141]. However, it should be noted that ordinary URLs can be managed in such a way as to achieve these same goals." From http://www.ietf.org/rfc/rfc2396.txt: "A URI reference that does not contain a URI is a reference to the current document." However, the "current document" does not have an identity, so this can't work for WebDAV requests. This is unfortunately ambiguous, but I conclude that the original request that is mentioned in this bug should never have been accepted, because it contains a null namespace which can't be a reference to the current document. It should have been rejected with 400 Bad Request. Do you agree? Lisa From w3c-dist-auth-request@w3.org Mon Oct 15 18:39:47 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14682 for ; Mon, 15 Oct 2001 18:39:47 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAA16433; Mon, 15 Oct 2001 18:37:35 -0400 (EDT) Resent-Date: Mon, 15 Oct 2001 18:37:35 -0400 (EDT) Resent-Message-Id: <200110152237.SAA16433@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id SAA16413 for ; Mon, 15 Oct 2001 18:37:31 -0400 (EDT) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id SAA13385 for ; Mon, 15 Oct 2001 18:37:30 -0400 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id SAA58978; Mon, 15 Oct 2001 18:34:32 -0400 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.117.200.72]) by northrelay02.pok.ibm.com (8.11.1m3/NCO v4.98) with ESMTP id f9FMavA210532; Mon, 15 Oct 2001 18:36:57 -0400 To: "Julian Reschke" Cc: "Webdav WG" X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "Jason Crawford" Date: Mon, 15 Oct 2001 18:20:18 -0400 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Build V509_10042001 |October 4, 2001) at 10/15/2001 06:36:57 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: Re: RFC2518 ambiguity on creationdate/lastmodifieddate Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5419 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: > > if for some reason a server doesn't have one of these timestamps for a > resource, what should it report on PROPFIND for these properties? > > a) Property not found (HTTP 404), > > b) Empty property (this seem to be backed by the wording in section 7.4 [1], > but is reported as error by Adobe GoLive, > > c) Property silently suppressed (not reported at all) -- this seems to work > with GoLive. > > In addition, how should the server behaviour upon a PROPFIND/propname on > this resource? This seems like an easy issue to resolve. Let's address it now. My preference is that if it's a property name that was explicitly requested, then it should be listed as Not Found. If the PROPFIND doesn't list it explicitly, then it should simply not be listed. Comments? J. From w3c-dist-auth-request@w3.org Mon Oct 15 20:01:00 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15793 for ; Mon, 15 Oct 2001 20:01:00 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id TAA18818; Mon, 15 Oct 2001 19:58:12 -0400 (EDT) Resent-Date: Mon, 15 Oct 2001 19:58:12 -0400 (EDT) Resent-Message-Id: <200110152358.TAA18818@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id TAA18797 for ; Mon, 15 Oct 2001 19:58:06 -0400 (EDT) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id TAA20414 for ; Mon, 15 Oct 2001 19:58:07 -0400 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id TAA489328; Mon, 15 Oct 2001 19:55:09 -0400 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.117.200.72]) by northrelay02.pok.ibm.com (8.11.1m3/NCO v4.98) with ESMTP id f9FNvXA145384; Mon, 15 Oct 2001 19:57:33 -0400 To: Daniel Brotsky Cc: "Webdav WG" X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "Jason Crawford" Date: Mon, 15 Oct 2001 19:40:01 -0400 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Build V509_10042001 |October 4, 2001) at 10/15/2001 07:57:33 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: RE: PROPFIND behaviour regarding collections with non-listable me mbers Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5420 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: <> But I think we agree that if someone isn't allowed to see if an element exists, then you simply don't list it as a member of a collection. (FWIW... They might of course find out some other way if a given URL is mapped.) So do we want to fix up the spec, defer the clarification, or let it go? J. From w3c-dist-auth-request@w3.org Tue Oct 16 03:24:34 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06843 for ; Tue, 16 Oct 2001 03:24:34 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id DAA13978; Tue, 16 Oct 2001 03:18:40 -0400 (EDT) Resent-Date: Tue, 16 Oct 2001 03:18:40 -0400 (EDT) Resent-Message-Id: <200110160718.DAA13978@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id DAA13944 for ; Tue, 16 Oct 2001 03:18:28 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id DAA01708 for ; Tue, 16 Oct 2001 03:18:28 -0400 Received: (qmail 10238 invoked by uid 0); 16 Oct 2001 07:18:24 -0000 Received: from pd95354b6.dip.t-dialin.net (HELO lisa) (217.83.84.182) by mail.gmx.net (mp003-rz3) with SMTP; 16 Oct 2001 07:18:24 -0000 From: "Julian Reschke" To: "Lisa Dusseault" , Date: Tue, 16 Oct 2001 09:19:13 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: Subject: RE: Possible bug mod_dav 1.0.2 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5421 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault > Sent: Monday, October 15, 2001 11:41 PM > To: w3c-dist-auth@w3.org > Subject: Re: Possible bug mod_dav 1.0.2 > > > > Julian, you've reported a bug for mod_dav and Xythos WFS: > > "a) Set a dead property with no namespace, for instance by: > > > > > 123 > > > > > This works, no error is reported." > > Is it your contention that an error SHOULD be reported? That was unclear > >from the mail and posting. No, I just wanted to indicate that the "precondition" for this test (that the property was created) was OK. > I've taken a look at the primary sources: > > >From http://www.w3.org/TR/1999/REC-xml-names-19990114/#NT-NCName: > > "The attribute's value, a URI reference, is the namespace name identifying > the namespace. The namespace name, to serve its intended purpose, should > have the characteristics of uniqueness and persistence. It is not a goal > that it be directly usable for retrieval of a schema (if any exists). An > example of a syntax that is designed with these goals in mind is that for > Uniform Resource Names [RFC2141]. However, it should be noted > that ordinary > URLs can be managed in such a way as to achieve these same goals." > > >From http://www.ietf.org/rfc/rfc2396.txt: > > "A URI reference that does not contain a URI is a reference to the current > document." > > However, the "current document" does not have an identity, so this can't > work for WebDAV requests. This is unfortunately ambiguous, but I conclude > that the original request that is mentioned in this bug should never have > been accepted, because it contains a null namespace which can't be a > reference to the current document. It should have been rejected with 400 > Bad Request. Do you agree? No, it's simply a property that is in no namespace. If you feel better with the notation, consider: 123 This sets the property "bar" (which is in no namespace). They key sentence in XNLMS is from : [Definition:] If the attribute name matches DefaultAttName, then the namespace name in the attribute value is that of the default namespace in the scope of the element to which the declaration is attached. In such a default declaration, the attribute value may be empty. Default namespaces and overriding of declarations are discussed in "5. Applying Namespaces to Elements and Attributes". So using xmlns="" is a special case where the value of the attribute *isn't* a URI -- it's a notation to "undeclare" the previously defined default namespace. What needs to be fixed in the way the property values are marshalled (in the two servers) is the following: if an element is in no namespace (in DOM2: namespaceUri is null), then it MUST be serialized without a prefix (and the default namespace undeclared if previously declared). That's the only XMLNS-wellfomed way to represent elements that are in no namespace. Julian From w3c-dist-auth-request@w3.org Tue Oct 16 11:49:53 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05144 for ; Tue, 16 Oct 2001 11:49:53 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id LAA05563; Tue, 16 Oct 2001 11:14:07 -0400 (EDT) Resent-Date: Tue, 16 Oct 2001 11:14:07 -0400 (EDT) Resent-Message-Id: <200110161514.LAA05563@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id LAA05540 for ; Tue, 16 Oct 2001 11:14:03 -0400 (EDT) Received: from opentext.com (drawbridge.opentext.com [204.138.115.3]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id LAA28199 for ; Tue, 16 Oct 2001 11:14:03 -0400 Received: (from root@localhost) by opentext.com (8.9.3/8.9.3) id LAA00991 for ; Tue, 16 Oct 2001 11:13:27 -0400 Received: from 022.dhcp2.liv.opentext.com(172.17.2.22) by krusty.wl.opentext.com via smap (V2.1) id xma000969; Tue, 16 Oct 01 11:13:25 -0400 From: "Dylan Barrell" To: "WebDAV" Date: Tue, 16 Oct 2001 11:12:37 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Subject: Digest Authentication Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5422 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit I would like to propose a small change to the webDAV specification. Digest Authentication requires that a server store its passwords in such a way that they be available in clear text format. Our experience with our customers has shown that this is TOTALLY UNACCEPTABLE. As a result, we will not be able to implement digest authentication in our webDAV server. I would like to propose that the Digest Authentication requirement be demoted from mandatory to optional. --Dylan From w3c-dist-auth-request@w3.org Tue Oct 16 11:54:07 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05725 for ; Tue, 16 Oct 2001 11:54:07 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id LAA09137; Tue, 16 Oct 2001 11:47:37 -0400 (EDT) Resent-Date: Tue, 16 Oct 2001 11:47:37 -0400 (EDT) Resent-Message-Id: <200110161547.LAA09137@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id LAA09117 for ; Tue, 16 Oct 2001 11:47:33 -0400 (EDT) Received: from sus-ma1it00.rational.com (ext-37021.rational.com [192.229.37.21]) by tux.w3.org (8.9.3/8.9.3) with SMTP id LAA01291 for ; Tue, 16 Oct 2001 11:47:33 -0400 Received: from 192.168.215.70 by sus-ma1it00.rational.com (InterScan E-Mail VirusWall NT); Tue, 16 Oct 2001 11:47:02 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id <4D3DJ742>; Tue, 16 Oct 2001 11:47:02 -0400 Message-ID: <3906C56A7BD1F54593344C05BD1374B103F8ACB0@SUS-MA1IT01> From: "Clemm, Geoff" To: WebDAV Date: Tue, 16 Oct 2001 11:46:53 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Digest Authentication Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5423 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Are you sure you are not confusing digest authentication with basic authentication? With digest authentication, a server only needs to expose its passwords in a cryptographically secure hash-coded form. Cheers, Geoff -----Original Message----- From: Dylan Barrell [mailto:dbarrell@opentext.com] Sent: Tuesday, October 16, 2001 11:13 AM To: WebDAV Subject: Digest Authentication I would like to propose a small change to the webDAV specification. Digest Authentication requires that a server store its passwords in such a way that they be available in clear text format. Our experience with our customers has shown that this is TOTALLY UNACCEPTABLE. As a result, we will not be able to implement digest authentication in our webDAV server. I would like to propose that the Digest Authentication requirement be demoted from mandatory to optional. --Dylan From w3c-dist-auth-request@w3.org Tue Oct 16 12:00:35 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06671 for ; Tue, 16 Oct 2001 12:00:35 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id LAA10322; Tue, 16 Oct 2001 11:56:28 -0400 (EDT) Resent-Date: Tue, 16 Oct 2001 11:56:28 -0400 (EDT) Resent-Message-Id: <200110161556.LAA10322@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id LAA10299 for ; Tue, 16 Oct 2001 11:56:23 -0400 (EDT) Received: from greenbytes.de (mail.greenbytes.de [217.5.201.10] (may be forged)) by tux.w3.org (8.9.3/8.9.3) with ESMTP id LAA03269 for ; Tue, 16 Oct 2001 11:56:23 -0400 Received: from apu [192.168.1.2] by greenbytes.de [217.5.201.11] with SMTP (MDaemon.v3.5.3.R) for ; Tue, 16 Oct 2001 17:56:27 +0200 From: "Stefan Eissing" To: "Clemm, Geoff" , "WebDAV" Date: Tue, 16 Oct 2001 17:56:57 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal In-Reply-To: <3906C56A7BD1F54593344C05BD1374B103F8ACB0@SUS-MA1IT01> X-MDRemoteIP: 192.168.1.2 X-Return-Path: stefan.eissing@greenbytes.de X-MDaemon-Deliver-To: w3c-dist-auth@w3.org Subject: RE: Digest Authentication Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5424 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Actually, you do not need to store cleartext in both cases. As Geoff explained, digest requires the server to store a secure hash of the username/password. You can use the same hash to verify Basic authentication, since the client send the password in (almost) clear text. Best Regards, Stefan > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff > Sent: Tuesday, October 16, 2001 5:47 PM > To: WebDAV > Subject: RE: Digest Authentication > > > Are you sure you are not confusing digest authentication with basic > authentication? With digest authentication, a server only needs to > expose its passwords in a cryptographically secure hash-coded form. > > Cheers, > Geoff > > -----Original Message----- > From: Dylan Barrell [mailto:dbarrell@opentext.com] > Sent: Tuesday, October 16, 2001 11:13 AM > To: WebDAV > Subject: Digest Authentication > > > I would like to propose a small change to the webDAV specification. > > Digest Authentication requires that a server store its passwords in such a > way that they be available in clear text format. > > Our experience with our customers has shown that this is TOTALLY > UNACCEPTABLE. > > As a result, we will not be able to implement digest authentication in our > webDAV server. > > I would like to propose that the Digest Authentication requirement be > demoted from mandatory to optional. > > --Dylan > > > From w3c-dist-auth-request@w3.org Tue Oct 16 12:07:08 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07485 for ; Tue, 16 Oct 2001 12:07:08 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA11123; Tue, 16 Oct 2001 12:03:59 -0400 (EDT) Resent-Date: Tue, 16 Oct 2001 12:03:59 -0400 (EDT) Resent-Message-Id: <200110161603.MAA11123@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id MAA11103 for ; Tue, 16 Oct 2001 12:03:55 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id MAA04875 for ; Tue, 16 Oct 2001 12:03:55 -0400 Received: (qmail 13719 invoked by uid 0); 16 Oct 2001 16:03:24 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mp010-rz3) with SMTP; 16 Oct 2001 16:03:24 -0000 From: "Julian Reschke" To: "WebDAV" Date: Tue, 16 Oct 2001 18:04:12 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-reply-to: <3906C56A7BD1F54593344C05BD1374B103F8ACB0@SUS-MA1IT01> Subject: RFC2518 / ACL responsedescription/description vs xml:lang Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5425 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi. RFC2518 and ACL define elements that contain a text that "that can be displayed to the user explaining the nature of the response" ([1]) or "is a human-readable description of what this privilege controls access to" ([2]). Both specs avoid speaking of I18N in this context. I suggest the following: 1) Add wording specifying that these elements MUST be labelled with xml:lang, and that server SHOULD use the HTTP Accept-Language headers to determine a suitable language. 2) Update the examples to include xml:lang="en". [1] [2] From w3c-dist-auth-request@w3.org Tue Oct 16 12:26:18 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09307 for ; Tue, 16 Oct 2001 12:26:17 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA11962; Tue, 16 Oct 2001 12:18:09 -0400 (EDT) Resent-Date: Tue, 16 Oct 2001 12:18:09 -0400 (EDT) Resent-Message-Id: <200110161618.MAA11962@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id MAA11942 for ; Tue, 16 Oct 2001 12:18:05 -0400 (EDT) Received: from greenbytes.de (mail.greenbytes.de [217.5.201.10] (may be forged)) by tux.w3.org (8.9.3/8.9.3) with ESMTP id MAA07199 for ; Tue, 16 Oct 2001 12:18:04 -0400 Received: from apu [192.168.1.2] by greenbytes.de [217.5.201.11] with SMTP (MDaemon.v3.5.3.R) for ; Tue, 16 Oct 2001 18:18:48 +0200 From: "Stefan Eissing" To: "WebDAV" Date: Tue, 16 Oct 2001 18:19:20 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal In-Reply-To: X-MDRemoteIP: 192.168.1.2 X-Return-Path: stefan.eissing@greenbytes.de X-MDaemon-Deliver-To: w3c-dist-auth@w3.org Subject: RE: Digest Authentication Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5426 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit As an afterthought: If Dylan wants to be safe that somebody stealing the encrypted passwords cannot log in to the server, then Digest Authentication is indeed not a good idea. (See RFC 2617, Chapter 4.13). If you need to be safe in the case of stolen "password files", you need to upgrade to TLS and basic auth or use client certs. //Stefan > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Stefan Eissing > Sent: Tuesday, October 16, 2001 5:57 PM > To: Clemm, Geoff; WebDAV > Subject: RE: Digest Authentication > > > Actually, you do not need to store cleartext in both cases. > > As Geoff explained, digest requires the server to store > a secure hash of the username/password. You can use the > same hash to verify Basic authentication, since the client > send the password in (almost) clear text. > > Best Regards, Stefan > > > -----Original Message----- > > From: w3c-dist-auth-request@w3.org > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff > > Sent: Tuesday, October 16, 2001 5:47 PM > > To: WebDAV > > Subject: RE: Digest Authentication > > > > > > Are you sure you are not confusing digest authentication with basic > > authentication? With digest authentication, a server only needs to > > expose its passwords in a cryptographically secure hash-coded form. > > > > Cheers, > > Geoff > > > > -----Original Message----- > > From: Dylan Barrell [mailto:dbarrell@opentext.com] > > Sent: Tuesday, October 16, 2001 11:13 AM > > To: WebDAV > > Subject: Digest Authentication > > > > > > I would like to propose a small change to the webDAV specification. > > > > Digest Authentication requires that a server store its > passwords in such a > > way that they be available in clear text format. > > > > Our experience with our customers has shown that this is TOTALLY > > UNACCEPTABLE. > > > > As a result, we will not be able to implement digest > authentication in our > > webDAV server. > > > > I would like to propose that the Digest Authentication requirement be > > demoted from mandatory to optional. > > > > --Dylan > > > > > > > > From w3c-dist-auth-request@w3.org Tue Oct 16 12:49:28 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10128 for ; Tue, 16 Oct 2001 12:49:28 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA13025; Tue, 16 Oct 2001 12:46:08 -0400 (EDT) Resent-Date: Tue, 16 Oct 2001 12:46:08 -0400 (EDT) Resent-Message-Id: <200110161646.MAA13025@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id MAA12989 for ; Tue, 16 Oct 2001 12:46:02 -0400 (EDT) Received: from cats.ucsc.edu (rumpleteazer.ucsc.edu [128.114.129.45]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id MAA10567 for ; Tue, 16 Oct 2001 12:46:02 -0400 Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177]) by cats.ucsc.edu (8.9.3/8.8.4.cats-athena) with SMTP id JAA11082 for ; Tue, 16 Oct 2001 09:46:05 -0700 (PDT) From: "Jim Whitehead" To: "WebDAV" Date: Tue, 16 Oct 2001 09:42:15 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-reply-to: <3906C56A7BD1F54593344C05BD1374B103F8ACB0@SUS-MA1IT01> Importance: Normal Subject: RE: Digest Authentication Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5427 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Geoff Clemm writes: > Are you sure you are not confusing digest authentication with basic > authentication? With digest authentication, a server only needs to > expose its passwords in a cryptographically secure hash-coded form. I'm going to make an educated guess here. Since Dylan works on a DAV server called "Livelink Gateway", I suspect the architecture of this implementation is a wrapper around an existing content management system, Livelink. I will also guess that Livelink does not natively handle Digest authentication. Hence, to handle Digest authentication the Livelink Gateway needs to be able to convert the hashed username/password pair it receives from the client into a cleartext version of same, which it can then pass along to Livelink. The alternative is to change Livelink itself so it can handle Digest authentication. Then the gateway can call Livelink, pass the Digest credentials, and then get back a pass/fail result. However, this requires changing the API to Livelink, and requires that customers who add the Livelink Gateway must update Livelink as well. That all said, I'm not very much in favor of weakening the Digest authentication requirements. Trends on the Internet are towards greater security, and the recent rash of attacks on Web servers shows that the cracker community has an interest in breaking Web servers. I suspect that as DAV becomes more mainstream, it will in turn be a focus of attacks. I'd like for us to have a solid security infrastructure in place when this day comes. - Jim From w3c-dist-auth-request@w3.org Tue Oct 16 14:07:39 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13362 for ; Tue, 16 Oct 2001 14:07:38 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA17120; Tue, 16 Oct 2001 14:02:19 -0400 (EDT) Resent-Date: Tue, 16 Oct 2001 14:02:19 -0400 (EDT) Resent-Message-Id: <200110161802.OAA17120@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id OAA17097 for ; Tue, 16 Oct 2001 14:02:14 -0400 (EDT) Received: from kim.ispra.webweaving.org (IDENT:CHUCK@adsl-66-124-87-42.dsl.snfc21.pacbell.net [66.124.87.42]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id OAA19130 for ; Tue, 16 Oct 2001 14:02:13 -0400 Received: from kim.ispra.webweaving.org (kim.ispra.webweaving.org [10.10.0.2]) by kim.ispra.webweaving.org (8.8.8/8.8.5) with ESMTP id SAA08657; Tue, 16 Oct 2001 18:01:47 GMT X-Passed: MX on Ispra.WebWeaving.org Tue, 16 Oct 2001 18:01:47 GMT and masked X-No-Spam: Neither the receipients nor the senders email address(s) are to be used for Unsolicited (Commercial) Email without the explicit written consent of either party; as a per-message fee is incurred for inbound and outbound traffic to the originator. Posted-Date: Tue, 16 Oct 2001 18:01:47 GMT Date: Tue, 16 Oct 2001 20:01:46 +0200 (CEST) From: Dirk-Willem van Gulik X-Sender: dirkx@kim.ispra.webweaving.org To: Dylan Barrell cc: WebDAV In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: Digest Authentication Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5428 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: On Tue, 16 Oct 2001, Dylan Barrell wrote: > Digest Authentication requires that a server store its passwords in such a > way that they be available in clear text format. Actually though your implementation -could- store the password on disk as plain text - most do not; and it is technically not required. Some bad implementations do store it plain - but (for example) the apache web server stores the password as a hash (md5 or crypt) on the server side. See http://cvs.apache.org -> apache-1.3 -> src/support/htpasswd.c and src/support/htdigest.c to get an idea of the code). So it is not a requirement - just an implementation choise. It is true that with normal basic auth the password goes over the wire in the clear; but with digest auth this is not the case. Dw From w3c-dist-auth-request@w3.org Tue Oct 16 14:42:19 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14838 for ; Tue, 16 Oct 2001 14:42:19 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA19531; Tue, 16 Oct 2001 14:38:25 -0400 (EDT) Resent-Date: Tue, 16 Oct 2001 14:38:25 -0400 (EDT) Resent-Message-Id: <200110161838.OAA19531@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id OAA19510 for ; Tue, 16 Oct 2001 14:38:21 -0400 (EDT) Received: from opentext.com (drawbridge.opentext.com [204.138.115.3]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id OAA23850 for ; Tue, 16 Oct 2001 14:38:20 -0400 Received: (from root@localhost) by opentext.com (8.9.3/8.9.3) id OAA01365; Tue, 16 Oct 2001 14:37:50 -0400 Received: from 022.dhcp2.liv.opentext.com(172.17.2.22) by krusty.wl.opentext.com via smap (V2.1) id xma001352; Tue, 16 Oct 01 14:37:46 -0400 From: "Dylan Barrell" To: "Dirk-Willem van Gulik" Cc: "WebDAV" Date: Tue, 16 Oct 2001 14:36:56 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: Subject: RE: Digest Authentication Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5429 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit We did think of this solution, but that means that we always have to use the same nonce value and we end up getting no security improvement over basic authentication - so the argument that it is more secure than basic is bogus if you do this. --Dylan > -----Original Message----- > From: Dirk-Willem van Gulik [mailto:dirkx@webweaving.org] > Sent: Tuesday, October 16, 2001 2:02 PM > To: Dylan Barrell > Cc: WebDAV > Subject: Re: Digest Authentication > > > > > On Tue, 16 Oct 2001, Dylan Barrell wrote: > > > Digest Authentication requires that a server store its > passwords in such a > > way that they be available in clear text format. > > Actually though your implementation -could- store the password on disk as > plain text - most do not; and it is technically not required. Some bad > implementations do store it plain - but (for example) the apache web > server stores the password as a hash (md5 or crypt) on the server side. > > See http://cvs.apache.org -> apache-1.3 -> src/support/htpasswd.c and > src/support/htdigest.c to get an idea of the code). > > So it is not a requirement - just an implementation choise. > > It is true that with normal basic auth the password goes over the wire in > the clear; but with digest auth this is not the case. > > Dw From w3c-dist-auth-request@w3.org Tue Oct 16 16:44:59 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20385 for ; Tue, 16 Oct 2001 16:44:59 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA26797; Tue, 16 Oct 2001 16:34:58 -0400 (EDT) Resent-Date: Tue, 16 Oct 2001 16:34:58 -0400 (EDT) Resent-Message-Id: <200110162034.QAA26797@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id QAA26777 for ; Tue, 16 Oct 2001 16:34:54 -0400 (EDT) Received: from cats.ucsc.edu (rumpleteazer.ucsc.edu [128.114.129.45]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id QAA07384 for ; Tue, 16 Oct 2001 16:34:54 -0400 Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177]) by cats.ucsc.edu (8.9.3/8.8.4.cats-athena) with SMTP id NAA05686 for ; Tue, 16 Oct 2001 13:34:58 -0700 (PDT) From: "Jim Whitehead" To: "WebDAV" Date: Tue, 16 Oct 2001 13:31:06 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Subject: Re: Digest Authentication Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5430 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Accidentally caught by the spam filter. I have added joe@manyfish.co.uk to the accept2 list, so future email from this address will go straight through. - Jim -----Original Message----- From: Joe Orton [mailto:joe@manyfish.co.uk] Sent: Tuesday, October 16, 2001 12:10 PM To: WebDAV Subject: [Moderator Action] Re: Digest Authentication On Tue, Oct 16, 2001 at 02:36:56PM -0400, Dylan Barrell wrote: > We did think of this solution, but that means that we always have to use the > same nonce value and we end up getting no security improvement over basic > authentication - so the argument that it is more secure than basic is bogus > if you do this. Mmm; I think you are misunderstanding something? RFC2617 section 3.3: Note that the HTTP server does not actually need to know the user's cleartext password. As long as H(A1) is available to the server, the validity of an Authorization header may be verified. Where H(A1) is just the MD5 of (user + ":" + realm + ":" + password)... joe From w3c-dist-auth-request@w3.org Tue Oct 16 16:50:34 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20539 for ; Tue, 16 Oct 2001 16:50:34 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA26932; Tue, 16 Oct 2001 16:39:39 -0400 (EDT) Resent-Date: Tue, 16 Oct 2001 16:39:39 -0400 (EDT) Resent-Message-Id: <200110162039.QAA26932@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id QAA26912 for ; Tue, 16 Oct 2001 16:39:30 -0400 (EDT) Received: from front2.mail.megapathdsl.net (front2.mail.megapathdsl.net [66.80.60.30]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id QAA07872 for ; Tue, 16 Oct 2001 16:39:29 -0400 Received: from [64.139.0.223] (HELO beaver) by front2.mail.megapathdsl.net (CommuniGate Pro SMTP 3.4.8a) with SMTP id 9162779; Tue, 16 Oct 2001 13:29:24 -0700 From: "Lisa Dusseault" To: "Dylan Barrell" Cc: "WebDAV" Date: Tue, 16 Oct 2001 13:38:18 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-reply-to: Subject: RE: Digest Authentication Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5431 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Dylan, I'm not sure I understand your nonce issue. You do not need to store the password on disk in the clear. In order to compute (or verify) the the client's authenticator you need to have the value H(A1). For the MD5 authentication scheme A1 is: A1 = unq(username-value) ":" unq(realm-value) ":" passwd (see RFC 2617 S 3.2.2.2). This is a fixed value for any user so it can be stored on disk directly. There's no need to use a fixed nonce in order to use a fixed H(A1) since the nonce is not an input to A1. Perhaps what you're referring to here is that compromise of H(A1) on a given server allows the attacker to impersonate the user to that server. However, this is not the same as compromise of the password since it does not permit the attacker to impersonate the user to any other server, even if the user has used the same password on that user. Admittedly, this problem does not exist with basic auth. However, most people consider sniffing a more serious threat than password file theft, which is why DAV so strongly "encourages" digest. What threat model are you concerned with here? Would you be implementing BASIC if you don't implement DIGEST, or is neither good enough? What would be good enough? Lisa > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Dylan Barrell > Sent: Tuesday, October 16, 2001 11:37 AM > To: Dirk-Willem van Gulik > Cc: WebDAV > Subject: RE: Digest Authentication > > > We did think of this solution, but that means that we always have > to use the > same nonce value and we end up getting no security improvement over basic > authentication - so the argument that it is more secure than > basic is bogus > if you do this. > > --Dylan > > > -----Original Message----- > > From: Dirk-Willem van Gulik [mailto:dirkx@webweaving.org] > > Sent: Tuesday, October 16, 2001 2:02 PM > > To: Dylan Barrell > > Cc: WebDAV > > Subject: Re: Digest Authentication > > > > > > > > > > On Tue, 16 Oct 2001, Dylan Barrell wrote: > > > > > Digest Authentication requires that a server store its > > passwords in such a > > > way that they be available in clear text format. > > > > Actually though your implementation -could- store the password > on disk as > > plain text - most do not; and it is technically not required. Some bad > > implementations do store it plain - but (for example) the apache web > > server stores the password as a hash (md5 or crypt) on the server side. > > > > See http://cvs.apache.org -> apache-1.3 -> src/support/htpasswd.c and > > src/support/htdigest.c to get an idea of the code). > > > > So it is not a requirement - just an implementation choise. > > > > It is true that with normal basic auth the password goes over > the wire in > > the clear; but with digest auth this is not the case. > > > > Dw From w3c-dist-auth-request@w3.org Tue Oct 16 17:54:37 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21572 for ; Tue, 16 Oct 2001 17:54:37 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA01548; Tue, 16 Oct 2001 17:46:06 -0400 (EDT) Resent-Date: Tue, 16 Oct 2001 17:46:06 -0400 (EDT) Resent-Message-Id: <200110162146.RAA01548@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id RAA01512 for ; Tue, 16 Oct 2001 17:45:51 -0400 (EDT) Received: from opentext.com (drawbridge.opentext.com [204.138.115.3]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id RAA15269 for ; Tue, 16 Oct 2001 17:45:39 -0400 Received: (from root@localhost) by opentext.com (8.9.3/8.9.3) id RAA25101; Tue, 16 Oct 2001 17:44:56 -0400 Received: from 022.dhcp2.liv.opentext.com(172.17.2.22) by krusty.wl.opentext.com via smap (V2.1) id xma025085; Tue, 16 Oct 01 17:44:52 -0400 From: "Dylan Barrell" To: "Lisa Dusseault" Cc: "WebDAV" Date: Tue, 16 Oct 2001 17:44:00 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: Subject: RE: Digest Authentication Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5432 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Lisa, But the passwd is a portion of A1. So how is storing this different from storing the password? I am saying that neither basic nor digest is good enough - and so there is no added benefit of implementing digest when the real solution is transport layer security or some other authentication mechanism like kerberos. --Dylan > -----Original Message----- > From: Lisa Dusseault [mailto:lisa@xythos.com] > Sent: Tuesday, October 16, 2001 4:38 PM > To: Dylan Barrell > Cc: WebDAV > Subject: RE: Digest Authentication > > > Dylan, > > I'm not sure I understand your nonce issue. You do not need to store > the password on disk in the clear. In order to compute (or verify) the > the client's authenticator you need to have the value H(A1). For the > MD5 authentication scheme A1 is: > > A1 = unq(username-value) ":" unq(realm-value) ":" passwd > > (see RFC 2617 S 3.2.2.2). > > This is a fixed value for any user so it can be stored on disk > directly. > > There's no need to use a fixed nonce in order to use a fixed H(A1) > since the nonce is not an input to A1. > > Perhaps what you're referring to here is that compromise of H(A1) > on a given server allows the attacker to impersonate the user to > that server. However, this is not the same as compromise of the > password since it does not permit the attacker to impersonate the > user to any other server, even if the user has used the same password > on that user. > > Admittedly, this problem does not exist with basic auth. However, > most people consider sniffing a more serious threat than password > file theft, which is why DAV so strongly "encourages" digest. > > What threat model are you concerned with here? Would you be > implementing BASIC if you don't implement DIGEST, or is neither > good enough? What would be good enough? > > Lisa > > > -----Original Message----- > > From: w3c-dist-auth-request@w3.org > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Dylan Barrell > > Sent: Tuesday, October 16, 2001 11:37 AM > > To: Dirk-Willem van Gulik > > Cc: WebDAV > > Subject: RE: Digest Authentication > > > > > > We did think of this solution, but that means that we always have > > to use the > > same nonce value and we end up getting no security improvement > over basic > > authentication - so the argument that it is more secure than > > basic is bogus > > if you do this. > > > > --Dylan > > > > > -----Original Message----- > > > From: Dirk-Willem van Gulik [mailto:dirkx@webweaving.org] > > > Sent: Tuesday, October 16, 2001 2:02 PM > > > To: Dylan Barrell > > > Cc: WebDAV > > > Subject: Re: Digest Authentication > > > > > > > > > > > > > > > On Tue, 16 Oct 2001, Dylan Barrell wrote: > > > > > > > Digest Authentication requires that a server store its > > > passwords in such a > > > > way that they be available in clear text format. > > > > > > Actually though your implementation -could- store the password > > on disk as > > > plain text - most do not; and it is technically not required. Some bad > > > implementations do store it plain - but (for example) the apache web > > > server stores the password as a hash (md5 or crypt) on the > server side. > > > > > > See http://cvs.apache.org -> apache-1.3 -> src/support/htpasswd.c and > > > src/support/htdigest.c to get an idea of the code). > > > > > > So it is not a requirement - just an implementation choise. > > > > > > It is true that with normal basic auth the password goes over > > the wire in > > > the clear; but with digest auth this is not the case. > > > > > > Dw From w3c-dist-auth-request@w3.org Tue Oct 16 19:13:12 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22749 for ; Tue, 16 Oct 2001 19:13:11 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id TAA06175; Tue, 16 Oct 2001 19:10:03 -0400 (EDT) Resent-Date: Tue, 16 Oct 2001 19:10:03 -0400 (EDT) Resent-Message-Id: <200110162310.TAA06175@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id TAA06153 for ; Tue, 16 Oct 2001 19:09:59 -0400 (EDT) Received: from front2.mail.megapathdsl.net (front2.mail.megapathdsl.net [66.80.60.30]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id TAA23569 for ; Tue, 16 Oct 2001 19:09:59 -0400 Received: from [64.139.0.223] (HELO beaver) by front2.mail.megapathdsl.net (CommuniGate Pro SMTP 3.4.8a) with SMTP id 9186551; Tue, 16 Oct 2001 15:59:53 -0700 From: "Lisa Dusseault" To: "Dylan Barrell" Cc: "WebDAV" Date: Tue, 16 Oct 2001 16:08:47 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-reply-to: Subject: RE: Digest Authentication Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5433 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit I agree that storing A1 is little better than storing the password. I just disagree with your nonce issue and conclusion. If you plan to support transport layer security, how do you intend to get the password from the client? Using Basic auth within a TLS-secured communication can be very secure indeed. lisa > -----Original Message----- > From: Dylan Barrell [mailto:dbarrell@opentext.com] > Sent: Tuesday, October 16, 2001 2:44 PM > To: Lisa Dusseault > Cc: WebDAV > Subject: RE: Digest Authentication > > > Lisa, > > But the passwd is a portion of A1. So how is storing this different from > storing the password? > > I am saying that neither basic nor digest is good enough - and so there is > no added benefit of implementing digest when the real solution is > transport > layer security or some other authentication mechanism like kerberos. > > --Dylan > > > -----Original Message----- > > From: Lisa Dusseault [mailto:lisa@xythos.com] > > Sent: Tuesday, October 16, 2001 4:38 PM > > To: Dylan Barrell > > Cc: WebDAV > > Subject: RE: Digest Authentication > > > > > > Dylan, > > > > I'm not sure I understand your nonce issue. You do not need to store > > the password on disk in the clear. In order to compute (or verify) the > > the client's authenticator you need to have the value H(A1). For the > > MD5 authentication scheme A1 is: > > > > A1 = unq(username-value) ":" unq(realm-value) ":" passwd > > > > (see RFC 2617 S 3.2.2.2). > > > > This is a fixed value for any user so it can be stored on disk > > directly. > > > > There's no need to use a fixed nonce in order to use a fixed H(A1) > > since the nonce is not an input to A1. > > > > Perhaps what you're referring to here is that compromise of H(A1) > > on a given server allows the attacker to impersonate the user to > > that server. However, this is not the same as compromise of the > > password since it does not permit the attacker to impersonate the > > user to any other server, even if the user has used the same password > > on that user. > > > > Admittedly, this problem does not exist with basic auth. However, > > most people consider sniffing a more serious threat than password > > file theft, which is why DAV so strongly "encourages" digest. > > > > What threat model are you concerned with here? Would you be > > implementing BASIC if you don't implement DIGEST, or is neither > > good enough? What would be good enough? > > > > Lisa > > > > > -----Original Message----- > > > From: w3c-dist-auth-request@w3.org > > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Dylan Barrell > > > Sent: Tuesday, October 16, 2001 11:37 AM > > > To: Dirk-Willem van Gulik > > > Cc: WebDAV > > > Subject: RE: Digest Authentication > > > > > > > > > We did think of this solution, but that means that we always have > > > to use the > > > same nonce value and we end up getting no security improvement > > over basic > > > authentication - so the argument that it is more secure than > > > basic is bogus > > > if you do this. > > > > > > --Dylan > > > > > > > -----Original Message----- > > > > From: Dirk-Willem van Gulik [mailto:dirkx@webweaving.org] > > > > Sent: Tuesday, October 16, 2001 2:02 PM > > > > To: Dylan Barrell > > > > Cc: WebDAV > > > > Subject: Re: Digest Authentication > > > > > > > > > > > > > > > > > > > > On Tue, 16 Oct 2001, Dylan Barrell wrote: > > > > > > > > > Digest Authentication requires that a server store its > > > > passwords in such a > > > > > way that they be available in clear text format. > > > > > > > > Actually though your implementation -could- store the password > > > on disk as > > > > plain text - most do not; and it is technically not > required. Some bad > > > > implementations do store it plain - but (for example) the apache web > > > > server stores the password as a hash (md5 or crypt) on the > > server side. > > > > > > > > See http://cvs.apache.org -> apache-1.3 -> > src/support/htpasswd.c and > > > > src/support/htdigest.c to get an idea of the code). > > > > > > > > So it is not a requirement - just an implementation choise. > > > > > > > > It is true that with normal basic auth the password goes over > > > the wire in > > > > the clear; but with digest auth this is not the case. > > > > > > > > Dw From w3c-dist-auth-request@w3.org Tue Oct 16 19:18:14 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22782 for ; Tue, 16 Oct 2001 19:18:14 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id TAA06647; Tue, 16 Oct 2001 19:16:03 -0400 (EDT) Resent-Date: Tue, 16 Oct 2001 19:16:03 -0400 (EDT) Resent-Message-Id: <200110162316.TAA06647@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id TAA06608 for ; Tue, 16 Oct 2001 19:15:53 -0400 (EDT) Received: from df-inet1.exchange.microsoft.com (df-inet1.exchange.microsoft.com [131.107.8.8]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id TAA24066 for ; Tue, 16 Oct 2001 19:15:53 -0400 Received: from df-virus2.platinum.corp.microsoft.com ([10.197.0.73]) by df-inet1.exchange.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 16 Oct 2001 16:16:24 -0700 Received: from 10.197.0.47 by df-virus2.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 16 Oct 2001 16:15:57 -0700 (Pacific Daylight Time) Received: from DF-MAX.platinum.corp.microsoft.com ([10.197.1.17]) by yuri.platinum.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 16 Oct 2001 16:16:01 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5752.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 16 Oct 2001 16:15:47 -0700 Message-ID: <4731EDAF5DD42946B4F12AFFBEEE31575EF540@DF-MAX.platinum.corp.microsoft.com> Thread-Topic: Digest Authentication Thread-Index: AcFWl8vSKkT/TmeaTo+Yaww6nkizuwAAEUNQ From: "Rajesh Rao" To: "Lisa Dusseault" , "Dylan Barrell" Cc: "WebDAV" X-OriginalArrivalTime: 16 Oct 2001 23:16:01.0828 (UTC) FILETIME=[85866640:01C15698] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www19.w3.org id TAA06608 Subject: RE: Digest Authentication Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5434 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 8bit Actually, we can store H(A1), rather than A1. This is better than storing a password as pointed previously in this mail thread as follows: > Perhaps what you're referring to here is that compromise > of H(A1) on > > > a given server allows the attacker to impersonate the > user to that > > > server. However, this is not the same as compromise of > the password > > > since it does not permit the attacker to impersonate the > user to any > > > other server, even if the user has used the same password on that > > > user. An no, we don't need to reuse the same nonce. Rajesh > -----Original Message----- > From: Lisa Dusseault [mailto:lisa@xythos.com] > Sent: Tuesday, October 16, 2001 4:09 PM > To: Dylan Barrell > Cc: WebDAV > Subject: RE: Digest Authentication > > > I agree that storing A1 is little better than storing the > password. I just disagree with your nonce issue and conclusion. > > If you plan to support transport layer security, how do you > intend to get the password from the client? Using Basic auth > within a TLS-secured communication can be very secure indeed. > > lisa > > > -----Original Message----- > > From: Dylan Barrell [mailto:dbarrell@opentext.com] > > Sent: Tuesday, October 16, 2001 2:44 PM > > To: Lisa Dusseault > > Cc: WebDAV > > Subject: RE: Digest Authentication > > > > > > Lisa, > > > > But the passwd is a portion of A1. So how is storing this different > > from storing the password? > > > > I am saying that neither basic nor digest is good enough - and so > > there is no added benefit of implementing digest when the real > > solution is transport layer security or some other authentication > > mechanism like kerberos. > > > > --Dylan > > > > > -----Original Message----- > > > From: Lisa Dusseault [mailto:lisa@xythos.com] > > > Sent: Tuesday, October 16, 2001 4:38 PM > > > To: Dylan Barrell > > > Cc: WebDAV > > > Subject: RE: Digest Authentication > > > > > > > > > Dylan, > > > > > > I'm not sure I understand your nonce issue. You do not > need to store > > > the password on disk in the clear. In order to compute > (or verify) > > > the the client's authenticator you need to have the value > H(A1). For > > > the MD5 authentication scheme A1 is: > > > > > > A1 = unq(username-value) ":" unq(realm-value) ":" passwd > > > > > > (see RFC 2617 S 3.2.2.2). > > > > > > This is a fixed value for any user so it can be stored on disk > > > directly. > > > > > > There's no need to use a fixed nonce in order to use a > fixed H(A1) > > > since the nonce is not an input to A1. > > > > > > Perhaps what you're referring to here is that compromise > of H(A1) on > > > a given server allows the attacker to impersonate the > user to that > > > server. However, this is not the same as compromise of > the password > > > since it does not permit the attacker to impersonate the > user to any > > > other server, even if the user has used the same password on that > > > user. > > > > > > Admittedly, this problem does not exist with basic auth. However, > > > most people consider sniffing a more serious threat than password > > > file theft, which is why DAV so strongly "encourages" digest. > > > > > > What threat model are you concerned with here? Would you be > > > implementing BASIC if you don't implement DIGEST, or is > neither good > > > enough? What would be good enough? > > > > > > Lisa > > > > > > > -----Original Message----- > > > > From: w3c-dist-auth-request@w3.org > > > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Dylan Barrell > > > > Sent: Tuesday, October 16, 2001 11:37 AM > > > > To: Dirk-Willem van Gulik > > > > Cc: WebDAV > > > > Subject: RE: Digest Authentication > > > > > > > > > > > > We did think of this solution, but that means that we > always have > > > > to use the same nonce value and we end up getting no security > > > > improvement > > > over basic > > > > authentication - so the argument that it is more secure > than basic > > > > is bogus if you do this. > > > > > > > > --Dylan > > > > > > > > > -----Original Message----- > > > > > From: Dirk-Willem van Gulik [mailto:dirkx@webweaving.org] > > > > > Sent: Tuesday, October 16, 2001 2:02 PM > > > > > To: Dylan Barrell > > > > > Cc: WebDAV > > > > > Subject: Re: Digest Authentication > > > > > > > > > > > > > > > > > > > > > > > > > On Tue, 16 Oct 2001, Dylan Barrell wrote: > > > > > > > > > > > Digest Authentication requires that a server store its > > > > > passwords in such a > > > > > > way that they be available in clear text format. > > > > > > > > > > Actually though your implementation -could- store the password > > > > on disk as > > > > > plain text - most do not; and it is technically not > > required. Some bad > > > > > implementations do store it plain - but (for example) > the apache > > > > > web server stores the password as a hash (md5 or crypt) on the > > > server side. > > > > > > > > > > See http://cvs.apache.org -> apache-1.3 -> > > src/support/htpasswd.c and > > > > > src/support/htdigest.c to get an idea of the code). > > > > > > > > > > So it is not a requirement - just an implementation choise. > > > > > > > > > > It is true that with normal basic auth the password goes over > > > > the wire in > > > > > the clear; but with digest auth this is not the case. > > > > > > > > > > Dw > > From w3c-dist-auth-request@w3.org Tue Oct 16 20:09:57 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23098 for ; Tue, 16 Oct 2001 20:09:57 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id UAA08785; Tue, 16 Oct 2001 20:07:27 -0400 (EDT) Resent-Date: Tue, 16 Oct 2001 20:07:27 -0400 (EDT) Resent-Message-Id: <200110170007.UAA08785@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id UAA08765 for ; Tue, 16 Oct 2001 20:07:22 -0400 (EDT) Received: from io.mds.rmit.edu.au (io.mds.rmit.edu.au [131.170.70.10]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id UAA28733 for ; Tue, 16 Oct 2001 20:07:21 -0400 Received: by io.mds.rmit.edu.au (Postfix, from userid 301) id 8E70F49B6B; Wed, 17 Oct 2001 10:06:49 +1000 (EST) Date: Wed, 17 Oct 2001 10:06:49 +1000 From: Alan Kent To: WebDAV Message-ID: <20011017100649.A23619@io.mds.rmit.edu.au> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95i In-Reply-To: ; from Dylan Barrell on Tue, Oct 16, 2001 at 02:36:56PM -0400 Subject: Re: Digest Authentication Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5435 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Just thought I would add my 2 cents (oh, given Australian/US currency conversion that might only be 1 cent :-) and say that our product is unable to implement digest authentication for reasons similar to those put forward by others. Our product has to work in a range of different environments where there are existing authentication mechanisms out of our control. We cannot even guarantee that a user name and password will be available for authentication! (One site uses SSL certificates only). There is no way we can ask for plain text passwords. And there is usually no way we can access even an encrypted version of it because the supplied API does not permit it and its to hard for the customer to change their security infrastructure just for us. Bottom line is that I think that WebDAV does not need to specify a security scheme - it can just say to use normal HTTP security methods. It seems like an orthogonal issue to WebDAV to me. Alan From w3c-dist-auth-request@w3.org Tue Oct 16 20:54:04 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23380 for ; Tue, 16 Oct 2001 20:54:04 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id UAA10979; Tue, 16 Oct 2001 20:48:12 -0400 (EDT) Resent-Date: Tue, 16 Oct 2001 20:48:12 -0400 (EDT) Resent-Message-Id: <200110170048.UAA10979@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id UAA10959 for ; Tue, 16 Oct 2001 20:48:08 -0400 (EDT) Received: from cats.ucsc.edu (rumpleteazer.ucsc.edu [128.114.129.45]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id UAA32122 for ; Tue, 16 Oct 2001 20:48:08 -0400 Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177]) by cats.ucsc.edu (8.9.3/8.8.4.cats-athena) with SMTP id RAA24338 for ; Tue, 16 Oct 2001 17:48:14 -0700 (PDT) From: "Jim Whitehead" To: "WebDAV" Date: Tue, 16 Oct 2001 17:44:21 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <20011017100649.A23619@io.mds.rmit.edu.au> Importance: Normal Subject: RE: Digest Authentication Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5436 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Alan Kent writes: > Bottom line is that I think that WebDAV does not need to specify > a security scheme - it can just say to use normal HTTP security > methods. It seems like an orthogonal issue to WebDAV to me. The diversity of WebDAV deployment scenarios was one of the key drivers behind RFC 2518 *not* mandating the *use* of a particular authentication mechanism. RFC 2518 merely states that implementations MUST implement Digest, not that they must use it. But, I believe Dylan is saying that the requirement to implement Digest is causing his server to store passwords in the clear, and hence implementing Digest (even if it isn't used) is causing him problems. - Jim From w3c-dist-auth-request@w3.org Tue Oct 16 21:34:55 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24380 for ; Tue, 16 Oct 2001 21:34:55 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id VAA12378; Tue, 16 Oct 2001 21:33:17 -0400 (EDT) Resent-Date: Tue, 16 Oct 2001 21:33:17 -0400 (EDT) Resent-Message-Id: <200110170133.VAA12378@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id VAA12358 for ; Tue, 16 Oct 2001 21:33:10 -0400 (EDT) Received: from io.mds.rmit.edu.au (io.mds.rmit.edu.au [131.170.70.10]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id VAA03542 for ; Tue, 16 Oct 2001 21:33:09 -0400 Received: by io.mds.rmit.edu.au (Postfix, from userid 301) id 095FD49B6B; Wed, 17 Oct 2001 11:32:37 +1000 (EST) Date: Wed, 17 Oct 2001 11:32:37 +1000 From: Alan Kent To: Jim Whitehead Cc: WebDAV Message-ID: <20011017113237.C23619@io.mds.rmit.edu.au> References: <20011017100649.A23619@io.mds.rmit.edu.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95i In-Reply-To: ; from Jim Whitehead on Tue, Oct 16, 2001 at 05:44:21PM -0700 Subject: Re: Digest Authentication Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5437 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: On Tue, Oct 16, 2001 at 05:44:21PM -0700, Jim Whitehead wrote: > The diversity of WebDAV deployment scenarios was one of the key drivers > behind RFC 2518 *not* mandating the *use* of a particular authentication > mechanism. RFC 2518 merely states that implementations MUST implement > Digest, not that they must use it. Well, since its not possible for us to use Digest authentiction at customer sites, I guess our 'digest implementation' will just have to reject all attempts to connect :-) :-) :-) Sorry, could not resist! Alan From w3c-dist-auth-request@w3.org Tue Oct 16 22:51:09 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26534 for ; Tue, 16 Oct 2001 22:51:09 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id WAA14181; Tue, 16 Oct 2001 22:45:57 -0400 (EDT) Resent-Date: Tue, 16 Oct 2001 22:45:57 -0400 (EDT) Resent-Message-Id: <200110170245.WAA14181@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id WAA14153 for ; Tue, 16 Oct 2001 22:45:48 -0400 (EDT) Received: from kim.ispra.webweaving.org (IDENT:CHUCK@adsl-66-124-87-42.dsl.snfc21.pacbell.net [66.124.87.42]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id WAA09187 for ; Tue, 16 Oct 2001 22:45:47 -0400 Received: from kim.ispra.webweaving.org (kim.ispra.webweaving.org [10.10.0.2]) by kim.ispra.webweaving.org (8.8.8/8.8.5) with ESMTP id CAA09948; Wed, 17 Oct 2001 02:45:39 GMT X-Passed: MX on Ispra.WebWeaving.org Wed, 17 Oct 2001 02:45:39 GMT and masked X-No-Spam: Neither the receipients nor the senders email address(s) are to be used for Unsolicited (Commercial) Email without the explicit written consent of either party; as a per-message fee is incurred for inbound and outbound traffic to the originator. Posted-Date: Wed, 17 Oct 2001 02:45:39 GMT Date: Wed, 17 Oct 2001 04:45:38 +0200 (CEST) From: Dirk-Willem van Gulik X-Sender: dirkx@kim.ispra.webweaving.org To: Dylan Barrell cc: WebDAV In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: RE: Digest Authentication Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5438 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: On Tue, 16 Oct 2001, Dylan Barrell wrote: Please check RFC2617. This issue was noted during the design of the digest method and effectively addressed. Or in other words: As long as the hash over the username/real/password is known to the server - any nonce can be used. See http://httpd.apache.org/docs/mod/mod_auth_digest.html and it's source for what and how. Dw > We did think of this solution, but that means that we always have to use the > same nonce value and we end up getting no security improvement over basic > authentication - so the argument that it is more secure than basic is bogus > if you do this. > > --Dylan > > > -----Original Message----- > > From: Dirk-Willem van Gulik [mailto:dirkx@webweaving.org] > > Sent: Tuesday, October 16, 2001 2:02 PM > > To: Dylan Barrell > > Cc: WebDAV > > Subject: Re: Digest Authentication > > > > > > > > > > On Tue, 16 Oct 2001, Dylan Barrell wrote: > > > > > Digest Authentication requires that a server store its > > passwords in such a > > > way that they be available in clear text format. > > > > Actually though your implementation -could- store the password on disk as > > plain text - most do not; and it is technically not required. Some bad > > implementations do store it plain - but (for example) the apache web > > server stores the password as a hash (md5 or crypt) on the server side. > > > > See http://cvs.apache.org -> apache-1.3 -> src/support/htpasswd.c and > > src/support/htdigest.c to get an idea of the code). > > > > So it is not a requirement - just an implementation choise. > > > > It is true that with normal basic auth the password goes over the wire in > > the clear; but with digest auth this is not the case. > > > > Dw > From w3c-dist-auth-request@w3.org Tue Oct 16 22:53:03 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26576 for ; Tue, 16 Oct 2001 22:53:03 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id WAA14307; Tue, 16 Oct 2001 22:50:33 -0400 (EDT) Resent-Date: Tue, 16 Oct 2001 22:50:33 -0400 (EDT) Resent-Message-Id: <200110170250.WAA14307@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id WAA14287 for ; Tue, 16 Oct 2001 22:50:28 -0400 (EDT) Received: from kim.ispra.webweaving.org (IDENT:CHUCK@adsl-66-124-87-42.dsl.snfc21.pacbell.net [66.124.87.42]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id WAA09651 for ; Tue, 16 Oct 2001 22:50:27 -0400 Received: from kim.ispra.webweaving.org (kim.ispra.webweaving.org [10.10.0.2]) by kim.ispra.webweaving.org (8.8.8/8.8.5) with ESMTP id CAA09969; Wed, 17 Oct 2001 02:50:11 GMT X-Passed: MX on Ispra.WebWeaving.org Wed, 17 Oct 2001 02:50:11 GMT and masked X-No-Spam: Neither the receipients nor the senders email address(s) are to be used for Unsolicited (Commercial) Email without the explicit written consent of either party; as a per-message fee is incurred for inbound and outbound traffic to the originator. Posted-Date: Wed, 17 Oct 2001 02:50:11 GMT Date: Wed, 17 Oct 2001 04:50:11 +0200 (CEST) From: Dirk-Willem van Gulik X-Sender: dirkx@kim.ispra.webweaving.org To: Lisa Dusseault cc: Dylan Barrell , WebDAV In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: RE: Digest Authentication Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5439 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Actually beasts like apache do not store A1 but a Hash(A1) which is not as bad as storing A1. Some other web servers do store A1. It is an implementation choise. Dw On Tue, 16 Oct 2001, Lisa Dusseault wrote: > I agree that storing A1 is little better than storing the password. I just > disagree with your nonce issue and conclusion. > > If you plan to support transport layer security, how do you intend to get > the password from the client? Using Basic auth within a TLS-secured > communication can be very secure indeed. > > lisa > > > -----Original Message----- > > From: Dylan Barrell [mailto:dbarrell@opentext.com] > > Sent: Tuesday, October 16, 2001 2:44 PM > > To: Lisa Dusseault > > Cc: WebDAV > > Subject: RE: Digest Authentication > > > > > > Lisa, > > > > But the passwd is a portion of A1. So how is storing this different from > > storing the password? > > > > I am saying that neither basic nor digest is good enough - and so there is > > no added benefit of implementing digest when the real solution is > > transport > > layer security or some other authentication mechanism like kerberos. > > > > --Dylan > > > > > -----Original Message----- > > > From: Lisa Dusseault [mailto:lisa@xythos.com] > > > Sent: Tuesday, October 16, 2001 4:38 PM > > > To: Dylan Barrell > > > Cc: WebDAV > > > Subject: RE: Digest Authentication > > > > > > > > > Dylan, > > > > > > I'm not sure I understand your nonce issue. You do not need to store > > > the password on disk in the clear. In order to compute (or verify) the > > > the client's authenticator you need to have the value H(A1). For the > > > MD5 authentication scheme A1 is: > > > > > > A1 = unq(username-value) ":" unq(realm-value) ":" passwd > > > > > > (see RFC 2617 S 3.2.2.2). > > > > > > This is a fixed value for any user so it can be stored on disk > > > directly. > > > > > > There's no need to use a fixed nonce in order to use a fixed H(A1) > > > since the nonce is not an input to A1. > > > > > > Perhaps what you're referring to here is that compromise of H(A1) > > > on a given server allows the attacker to impersonate the user to > > > that server. However, this is not the same as compromise of the > > > password since it does not permit the attacker to impersonate the > > > user to any other server, even if the user has used the same password > > > on that user. > > > > > > Admittedly, this problem does not exist with basic auth. However, > > > most people consider sniffing a more serious threat than password > > > file theft, which is why DAV so strongly "encourages" digest. > > > > > > What threat model are you concerned with here? Would you be > > > implementing BASIC if you don't implement DIGEST, or is neither > > > good enough? What would be good enough? > > > > > > Lisa > > > > > > > -----Original Message----- > > > > From: w3c-dist-auth-request@w3.org > > > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Dylan Barrell > > > > Sent: Tuesday, October 16, 2001 11:37 AM > > > > To: Dirk-Willem van Gulik > > > > Cc: WebDAV > > > > Subject: RE: Digest Authentication > > > > > > > > > > > > We did think of this solution, but that means that we always have > > > > to use the > > > > same nonce value and we end up getting no security improvement > > > over basic > > > > authentication - so the argument that it is more secure than > > > > basic is bogus > > > > if you do this. > > > > > > > > --Dylan > > > > > > > > > -----Original Message----- > > > > > From: Dirk-Willem van Gulik [mailto:dirkx@webweaving.org] > > > > > Sent: Tuesday, October 16, 2001 2:02 PM > > > > > To: Dylan Barrell > > > > > Cc: WebDAV > > > > > Subject: Re: Digest Authentication > > > > > > > > > > > > > > > > > > > > > > > > > On Tue, 16 Oct 2001, Dylan Barrell wrote: > > > > > > > > > > > Digest Authentication requires that a server store its > > > > > passwords in such a > > > > > > way that they be available in clear text format. > > > > > > > > > > Actually though your implementation -could- store the password > > > > on disk as > > > > > plain text - most do not; and it is technically not > > required. Some bad > > > > > implementations do store it plain - but (for example) the apache web > > > > > server stores the password as a hash (md5 or crypt) on the > > > server side. > > > > > > > > > > See http://cvs.apache.org -> apache-1.3 -> > > src/support/htpasswd.c and > > > > > src/support/htdigest.c to get an idea of the code). > > > > > > > > > > So it is not a requirement - just an implementation choise. > > > > > > > > > > It is true that with normal basic auth the password goes over > > > > the wire in > > > > > the clear; but with digest auth this is not the case. > > > > > > > > > > Dw > From w3c-dist-auth-request@w3.org Wed Oct 17 02:18:31 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12094 for ; Wed, 17 Oct 2001 02:18:31 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id CAA20524; Wed, 17 Oct 2001 02:16:12 -0400 (EDT) Resent-Date: Wed, 17 Oct 2001 02:16:12 -0400 (EDT) Resent-Message-Id: <200110170616.CAA20524@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id CAA20504 for ; Wed, 17 Oct 2001 02:16:06 -0400 (EDT) Received: from life.ai.mit.edu (life.ai.mit.edu [128.52.32.80]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id CAA26748 for ; Wed, 17 Oct 2001 02:16:07 -0400 Received: from Phillspc (h00a0cc5364a4.ne.mediaone.net [66.31.37.144]) by life.ai.mit.edu (8.9.3/8.9.3/AI2.13/ai.master.life:2.21) with SMTP id CAA24702; Wed, 17 Oct 2001 02:15:59 -0400 (EDT) From: "Phillip Hallam-Baker" To: "'Lisa Dusseault'" , "'Dylan Barrell'" Cc: "'WebDAV'" Date: Wed, 17 Oct 2001 02:13:04 -0400 Message-ID: <00da01c156d2$c8889640$4100a8c0@ne.mediaone.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: Importance: Normal Subject: RE: Digest Authentication Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5440 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Sigh, this debate has been going on for eight years. There are two potential points of vulnerability for a password, in storage and in transit. If you have a system that protects the password in storage and in transit then it can be used as a public key system, therefore any system based on a symetric key alone cannot provide protection in both cases. The reason I first proposed Digest Authentication is that the vulnerabilty of a password in transit is considerably greater than the vulnerability in storage for practically any conceivable network application. The original Moris analysis of the one way encryption scheme in UNIX considered only the vulnerability of stored passwords because networking was not common at the time. The original Moris analysis is in any case hopelessly flawed, in the original paper the proposal is made that read protecting the password file in addition to encryption is a bad idea and should be dimissed as 'security through obscurity'. It took several generations of password crackers before the UNIX sysadmin world silently abandoned that particular piece of nonsense and started using shaddow password files. At the time the proposal was made public key encryption was encumbered by the Diffie-Hellman and RSA patents, hence there was a need for a symetric key scheme designed to protect the key in transit. The second issue the digest authentication design attempts to address is limiting the risks involved in sharing passwords between sites. The Basic authentication scheme, even over SSL is vulnerable to practically every scenario in which the Digest scheme is vulnerable in addition to many in which the Digest scheme is secure. If the attacker is presumed to have read access to a critical systen file such as the password file it is unreasonable to assume that the attacker cannot gain write access to the web server executable, or for that matter gain access to whatever security sensitive resource that was meant to be protected. Today a much better approach than Digest Authentication would be to use a federated authentication system such as SAML being standardized in the OASIS standards group. Phill > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault > Sent: Tuesday, October 16, 2001 7:09 PM > To: Dylan Barrell > Cc: WebDAV > Subject: RE: Digest Authentication > > > I agree that storing A1 is little better than storing the > password. I just > disagree with your nonce issue and conclusion. > > If you plan to support transport layer security, how do you > intend to get > the password from the client? Using Basic auth within a TLS-secured > communication can be very secure indeed. > > lisa > > > -----Original Message----- > > From: Dylan Barrell [mailto:dbarrell@opentext.com] > > Sent: Tuesday, October 16, 2001 2:44 PM > > To: Lisa Dusseault > > Cc: WebDAV > > Subject: RE: Digest Authentication > > > > > > Lisa, > > > > But the passwd is a portion of A1. So how is storing this > different from > > storing the password? > > > > I am saying that neither basic nor digest is good enough - > and so there is > > no added benefit of implementing digest when the real solution is > > transport > > layer security or some other authentication mechanism like kerberos. > > > > --Dylan > > > > > -----Original Message----- > > > From: Lisa Dusseault [mailto:lisa@xythos.com] > > > Sent: Tuesday, October 16, 2001 4:38 PM > > > To: Dylan Barrell > > > Cc: WebDAV > > > Subject: RE: Digest Authentication > > > > > > > > > Dylan, > > > > > > I'm not sure I understand your nonce issue. You do not > need to store > > > the password on disk in the clear. In order to compute > (or verify) the > > > the client's authenticator you need to have the value > H(A1). For the > > > MD5 authentication scheme A1 is: > > > > > > A1 = unq(username-value) ":" unq(realm-value) ":" passwd > > > > > > (see RFC 2617 S 3.2.2.2). > > > > > > This is a fixed value for any user so it can be stored on disk > > > directly. > > > > > > There's no need to use a fixed nonce in order to use a fixed H(A1) > > > since the nonce is not an input to A1. > > > > > > Perhaps what you're referring to here is that compromise of H(A1) > > > on a given server allows the attacker to impersonate the user to > > > that server. However, this is not the same as compromise of the > > > password since it does not permit the attacker to impersonate the > > > user to any other server, even if the user has used the > same password > > > on that user. > > > > > > Admittedly, this problem does not exist with basic auth. However, > > > most people consider sniffing a more serious threat than password > > > file theft, which is why DAV so strongly "encourages" digest. > > > > > > What threat model are you concerned with here? Would you be > > > implementing BASIC if you don't implement DIGEST, or is neither > > > good enough? What would be good enough? > > > > > > Lisa > > > > > > > -----Original Message----- > > > > From: w3c-dist-auth-request@w3.org > > > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Dylan Barrell > > > > Sent: Tuesday, October 16, 2001 11:37 AM > > > > To: Dirk-Willem van Gulik > > > > Cc: WebDAV > > > > Subject: RE: Digest Authentication > > > > > > > > > > > > We did think of this solution, but that means that we > always have > > > > to use the > > > > same nonce value and we end up getting no security improvement > > > over basic > > > > authentication - so the argument that it is more secure than > > > > basic is bogus > > > > if you do this. > > > > > > > > --Dylan > > > > > > > > > -----Original Message----- > > > > > From: Dirk-Willem van Gulik [mailto:dirkx@webweaving.org] > > > > > Sent: Tuesday, October 16, 2001 2:02 PM > > > > > To: Dylan Barrell > > > > > Cc: WebDAV > > > > > Subject: Re: Digest Authentication > > > > > > > > > > > > > > > > > > > > > > > > > On Tue, 16 Oct 2001, Dylan Barrell wrote: > > > > > > > > > > > Digest Authentication requires that a server store its > > > > > passwords in such a > > > > > > way that they be available in clear text format. > > > > > > > > > > Actually though your implementation -could- store the password > > > > on disk as > > > > > plain text - most do not; and it is technically not > > required. Some bad > > > > > implementations do store it plain - but (for example) > the apache web > > > > > server stores the password as a hash (md5 or crypt) on the > > > server side. > > > > > > > > > > See http://cvs.apache.org -> apache-1.3 -> > > src/support/htpasswd.c and > > > > > src/support/htdigest.c to get an idea of the code). > > > > > > > > > > So it is not a requirement - just an implementation choise. > > > > > > > > > > It is true that with normal basic auth the password goes over > > > > the wire in > > > > > the clear; but with digest auth this is not the case. > > > > > > > > > > Dw > > From w3c-dist-auth-request@w3.org Wed Oct 17 09:26:08 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23594 for ; Wed, 17 Oct 2001 09:26:07 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id JAA09851; Wed, 17 Oct 2001 09:23:17 -0400 (EDT) Resent-Date: Wed, 17 Oct 2001 09:23:17 -0400 (EDT) Resent-Message-Id: <200110171323.JAA09851@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id JAA09831 for ; Wed, 17 Oct 2001 09:23:11 -0400 (EDT) Received: from opentext.com (drawbridge.opentext.com [204.138.115.3]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id JAA13895 for ; Wed, 17 Oct 2001 09:23:12 -0400 Received: (from root@localhost) by opentext.com (8.9.3/8.9.3) id JAA30666; Wed, 17 Oct 2001 09:22:41 -0400 Received: from 022.dhcp2.liv.opentext.com(172.17.2.22) by krusty.wl.opentext.com via smap (V2.1) id xmab30591; Wed, 17 Oct 01 09:22:34 -0400 From: "Dylan Barrell" To: "Phillip Hallam-Baker" , "'Lisa Dusseault'" Cc: "'WebDAV'" Date: Wed, 17 Oct 2001 09:22:04 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: <00da01c156d2$c8889640$4100a8c0@ne.mediaone.net> Subject: RE: Digest Authentication Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5441 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit I have no problem with Digest Authentication, simply its status in RFC2518. --Dylan > -----Original Message----- > From: Phillip Hallam-Baker [mailto:hallam@ai.mit.edu] > Sent: Wednesday, October 17, 2001 2:13 AM > To: 'Lisa Dusseault'; 'Dylan Barrell' > Cc: 'WebDAV' > Subject: RE: Digest Authentication > > > Sigh, this debate has been going on for eight years. > > There are two potential points of vulnerability for a password, in storage > and in transit. > > If you have a system that protects the password in storage and in transit > then it can be used as a public key system, therefore any system > based on a > symetric key alone cannot provide protection in both cases. > > The reason I first proposed Digest Authentication is that the vulnerabilty > of a password in transit is considerably greater than the vulnerability in > storage for practically any conceivable network application. The original > Moris analysis of the one way encryption scheme in UNIX > considered only the > vulnerability of stored passwords because networking was not common at the > time. > > The original Moris analysis is in any case hopelessly flawed, in the > original paper the proposal is made that read protecting the password file > in addition to encryption is a bad idea and should be dimissed as > 'security > through obscurity'. It took several generations of password > crackers before > the UNIX sysadmin world silently abandoned that particular piece > of nonsense > and started using shaddow password files. > > At the time the proposal was made public key encryption was encumbered by > the Diffie-Hellman and RSA patents, hence there was a need for a symetric > key scheme designed to protect the key in transit. > > The second issue the digest authentication design attempts to address is > limiting the risks involved in sharing passwords between sites. > > The Basic authentication scheme, even over SSL is vulnerable to > practically > every scenario in which the Digest scheme is vulnerable in > addition to many > in which the Digest scheme is secure. If the attacker is presumed to have > read access to a critical systen file such as the password file it is > unreasonable to assume that the attacker cannot gain write access > to the web > server executable, or for that matter gain access to whatever security > sensitive resource that was meant to be protected. > > > Today a much better approach than Digest Authentication would be to use a > federated authentication system such as SAML being standardized > in the OASIS > standards group. > > > Phill > > > -----Original Message----- > > From: w3c-dist-auth-request@w3.org > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault > > Sent: Tuesday, October 16, 2001 7:09 PM > > To: Dylan Barrell > > Cc: WebDAV > > Subject: RE: Digest Authentication > > > > > > I agree that storing A1 is little better than storing the > > password. I just > > disagree with your nonce issue and conclusion. > > > > If you plan to support transport layer security, how do you > > intend to get > > the password from the client? Using Basic auth within a TLS-secured > > communication can be very secure indeed. > > > > lisa > > > > > -----Original Message----- > > > From: Dylan Barrell [mailto:dbarrell@opentext.com] > > > Sent: Tuesday, October 16, 2001 2:44 PM > > > To: Lisa Dusseault > > > Cc: WebDAV > > > Subject: RE: Digest Authentication > > > > > > > > > Lisa, > > > > > > But the passwd is a portion of A1. So how is storing this > > different from > > > storing the password? > > > > > > I am saying that neither basic nor digest is good enough - > > and so there is > > > no added benefit of implementing digest when the real solution is > > > transport > > > layer security or some other authentication mechanism like kerberos. > > > > > > --Dylan > > > > > > > -----Original Message----- > > > > From: Lisa Dusseault [mailto:lisa@xythos.com] > > > > Sent: Tuesday, October 16, 2001 4:38 PM > > > > To: Dylan Barrell > > > > Cc: WebDAV > > > > Subject: RE: Digest Authentication > > > > > > > > > > > > Dylan, > > > > > > > > I'm not sure I understand your nonce issue. You do not > > need to store > > > > the password on disk in the clear. In order to compute > > (or verify) the > > > > the client's authenticator you need to have the value > > H(A1). For the > > > > MD5 authentication scheme A1 is: > > > > > > > > A1 = unq(username-value) ":" unq(realm-value) ":" passwd > > > > > > > > (see RFC 2617 S 3.2.2.2). > > > > > > > > This is a fixed value for any user so it can be stored on disk > > > > directly. > > > > > > > > There's no need to use a fixed nonce in order to use a fixed H(A1) > > > > since the nonce is not an input to A1. > > > > > > > > Perhaps what you're referring to here is that compromise of H(A1) > > > > on a given server allows the attacker to impersonate the user to > > > > that server. However, this is not the same as compromise of the > > > > password since it does not permit the attacker to impersonate the > > > > user to any other server, even if the user has used the > > same password > > > > on that user. > > > > > > > > Admittedly, this problem does not exist with basic auth. However, > > > > most people consider sniffing a more serious threat than password > > > > file theft, which is why DAV so strongly "encourages" digest. > > > > > > > > What threat model are you concerned with here? Would you be > > > > implementing BASIC if you don't implement DIGEST, or is neither > > > > good enough? What would be good enough? > > > > > > > > Lisa > > > > > > > > > -----Original Message----- > > > > > From: w3c-dist-auth-request@w3.org > > > > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Dylan Barrell > > > > > Sent: Tuesday, October 16, 2001 11:37 AM > > > > > To: Dirk-Willem van Gulik > > > > > Cc: WebDAV > > > > > Subject: RE: Digest Authentication > > > > > > > > > > > > > > > We did think of this solution, but that means that we > > always have > > > > > to use the > > > > > same nonce value and we end up getting no security improvement > > > > over basic > > > > > authentication - so the argument that it is more secure than > > > > > basic is bogus > > > > > if you do this. > > > > > > > > > > --Dylan > > > > > > > > > > > -----Original Message----- > > > > > > From: Dirk-Willem van Gulik [mailto:dirkx@webweaving.org] > > > > > > Sent: Tuesday, October 16, 2001 2:02 PM > > > > > > To: Dylan Barrell > > > > > > Cc: WebDAV > > > > > > Subject: Re: Digest Authentication > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Tue, 16 Oct 2001, Dylan Barrell wrote: > > > > > > > > > > > > > Digest Authentication requires that a server store its > > > > > > passwords in such a > > > > > > > way that they be available in clear text format. > > > > > > > > > > > > Actually though your implementation -could- store the password > > > > > on disk as > > > > > > plain text - most do not; and it is technically not > > > required. Some bad > > > > > > implementations do store it plain - but (for example) > > the apache web > > > > > > server stores the password as a hash (md5 or crypt) on the > > > > server side. > > > > > > > > > > > > See http://cvs.apache.org -> apache-1.3 -> > > > src/support/htpasswd.c and > > > > > > src/support/htdigest.c to get an idea of the code). > > > > > > > > > > > > So it is not a requirement - just an implementation choise. > > > > > > > > > > > > It is true that with normal basic auth the password goes over > > > > > the wire in > > > > > > the clear; but with digest auth this is not the case. > > > > > > > > > > > > Dw > > > > From w3c-dist-auth-request@w3.org Wed Oct 17 09:26:11 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23605 for ; Wed, 17 Oct 2001 09:26:11 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id JAA09894; Wed, 17 Oct 2001 09:23:41 -0400 (EDT) Resent-Date: Wed, 17 Oct 2001 09:23:41 -0400 (EDT) Resent-Message-Id: <200110171323.JAA09894@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id JAA09871 for ; Wed, 17 Oct 2001 09:23:36 -0400 (EDT) Received: from opentext.com (drawbridge.opentext.com [204.138.115.3]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id JAA13922 for ; Wed, 17 Oct 2001 09:23:37 -0400 Received: (from root@localhost) by opentext.com (8.9.3/8.9.3) id JAA30610; Wed, 17 Oct 2001 09:22:34 -0400 Received: from 022.dhcp2.liv.opentext.com(172.17.2.22) by krusty.wl.opentext.com via smap (V2.1) id xma030591; Wed, 17 Oct 01 09:22:33 -0400 From: "Dylan Barrell" To: "WebDAV" , "Lisa Dusseault" Date: Wed, 17 Oct 2001 09:22:03 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: Subject: RE: Digest Authentication Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5442 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Ah, right. It does get a bit complicated: Yes, the concern is the storage of H(A1), because this is a plaintext-password equivalent. The only advantage to storing H(A1) over the plaintext password itself is that leaking the "password file" wouldn't compromise other systems on which the user uses the same password. Apart from that, it's the same as a plaintext-password, because you can use it to log in as the user in question. Livelink stores its "password file" in the database, and it does _not_ assume that anyone who can access the password info has the right to impersonate any user. The way Livelink stores this information ensures that you cannot impersonate a user with it. This is a feature of _many_ authentication mechanisms, including the old /etc/passwd. Right now, we can have a very secure Livelink install by using SSL with Basic authentication. If we must support Digest authentication, however, then it would seem that we need to store H(A1), and so we would be introducing a hole that does not exist Today -- bad. You see, the problem is not so much that the spec forbids us from offering Basic over insecure channels (though I would argue that it is overly presumptuous). The significant problem is that the spec _insists_ that we support Digest -- even if we only use secure connections. The only way I can see implementing Digest without introducing this new security hole is to use a constant server nonce and no qop, so that for any username/password/realm, the request-digest is constant. Then I can store salt+H(salt,request-digest) in the database. While this _would_ produce a compatible implementation, it would violate several directives in rfc2617, and would render the protocol vulnerable to sniffing again -- just like Basic. Hence my request to demote digest authentication to the same level as basic i.e. optional. From w3c-dist-auth-request@w3.org Fri Oct 19 21:59:42 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12361 for ; Fri, 19 Oct 2001 21:59:42 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id VAA22182; Fri, 19 Oct 2001 21:50:39 -0400 (EDT) Resent-Date: Fri, 19 Oct 2001 21:50:39 -0400 (EDT) Resent-Message-Id: <200110200150.VAA22182@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id VAA22155 for ; Fri, 19 Oct 2001 21:50:32 -0400 (EDT) Received: from life.ai.mit.edu (life.ai.mit.edu [128.52.32.80]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id VAA20480 for ; Fri, 19 Oct 2001 21:50:32 -0400 Received: from Phillspc (h08004607c62f.ne.mediaone.net [66.31.37.190]) by life.ai.mit.edu (8.9.3/8.9.3/AI2.13/ai.master.life:2.21) with SMTP id VAA06610; Fri, 19 Oct 2001 21:50:30 -0400 (EDT) From: "Phillip Hallam-Baker" To: "'Dylan Barrell'" , "'WebDAV'" , "'Lisa Dusseault'" Date: Fri, 19 Oct 2001 21:47:12 -0400 Message-ID: <00b801c15909$23ed0c40$4100a8c0@ne.mediaone.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: Importance: Normal Subject: RE: Digest Authentication Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5443 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit IETF security policy is the reason why Digest is mandatory. W3C policy is not going to accept sending passwords in the clear either. Phill > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Dylan Barrell > Sent: Wednesday, October 17, 2001 9:22 AM > To: WebDAV; Lisa Dusseault > Subject: RE: Digest Authentication > > > Ah, right. It does get a bit complicated: > > Yes, the concern is the storage of H(A1), because this is a > plaintext-password equivalent. The only advantage to storing > H(A1) over the > plaintext password itself is that leaking the "password file" wouldn't > compromise other systems on which the user uses the same > password. Apart > from that, it's the same as a plaintext-password, because you > can use it to > log in as the user in question. > > Livelink stores its "password file" in the database, and it does _not_ > assume that anyone who can access the password info has the right to > impersonate any user. The way Livelink stores this > information ensures that > you cannot impersonate a user with it. This is a feature of _many_ > authentication mechanisms, including the old /etc/passwd. > > Right now, we can have a very secure Livelink install by > using SSL with > Basic authentication. If we must support Digest > authentication, however, > then it would seem that we need to store H(A1), and so we would be > introducing a hole that does not exist Today -- bad. > > You see, the problem is not so much that the spec forbids us > from offering > Basic over insecure channels (though I would argue that it is overly > presumptuous). The significant problem is that the spec > _insists_ that we > support Digest -- even if we only use secure connections. > > The only way I can see implementing Digest without > introducing this new > security hole is to use a constant server nonce and no qop, > so that for any > username/password/realm, the request-digest is constant. > Then I can store > salt+H(salt,request-digest) in the database. While this > _would_ produce a > compatible implementation, it would violate several > directives in rfc2617, > and would render the protocol vulnerable to sniffing again -- > just like > Basic. > > Hence my request to demote digest authentication to the same > level as basic > i.e. optional. > > From w3c-dist-auth-request@w3.org Mon Oct 22 06:06:35 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09777 for ; Mon, 22 Oct 2001 06:06:34 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id GAA10123; Mon, 22 Oct 2001 06:03:47 -0400 (EDT) Resent-Date: Mon, 22 Oct 2001 06:03:47 -0400 (EDT) Resent-Message-Id: <200110221003.GAA10123@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id GAA10099 for ; Mon, 22 Oct 2001 06:03:39 -0400 (EDT) Received: from linux.wiplash.com ([203.122.0.159]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id GAA04904 for ; Mon, 22 Oct 2001 06:03:32 -0400 From: Krischrist@gmx.net Received: from ns2.gmx.net (server7.wiplash.com [192.168.0.37]) by linux.wiplash.com (8.9.3/8.8.7) with ESMTP id PAA10635 for ; Mon, 22 Oct 2001 15:38:58 -0400 Message-Id: <5.1.0.14.0.20011022154244.009e5c50@mail.gmx.net> X-Sender: krischrist@gmx.net@mail.gmx.net X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 22 Oct 2001 15:43:41 +0530 To: w3c-dist-auth@w3.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_8016880==_.ALT" Subject: How to patch with SQUID? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5444 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: --=====================_8016880==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hi, I am using Redhat 6.0. The squid version geing used is squid2.2.stable4-5.I have the webdav patch for it.Kindly tell me the procedure to patch with squid.Please help it's urgent!!!!! regards Krischrist Welcome to my Homepage!!!!! http://Krischrist.xaper.com http://Krischrist.tripod.com --=====================_8016880==_.ALT Content-Type: text/html; charset="us-ascii" Hi,
I am using Redhat 6.0. The squid version geing used is squid2.2.stable4-5.I have the webdav patch for it.Kindly tell me the procedure to patch with squid.Please help it's urgent!!!!!

regards
Krischrist


Welcome to my Homepage!!!!!
http://Krischrist.xaper.com
http://Krischrist.tripod.com
--=====================_8016880==_.ALT-- From w3c-dist-auth-request@w3.org Mon Oct 22 09:36:17 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16454 for ; Mon, 22 Oct 2001 09:36:17 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id JAA26806; Mon, 22 Oct 2001 09:30:12 -0400 (EDT) Resent-Date: Mon, 22 Oct 2001 09:30:12 -0400 (EDT) Resent-Message-Id: <200110221330.JAA26806@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id JAA26786 for ; Mon, 22 Oct 2001 09:30:08 -0400 (EDT) Received: from opentext.com (drawbridge.opentext.com [204.138.115.3]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id JAA06436 for ; Mon, 22 Oct 2001 09:30:08 -0400 Received: (from root@localhost) by opentext.com (8.9.3/8.9.3) id JAA32708; Mon, 22 Oct 2001 09:28:55 -0400 Received: from 022.dhcp2.liv.opentext.com(172.17.2.22) by krusty.wl.opentext.com via smap (V2.1) id xma032693; Mon, 22 Oct 01 09:28:52 -0400 From: "Dylan Barrell" To: "Phillip Hallam-Baker" , "'WebDAV'" , "'Lisa Dusseault'" Date: Mon, 22 Oct 2001 09:28:22 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <00b801c15909$23ed0c40$4100a8c0@ne.mediaone.net> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Subject: RE: Digest Authentication Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5445 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit So we have to stick to policy even when there are indisputable reasons why it doesn't make sense? This doesn't seem like a very sensible thing to do. --Dylan From w3c-dist-auth-request@w3.org Mon Oct 22 12:22:13 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21831 for ; Mon, 22 Oct 2001 12:22:12 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA12246; Mon, 22 Oct 2001 12:19:59 -0400 (EDT) Resent-Date: Mon, 22 Oct 2001 12:19:59 -0400 (EDT) Resent-Message-Id: <200110221619.MAA12246@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id MAA12224 for ; Mon, 22 Oct 2001 12:19:55 -0400 (EDT) Received: from cats.ucsc.edu (rumpleteazer.ucsc.edu [128.114.129.45]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id MAA30860 for ; Mon, 22 Oct 2001 12:19:56 -0400 Received: from Tycho (dhcp-55-194.cse.ucsc.edu [128.114.55.194]) by cats.ucsc.edu (8.9.3/8.8.4.cats-athena) with SMTP id JAA23241; Mon, 22 Oct 2001 09:20:55 -0700 (PDT) From: "Jim Whitehead" To: , Date: Mon, 22 Oct 2001 09:16:02 -0700 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0036_01C15ADA.2B82D750" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: <5.1.0.14.0.20011022154244.009e5c50@mail.gmx.net> Subject: RE: How to patch with SQUID? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5446 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0036_01C15ADA.2B82D750 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The WebDAV mailing list is probably not as good a source of information about Squid as one of the Squid mailing lists: http://www.squid-cache.org/mailing-lists.html You should also try your request on one of these lists, if you haven't already. - Jim -----Original Message----- From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Krischrist@gmx.net Sent: Monday, October 22, 2001 3:14 AM To: w3c-dist-auth@w3.org Subject: How to patch with SQUID? Hi, I am using Redhat 6.0. The squid version geing used is squid2.2.stable4-5.I have the webdav patch for it.Kindly tell me the procedure to patch with squid.Please help it's urgent!!!!! regards Krischrist Welcome to my Homepage!!!!! http://Krischrist.xaper.com http://Krischrist.tripod.com ------=_NextPart_000_0036_01C15ADA.2B82D750 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The=20 WebDAV mailing list is probably not as good a source of information = about Squid=20 as one of the Squid mailing lists:
 
http://www.squid-c= ache.org/mailing-lists.html
 
You=20 should also try your request on one of these lists, if you haven't=20 already.
 
-=20 Jim
-----Original Message-----
From: = w3c-dist-auth-request@w3.org=20 [mailto:w3c-dist-auth-request@w3.org]On Behalf Of=20 Krischrist@gmx.net
Sent: Monday, October 22, 2001 3:14=20 AM
To: w3c-dist-auth@w3.org
Subject: How to patch = with=20 SQUID?

Hi,
I am using Redhat 6.0. The squid = version=20 geing used is squid2.2.stable4-5.I have the webdav patch for it.Kindly = tell me=20 the procedure to patch with squid.Please help it's=20 urgent!!!!!

regards
Krischrist


Welcome to my=20 Homepage!!!!!
http://Krischrist.xaper.com
http://Krischrist.tripod.com

<= /BODY> ------=_NextPart_000_0036_01C15ADA.2B82D750-- From w3c-dist-auth-request@w3.org Mon Oct 22 18:32:01 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01042 for ; Mon, 22 Oct 2001 18:32:01 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAA04608; Mon, 22 Oct 2001 18:29:58 -0400 (EDT) Resent-Date: Mon, 22 Oct 2001 18:29:58 -0400 (EDT) Resent-Message-Id: <200110222229.SAA04608@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id SAA04588 for ; Mon, 22 Oct 2001 18:29:47 -0400 (EDT) Received: from opentext.com (drawbridge.opentext.com [204.138.115.3]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id SAA07314 for ; Mon, 22 Oct 2001 18:29:47 -0400 Received: from mt2k (212.dhcp.ott.opentext.com [192.168.130.212]) by opentext.com (8.9.3/8.9.3) with SMTP id SAA29439; Mon, 22 Oct 2001 18:28:45 -0400 Reply-To: From: "Matt Timmermans" To: "'Phillip Hallam-Baker'" , "'Dylan Barrell'" , "'WebDAV'" , "'Lisa Dusseault'" Date: Mon, 22 Oct 2001 18:28:40 -0400 Message-ID: <001501c15b48$e7c5fe10$d482a8c0@mt2k> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: <00b801c15909$23ed0c40$4100a8c0@ne.mediaone.net> Importance: Normal Subject: RE: Digest Authentication Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5447 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi All, I'm working on Open Text's WebDAV server, so these issues are somewhat important to me. At issue is not whether or not it's OK to allow Basic, but whether or not it's necessary, or even acceptable, to require Digest. This is not a binary decision. These are separate questions. The offending sentence is in paragraph 3 of 17.1, where it says "WebDAV applications MUST support the Digest authentication scheme". For a server application, a reasonable interpretation of this directive means that a client can authenticate with any WebDAV server using Digest authentication. This implies (in the strong sense) that a server _cannot_ require stronger authentication. It similarly implies that a client _cannot_ require stronger authentication. It also implies that WebDAV servers cannot exist in authenticated environments that are _too_secure_ to support Digest. I'm willing to accept that IETF and W3C policies would forbid sending passwords in the clear, and I'll admit to not having done an exhaustive search, but I cannot believe that it is the policy of either IETF or W3C to forbid organizational requirements for strong authentication mechanisms. Paragraph 2 in 17.1 already sets the appropriate lower bound on authentication security, by giving the admonition against Basic over insecure channels. Paragraph 3 sets only _upper_ bounds on authentication security, which is completely inappropriate. I suspect that the intent of paragraph 3 was to guarantee some level of interoperability when Basic was disallowed, because Basic is usually used as the final fallback. Appropriate wording would be "If a WebDAV client application supports the Basic authentication scheme, then it must also support Digest, and must choose to use Digest over Basic in all circumstances where the server permits both". This leaves both clients and servers free to require strong authentication. It also lets the server require at least Digest as its lowest common denominator, without sacrificing interoperability with any clients. > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Phillip Hallam-Baker > Sent: Friday, October 19, 2001 9:47 PM > To: 'Dylan Barrell'; 'WebDAV'; 'Lisa Dusseault' > Subject: RE: Digest Authentication > > > IETF security policy is the reason why Digest is mandatory. > > W3C policy is not going to accept sending passwords in the clear > either. > > Phill From w3c-dist-auth-request@w3.org Mon Oct 22 20:05:21 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01830 for ; Mon, 22 Oct 2001 20:05:20 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id UAA08418; Mon, 22 Oct 2001 20:03:21 -0400 (EDT) Resent-Date: Mon, 22 Oct 2001 20:03:21 -0400 (EDT) Resent-Message-Id: <200110230003.UAA08418@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id UAA08394 for ; Mon, 22 Oct 2001 20:03:15 -0400 (EDT) Received: from cats.ucsc.edu (rumpleteazer.ucsc.edu [128.114.129.45]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id UAA14895 for ; Mon, 22 Oct 2001 20:03:15 -0400 Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177]) by cats.ucsc.edu (8.9.3/8.8.4.cats-athena) with SMTP id RAA25247; Mon, 22 Oct 2001 17:04:14 -0700 (PDT) From: "Jim Whitehead" To: , "'Phillip Hallam-Baker'" , "'WebDAV'" Date: Mon, 22 Oct 2001 16:59:16 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <001501c15b48$e7c5fe10$d482a8c0@mt2k> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: RE: Digest Authentication Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5448 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > The offending sentence is in paragraph 3 of 17.1, where it says "WebDAV > applications MUST support the Digest authentication scheme". I wrote this section of 2518. The intent was to ensure that: (a) all server implementations were capable, if properly configured, of performing Digest authentication. (b) all client implementations were capable of responding to a Digest authentication challenge, if issued by a server. The rationale behind this was the IETF's stated policy of not approving new protocols that sent username/password pairs over the wire in the clear. Note, however, that RFC 2518 does NOT say that servers must USE Digest, merely that they "support" (i.e., "implement") it. RFC 2518 also does NOT say that you cannot implement or use other authentication technologies. IIS 5, for example, can be configured to use NTLM, and/or Digest, and/or Basic. We recognized that there are a wide, wide range of deployment scenarios, and we could not, a priori, predict what they would be like. Thus we left the decision on whether to actually use Digest to the people deploying WebDAV servers. And, yes, we did realize that initially, most DAV use would involve Basic authentication over the open Internet, or within an intranet. > For a server application, a reasonable interpretation of this directive > means that a client can authenticate with any WebDAV server using Digest > authentication. The cause-effect is a little skewed here. The interpretation is that it must be possible to configure a client such that it can respond to a Digest authentication challenge issued by the server. > This implies (in the strong sense) that a server _cannot_ > require stronger authentication. I do not see how this follows. IIS 5/6 is a counter-example of a server that has successfully implemented an additional authentication scheme, NTLM, in addition to Digest and Basic. > It similarly implies that a client _cannot_ require stronger > authentication. In a challenge-response authentication scheme, I don't see how a client can require *anything*. A client could be configured to refuse to answer a challenge in a particular authentication scheme (say, Basic), but not answering is a different beast from *requiring* a specific authentication scheme. > It also implies that WebDAV servers cannot exist in authenticated > environments that are _too_secure_ to support Digest. I disagree. Following RFC 2518, someone deploying a DAV server could disable Digest authentication, require connections only via SSL, and only allow Basic authentication. > I'm willing to accept that IETF and W3C policies would forbid sending > passwords in the clear, and I'll admit to not having done an exhaustive > search, but I cannot believe that it is the policy of either IETF > or W3C to forbid organizational requirements for strong authentication > mechanisms. Correct. But, you're making a strawman out of 2518 that isn't true. Nothing in 2518 prevents the use of stronger (or any) authentication schemes other than Basic and Digest. Since Digest is unsatisfactory to a large number of implementors, we felt that it was quite likely that new authentication schemes would be developed over time, and wanted to make sure we could accommodate them. > Appropriate wording would be "If a WebDAV client > application supports the Basic authentication scheme, then it must also > support Digest, and must choose to use Digest over Basic in all > circumstances where the server permits both". Actually, this is too strong, since Basic over SSL is reasonably secure. - Jim From w3c-dist-auth-request@w3.org Mon Oct 22 20:12:07 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01863 for ; Mon, 22 Oct 2001 20:12:07 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id UAA08708; Mon, 22 Oct 2001 20:08:46 -0400 (EDT) Resent-Date: Mon, 22 Oct 2001 20:08:46 -0400 (EDT) Resent-Message-Id: <200110230008.UAA08708@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id UAA08688 for ; Mon, 22 Oct 2001 20:08:42 -0400 (EDT) Received: from cats.ucsc.edu (rumpleteazer.ucsc.edu [128.114.129.45]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id UAA15405 for ; Mon, 22 Oct 2001 20:08:42 -0400 Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177]) by cats.ucsc.edu (8.9.3/8.8.4.cats-athena) with SMTP id RAA26661; Mon, 22 Oct 2001 17:09:45 -0700 (PDT) From: "Jim Whitehead" To: , "'Phillip Hallam-Baker'" , "'Dylan Barrell'" , "'WebDAV'" Date: Mon, 22 Oct 2001 17:04:48 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <001501c15b48$e7c5fe10$d482a8c0@mt2k> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: RE: Digest Authentication Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5449 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Let me note that the DAV WG was never given the mandate to develop new authentication schemes, and we never wanted to. There is widespread agreement that Digest has many drawbacks. Yet, as a protocol specifier, I currently do not have an open protocol specification free of IP restrictions that gives a more secure solution than Digest for use with HTTP. I, personally, have no interest in working on such a thing. But, I know there are many people who are very interested in seeing a better authentication scheme developed. So, how much pain does this represent? Enough to start a working group to develop a better alternative to Digest? If so, I am more than happy to work with interested parties to get a birds-of-a-feather (BOF) meeting scheduled on this topic at the next IETF, and to help you with the process of forming a new working group. - Jim From w3c-dist-auth-request@w3.org Mon Oct 22 20:34:01 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02087 for ; Mon, 22 Oct 2001 20:34:01 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id UAA11462; Mon, 22 Oct 2001 20:32:07 -0400 (EDT) Resent-Date: Mon, 22 Oct 2001 20:32:07 -0400 (EDT) Resent-Message-Id: <200110230032.UAA11462@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id UAA11375 for ; Mon, 22 Oct 2001 20:31:54 -0400 (EDT) Received: from life.ai.mit.edu (life.ai.mit.edu [128.52.32.80]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id UAA18137 for ; Mon, 22 Oct 2001 20:31:54 -0400 Received: from Phillspc (h08004607c62f.ne.mediaone.net [66.31.37.190]) by life.ai.mit.edu (8.9.3/8.9.3/AI2.13/ai.master.life:2.21) with SMTP id UAA26396; Mon, 22 Oct 2001 20:31:52 -0400 (EDT) From: "Phillip Hallam-Baker" To: "'Dylan Barrell'" , "'WebDAV'" , "'Lisa Dusseault'" Date: Mon, 22 Oct 2001 20:28:56 -0400 Message-ID: <006c01c15b59$b43873a0$4100a8c0@ne.mediaone.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: Subject: RE: Digest Authentication Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5450 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit The policy makes very good sense. Sending passwords in the clear is one of the major causes of compromised passwords. If password is compromised it is likely that the effect will compromise applications beyond just WebDav because many users share passwords across applications. The excuses given for not supporting digest were unconvincing. You have an application that is not HTTP 1.1 compliant, so fix the thing. WebDav is not going to proceed to standards status in any standards group I have influence in if BASIC is the only mandatory to implement authentication scheme. In the IETF it will be subject to Jeff Schiller's veto on the IESG. In the W3C I will point the director to the IESG policy and the reason for which it was made. I don't think that you are going to persuade the W3C director to second guess the IETF on the issue. Phill > -----Original Message----- > From: Dylan Barrell [mailto:dbarrell@opentext.com] > Sent: Monday, October 22, 2001 9:28 AM > To: Phillip Hallam-Baker; 'WebDAV'; 'Lisa Dusseault' > Subject: RE: Digest Authentication > > > So we have to stick to policy even when there are > indisputable reasons why > it doesn't make sense? > > This doesn't seem like a very sensible thing to do. > > --Dylan > > From w3c-dist-auth-request@w3.org Tue Oct 23 09:39:41 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01692 for ; Tue, 23 Oct 2001 09:39:41 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id JAA25199; Tue, 23 Oct 2001 09:36:39 -0400 (EDT) Resent-Date: Tue, 23 Oct 2001 09:36:39 -0400 (EDT) Resent-Message-Id: <200110231336.JAA25199@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id JAA25174 for ; Tue, 23 Oct 2001 09:36:34 -0400 (EDT) Received: from opentext.com (drawbridge.opentext.com [204.138.115.3]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id JAA04298 for ; Tue, 23 Oct 2001 09:36:33 -0400 Received: (from root@localhost) by opentext.com (8.9.3/8.9.3) id JAA07376; Tue, 23 Oct 2001 09:35:31 -0400 Received: from 022.dhcp2.liv.opentext.com(172.17.2.22) by krusty.wl.opentext.com via smap (V2.1) id xma007360; Tue, 23 Oct 01 09:35:27 -0400 From: "Dylan Barrell" To: "Phillip Hallam-Baker" , "'WebDAV'" , "'Lisa Dusseault'" Date: Tue, 23 Oct 2001 09:34:57 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <006c01c15b59$b43873a0$4100a8c0@ne.mediaone.net> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Subject: RE: Digest Authentication Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5451 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > The excuses given for not supporting digest were unconvincing. You > have an application that is not HTTP 1.1 compliant, so fix the thing. Phillip - show me the arguments against - other than the fact that policy is against it. For all I care, we can make NTLM authentication mandatory as this does not have the drawbacks that Digest does. Or otherwise make SSL mandatory. Digest authentication has ramifications for a server that are UNACCEPTABLE in the real world. I am talking about 5 million users of our product here - not one or two! I am talking about global 2000 companies! I am talking about REAL objections that we face EVERY DAY at our customers! This is not some academic discussion - this is the real world! --Dylan From w3c-dist-auth-request@w3.org Tue Oct 23 12:20:25 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09855 for ; Tue, 23 Oct 2001 12:20:25 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA08325; Tue, 23 Oct 2001 12:17:29 -0400 (EDT) Resent-Date: Tue, 23 Oct 2001 12:17:29 -0400 (EDT) Resent-Message-Id: <200110231617.MAA08325@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id MAA08301 for ; Tue, 23 Oct 2001 12:17:19 -0400 (EDT) Received: from opentext.com (drawbridge.opentext.com [204.138.115.3]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id MAA01046 for ; Tue, 23 Oct 2001 12:17:19 -0400 Received: from mt2k (212.dhcp.ott.opentext.com [192.168.130.212]) by opentext.com (8.9.3/8.9.3) with SMTP id MAA01667; Tue, 23 Oct 2001 12:16:17 -0400 Reply-To: From: "Matt Timmermans" To: "'Jim Whitehead'" , "'WebDAV'" Date: Tue, 23 Oct 2001 12:16:14 -0400 Message-ID: <000801c15bde$0a1462a0$d482a8c0@mt2k> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Subject: RE: Digest Authentication Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5452 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Jim Whitehead [mailto:ejw@cse.ucsc.edu] > Sent: Monday, October 22, 2001 7:59 PM > [...] > The intent was to ensure that: > (a) all server implementations were capable, if properly > configured, of > performing Digest authentication. > [...] This is still quite unclear. What are the testable properties of a server that "Supports the digest authentication scheme"? The way I read it, "MUST support the Digest authentication scheme" says that the server must return Digest as an available scheme in its "WWW-Authenticate" headers, and that it must allow access to clients that generate appropriate Digest responses. This is the way you _want_ me to read your specs, because if I don't read them this way, we run in to the kind of troubles we have below. > Note, however, that RFC 2518 does NOT say that servers must > USE Digest, merely that they "support" (i.e., "implement") it. > RFC 2518 also does NOT say that you cannot implement or use other > authentication technologies. IIS 5, for example, can be configured > to use NTLM, and/or Digest, and/or Basic. IIS can only be configured to present Digest in WWW-Authenticate if your user database is in stored in Active Directory. Does IIS still support Digest, or does (IIS+Active directory) support Digest? If I send IIS an OPTIONS, does it have the right to claim DAV-compliance if Active directory isn't installed? If DoD gets a special version of IIS that disables the Basic and Digest options, because DoD only allows their public-key scheme, does that version support Digest? > > This implies (in the strong sense) that a server _cannot_ > > require stronger authentication. > > I do not see how this follows. IIS 5/6 is a counter-example > of a server that > has successfully implemented an additional authentication > scheme, NTLM, in > addition to Digest and Basic. I trust you can see how it follows from my reading. "The server requires NTLM" means that NTLM is the only scheme presented in WWW-Authenticate. If Digest MUST be present in WWW-Authenticate, then the server cannot require NTLM. > > It similarly implies that a client _cannot_ require stronger > > authentication. > > In a challenge-response authentication scheme, I don't see > how a client can > require *anything*. A client could be configured to refuse > to answer a > challenge in a particular authentication scheme (say, Basic), but not > answering is a different beast from *requiring* a specific > authentication > scheme. If a client will only answer NTLM authentication requests, then it requires NTLM. That means that if a server only allows Basic and Digest, then you can't access it with that client. In high-security environments, this is a perfectly reasonable thing for the client to do, because the client might have a responsibility to protect the user's password. > > It also implies that WebDAV servers cannot exist in authenticated > > environments that are _too_secure_ to support Digest. > > I disagree. Following RFC 2518, someone deploying a DAV > server could disable > Digest authentication, require connections only via SSL, and > only allow > Basic authentication. So there is no way to determine from the client side whether or not a server "supports the Digest authentication scheme"? That is very odd. You're saying that if I run my server in an environment that doesn't allow me to present Digest in the WWW-Authenticate headers, then that's OK, as long as there's a checkbox for Digest somewhere and I've unchecked it? But the server would become mysteriously non-compliant if I customized it for my environment by removing the checkbox, and that Digest implementation that isn't used? It would become non-compliant, even though it's functionally equivalent?! Even if this was reasonable, it would be outside the scope of a protocol specification. From w3c-dist-auth-request@w3.org Tue Oct 23 14:01:59 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13970 for ; Tue, 23 Oct 2001 14:01:59 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA13586; Tue, 23 Oct 2001 13:59:14 -0400 (EDT) Resent-Date: Tue, 23 Oct 2001 13:59:14 -0400 (EDT) Resent-Message-Id: <200110231759.NAA13586@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id NAA13566 for ; Tue, 23 Oct 2001 13:59:07 -0400 (EDT) Received: from cats.ucsc.edu (rumpleteazer.ucsc.edu [128.114.129.45]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id NAA12027 for ; Tue, 23 Oct 2001 13:59:07 -0400 Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177]) by cats.ucsc.edu (8.9.3/8.8.4.cats-athena) with SMTP id LAA04724; Tue, 23 Oct 2001 11:00:17 -0700 (PDT) From: "Jim Whitehead" To: , "'WebDAV'" Date: Tue, 23 Oct 2001 10:55:12 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <000801c15bde$0a1462a0$d482a8c0@mt2k> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: RE: Digest Authentication Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5453 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > This is still quite unclear. What are the testable properties of a server > that "Supports the digest authentication scheme"? The testable property is this: It must be possible to configure the server, without writing new code, such that it will return a Digest authentication challenge for a GET on given resource R. It is possible to create a falsifiable test of this property. > I trust you can see how it follows from my reading. "The server requires > NTLM" means that NTLM is the only scheme presented in > WWW-Authenticate. If Digest MUST be present in WWW-Authenticate, then the > server cannot require NTLM. Again, RFC 2518 does not mandate that Digest MUST be present in every WWW-Authenticate header, only that it must be possible to configure that server to make this so. > > > It also implies that WebDAV servers cannot exist in authenticated > > > environments that are _too_secure_ to support Digest. > > > > I disagree. Following RFC 2518, someone deploying a DAV > > server could disable Digest authentication, require connections > > only via SSL, and only allow Basic authentication. > > So there is no way to determine from the client side whether or > not a server "supports the Digest authentication scheme"? That is > very odd. No, the client only has the ability to determine which authentication schemes are currently active on a specific resource, by examining the WWW-Authenticate header. Even if the client could determine that Digest was supported, but not turned on for a particular resource, what would it do with that information? Having this information wouldn't lead to greater interoperability. > You're saying that if I run my server in an environment that doesn't allow > me to present Digest in the WWW-Authenticate headers, then that's OK, as > long as there's a checkbox for Digest somewhere and I've unchecked it? Correct. (Assuming you mean the checkbox is on the server). > But the server would become mysteriously non-compliant if I > customized it for my environment by removing the checkbox, and that > Digest implementation that isn't used? It would become non-compliant, > even though it's functionally equivalent?! My personal opinion is that if the checkbox controlled a process that swapped in/out a code library implementing the server-side storage of passwords (and possibly resulted in data conversion of a password database to a new format), that would be acceptable. That is, you could have a running server executable that was incapable of Digest, so long as there was an easy process (i.e., one that does not involve writing code) for changing that executable so that it could support Digest. In operational environments where Digest was not acceptable, the Digest code would never be merged into the server executable. Alternately, it might even be OK to have to go back to the installation disk to get Digest support added. What is unacceptable is for a user of a server to have to write code to get Digest support. The goal is to make it "relatively easy" for a server operator to enable/disable Digest authentication support on their server. > Even if this was reasonable, it would be outside the scope of a protocol > specification. I have to agree with Phill here. The political reality of the IESG is such that an application protocol specification will not be approved if the only mechanism for sending passwords over the wire is in the clear. My techical opinion is that the current "Basic over SSL" or Digest choices are the weakest possible requirements that will allow the specification to be accepted. This is why I was encouraging people to develop a new, more acceptable form of HTTP authentication technology. But, the IETF has a long history of pragmatism, and so they would be amenable to arguments about the lack of suitability of Digest. However, I do feel you have an uphill climb to convince people that the problems with Digest are inherent to the protocol, and not merely a peculiarity of your particular implementation. The path of argumentation usually runs: Person A: For implementation architecture X, Digest has the following bad properties. Person B: Ah, but if you do your implementation this way (...), you don't have that problem. Person A: Well, that may be true, but it would be difficult/costly to do it that way. Person B: Well then, your objection isn't to the protocol, it's to the expense of implementing the protocol. That is, it's not a technical argument, it's an economic one. Now, you could present evidence that enough people have enough problems with the implementation that it does imply a problem with the protocol, but that's a tough argument to make. - Jim From w3c-dist-auth-request@w3.org Tue Oct 23 14:03:17 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14015 for ; Tue, 23 Oct 2001 14:03:17 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA13756; Tue, 23 Oct 2001 14:00:55 -0400 (EDT) Resent-Date: Tue, 23 Oct 2001 14:00:55 -0400 (EDT) Resent-Message-Id: <200110231800.OAA13756@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id OAA13727 for ; Tue, 23 Oct 2001 14:00:42 -0400 (EDT) Received: from cats.ucsc.edu (rumpleteazer.ucsc.edu [128.114.129.45]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id OAA12225 for ; Tue, 23 Oct 2001 14:00:42 -0400 Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177]) by cats.ucsc.edu (8.9.3/8.8.4.cats-athena) with SMTP id LAA05309; Tue, 23 Oct 2001 11:01:53 -0700 (PDT) From: "Jim Whitehead" To: "Phillip Hallam-Baker" , "'WebDAV'" Date: Tue, 23 Oct 2001 10:56:49 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <006c01c15b59$b43873a0$4100a8c0@ne.mediaone.net> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: RE: Digest Authentication Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5454 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > In the IETF it will be subject to Jeff Schiller's veto on the IESG. > > In the W3C I will point the director to the IESG policy and the reason > for which it was made. I don't think that you are going to persuade > the W3C director to second guess the IETF on the issue. Now, Phill, we're just having a discussion to flesh out the cross product of Digest X WebDAV. No need to whip out the big sticks yet. - Jim From w3c-dist-auth-request@w3.org Tue Oct 23 14:10:51 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14388 for ; Tue, 23 Oct 2001 14:10:50 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA14746; Tue, 23 Oct 2001 14:08:15 -0400 (EDT) Resent-Date: Tue, 23 Oct 2001 14:08:15 -0400 (EDT) Resent-Message-Id: <200110231808.OAA14746@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id OAA14708 for ; Tue, 23 Oct 2001 14:08:02 -0400 (EDT) Received: from cats.ucsc.edu (rumpleteazer.ucsc.edu [128.114.129.45]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id OAA13183 for ; Tue, 23 Oct 2001 14:08:02 -0400 Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177]) by cats.ucsc.edu (8.9.3/8.8.4.cats-athena) with SMTP id LAA07760; Tue, 23 Oct 2001 11:09:13 -0700 (PDT) From: "Jim Whitehead" To: , "'WebDAV'" Date: Tue, 23 Oct 2001 11:04:08 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <000801c15bde$0a1462a0$d482a8c0@mt2k> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: RE: Digest Authentication Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5455 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > You're saying that if I run my server in an environment that doesn't allow > me to present Digest in the WWW-Authenticate headers, then that's OK, as > long as there's a checkbox for Digest somewhere and I've unchecked it? Just thought of another example. The Apache server "supports" Digest authentication, even though the process of enabling it involves installing a new module (mod_auth_digest). In the case of Apache, it is possible to create a server that does not have any Digest authentication code in the running server executable. Thus, Apache is an existence proof of "supporting" Digest, while not compromising security in environments where characteristics of the Digest implementation are unacceptable. - Jim From w3c-dist-auth-request@w3.org Tue Oct 23 14:34:40 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15330 for ; Tue, 23 Oct 2001 14:34:39 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA16803; Tue, 23 Oct 2001 14:30:05 -0400 (EDT) Resent-Date: Tue, 23 Oct 2001 14:30:05 -0400 (EDT) Resent-Message-Id: <200110231830.OAA16803@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id OAA16777 for ; Tue, 23 Oct 2001 14:29:59 -0400 (EDT) Received: from greenbytes.de (mail.greenbytes.de [217.5.201.10] (may be forged)) by tux.w3.org (8.9.3/8.9.3) with ESMTP id OAA16187 for ; Tue, 23 Oct 2001 14:29:59 -0400 Received: from apu [192.168.1.2] by greenbytes.de [217.5.201.11] with SMTP (MDaemon.v3.5.3.R) for ; Tue, 23 Oct 2001 20:29:44 +0200 From: "Stefan Eissing" To: "Jim Whitehead" , , "'WebDAV'" Date: Tue, 23 Oct 2001 20:30:16 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal In-Reply-To: X-MDRemoteIP: 192.168.1.2 X-Return-Path: stefan.eissing@greenbytes.de X-MDaemon-Deliver-To: w3c-dist-auth@w3.org Subject: RE: Digest Authentication Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5456 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Now, are we having fun here or what? I just scanned RFC 2617 for any MUST wording on digest authentication and could not find any. The thing I found is in Ch. 4.1, 3rd paragraph: "Because Basic authentication involves the cleartext transmission of passwords it SHOULD NOT be used (without enhancements) to protect sensible or valuable information." I think this is the way it should be stated for WebDAV as well, if it must be stated at all. //Stefan > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jim Whitehead > Sent: Tuesday, October 23, 2001 8:04 PM > To: mtimmerm@opentext.com; 'WebDAV' > Subject: RE: Digest Authentication > > > > You're saying that if I run my server in an environment that > doesn't allow > > me to present Digest in the WWW-Authenticate headers, then that's OK, as > > long as there's a checkbox for Digest somewhere and I've unchecked it? > > Just thought of another example. The Apache server "supports" Digest > authentication, even though the process of enabling it involves > installing a > new module (mod_auth_digest). In the case of Apache, it is possible to > create a server that does not have any Digest authentication code in the > running server executable. > > Thus, Apache is an existence proof of "supporting" Digest, while not > compromising security in environments where characteristics of the Digest > implementation are unacceptable. > > - Jim > > > From w3c-dist-auth-request@w3.org Tue Oct 23 14:49:32 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15775 for ; Tue, 23 Oct 2001 14:49:32 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA18539; Tue, 23 Oct 2001 14:46:05 -0400 (EDT) Resent-Date: Tue, 23 Oct 2001 14:46:05 -0400 (EDT) Resent-Message-Id: <200110231846.OAA18539@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id OAA18519 for ; Tue, 23 Oct 2001 14:46:01 -0400 (EDT) Received: from opentext.com (drawbridge.opentext.com [204.138.115.3]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id OAA18036 for ; Tue, 23 Oct 2001 14:46:00 -0400 Received: from mt2k (212.dhcp.ott.opentext.com [192.168.130.212]) by opentext.com (8.9.3/8.9.3) with SMTP id OAA09616; Tue, 23 Oct 2001 14:44:56 -0400 Reply-To: From: "Matt Timmermans" To: "'Jim Whitehead'" , "'WebDAV'" Date: Tue, 23 Oct 2001 14:44:52 -0400 Message-ID: <000c01c15bf2$ce87e3f0$d482a8c0@mt2k> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Subject: RE: Digest Authentication Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5457 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Jim Whitehead > > The testable property is this: > > It must be possible to configure the server, without writing > new code, such > that it will return a Digest authentication challenge for a > GET on given > resource R. All right. By this definition, our server already supports Digest, even though it won't be available in most installations. There are unattractive ways of installing it that pass through Digest authentication in the Web servers we bind to. However, I _know_ that any customer who is expecting "Digest" in his WWW-Authenticate headers will think me a weasel if I provide this explanation -- even if I can demonstrate that Jim Says It's OK. Is there an authoritative reference I can point to that details this interpretation of "must support the Digest authentication scheme"? If not, can we have a public authoritative erratum that spells it out? I'm pretty sure that anybody who just reads the spec is going to expect the Digest scheme in WWW-Authenticate, and will expect clients to know how to respond. > I have to agree with Phill here. The political reality of the > IESG is such > that an application protocol specification will not be > approved if the only > mechanism for sending passwords over the wire is in the > clear. Agreed, but this can be addressed with the standard cop-out that says that normal HTTP authentication methods are used, that choosing one is out-of-scope, that security is important for WebDAV, and that, therefore, Basic over the Web is inappropriate. The Digest requirement still performs no useful function. I suggested that it set only _upper_ bounds on security, and you replied that even those don't exist. From w3c-dist-auth-request@w3.org Tue Oct 23 16:33:41 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19169 for ; Tue, 23 Oct 2001 16:33:40 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA00686; Tue, 23 Oct 2001 16:30:24 -0400 (EDT) Resent-Date: Tue, 23 Oct 2001 16:30:24 -0400 (EDT) Resent-Message-Id: <200110232030.QAA00686@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id QAA00656 for ; Tue, 23 Oct 2001 16:30:17 -0400 (EDT) Received: from opentext.com (drawbridge.opentext.com [204.138.115.3]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id QAA30717 for ; Tue, 23 Oct 2001 16:30:17 -0400 Received: (from root@localhost) by opentext.com (8.9.3/8.9.3) id QAA24415; Tue, 23 Oct 2001 16:29:46 -0400 Received: from 022.dhcp2.liv.opentext.com(172.17.2.22) by krusty.wl.opentext.com via smap (V2.1) id xmaa24391; Tue, 23 Oct 01 16:29:40 -0400 From: "Dylan Barrell" To: , "'Jim Whitehead'" , "'WebDAV'" Date: Tue, 23 Oct 2001 16:29:03 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <000c01c15bf2$ce87e3f0$d482a8c0@mt2k> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Subject: RE: Digest Authentication Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5458 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Yes, we can configure the Livelink server to support Digest Authentication. Just seems a bit silly to have a mandatory part of a spec, that will never get used in practice because it is too insecure, but the only reason it is mandatory is policy aimed at making specs more secure. I suppose that we just have to resign ourselves to these types of realities ;-) --Dylan From w3c-dist-auth-request@w3.org Tue Oct 23 18:31:03 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21757 for ; Tue, 23 Oct 2001 18:31:03 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAA08335; Tue, 23 Oct 2001 18:24:29 -0400 (EDT) Resent-Date: Tue, 23 Oct 2001 18:24:29 -0400 (EDT) Resent-Message-Id: <200110232224.SAA08335@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id SAA08315 for ; Tue, 23 Oct 2001 18:24:24 -0400 (EDT) Received: from cats.ucsc.edu (rumpleteazer.ucsc.edu [128.114.129.45]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id SAA11153 for ; Tue, 23 Oct 2001 18:24:25 -0400 Received: from Tycho (dhcp-55-194.cse.ucsc.edu [128.114.55.194]) by cats.ucsc.edu (8.9.3/8.8.4.cats-athena) with SMTP id PAA19229; Tue, 23 Oct 2001 15:25:34 -0700 (PDT) From: "Jim Whitehead" To: "Dylan Barrell" , , "'WebDAV'" Date: Tue, 23 Oct 2001 15:20:28 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-reply-to: X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Subject: RE: Digest Authentication Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5459 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Dylan, Matt, others: Out of curiosity, what authentication options do you consider to be good enough to meet your requirements? - Jim From w3c-dist-auth-request@w3.org Tue Oct 23 19:11:33 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22317 for ; Tue, 23 Oct 2001 19:11:31 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id TAA10927; Tue, 23 Oct 2001 19:06:39 -0400 (EDT) Resent-Date: Tue, 23 Oct 2001 19:06:39 -0400 (EDT) Resent-Message-Id: <200110232306.TAA10927@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id TAA10906 for ; Tue, 23 Oct 2001 19:06:27 -0400 (EDT) Received: from opentext.com (drawbridge.opentext.com [204.138.115.3]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id TAA14937 for ; Tue, 23 Oct 2001 19:06:27 -0400 Received: from mt2k (212.dhcp.ott.opentext.com [192.168.130.212]) by opentext.com (8.9.3/8.9.3) with SMTP id TAA22481; Tue, 23 Oct 2001 19:05:23 -0400 Reply-To: From: "Matt Timmermans" To: "'Jim Whitehead'" , "'Dylan Barrell'" , "'WebDAV'" Date: Tue, 23 Oct 2001 19:05:19 -0400 Message-ID: <001e01c15c17$30868510$d482a8c0@mt2k> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Subject: RE: Digest Authentication Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5460 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit I'm happy with Basic over SSL. If you want security over the Web, you might as well use SSL. Most of our intranet customers would probably prefer NTLM. For parts of the intranet that don't require security, Basic suffices. I'm not sure that really secure authentication without SSL is even a requirement, but if you want it, then there are several alternative public key technologies that do just fine. While any organization might choose one of these, they are not without IP issues, as you've noted. Without public key techniques, there is a limit on how secure authentication can be. Digest doesn't meet that limit, because it's possible to require eavesdropping on an authentication session _and_ access to the server's stored password information, before it's possible to impersonate a user. I don't know of any standard scheme like this, though, and I don't know if there's a need for one. > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jim Whitehead > Sent: Tuesday, October 23, 2001 6:20 PM > To: Dylan Barrell; mtimmerm@opentext.com; 'WebDAV' > Subject: RE: Digest Authentication > > > Dylan, Matt, others: Out of curiosity, what authentication > options do you > consider to be good enough to meet your requirements? > > - Jim From w3c-dist-auth-request@w3.org Wed Oct 24 04:18:18 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18995 for ; Wed, 24 Oct 2001 04:18:18 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id EAA06846; Wed, 24 Oct 2001 04:09:53 -0400 (EDT) Resent-Date: Wed, 24 Oct 2001 04:09:53 -0400 (EDT) Resent-Message-Id: <200110240809.EAA06846@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id EAA06826 for ; Wed, 24 Oct 2001 04:09:48 -0400 (EDT) Received: from adobe.com (smtp-relay-2.adobe.com [192.150.11.2]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id EAA27845 for ; Wed, 24 Oct 2001 04:09:48 -0400 Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by adobe.com (1.0.0/8.11.4) with ESMTP id f9O88Vb16500 for ; Wed, 24 Oct 2001 01:08:31 -0700 (PDT) Received: from mail-hamburg.eur.adobe.com (mail-hamburg [130.248.122.254]) by inner-relay-1.corp.adobe.com (8.11.4/8.11.4) with ESMTP id f9O89QS29581 for ; Wed, 24 Oct 2001 01:09:26 -0700 (PDT) Received: from maileurope-ham.eur.adobe.com (maileurope-ham [130.248.122.251]) by mail-hamburg.eur.adobe.com (8.11.4/8.11.4) with ESMTP id f9O897I02167 for ; Wed, 24 Oct 2001 10:09:10 +0200 (MET DST) Received: from [130.248.122.215] ([130.248.122.215]) by maileurope-ham.eur.adobe.com (Netscape Messaging Server 4.15 ham Jul 11 2001 16:32:57) with ESMTP id GLPAN600.3HN; Wed, 24 Oct 2001 10:09:06 +0200 Mime-Version: 1.0 X-Sender: dbrotsky@mailsj.corp.adobe.com Message-Id: In-Reply-To: References: Date: Tue, 23 Oct 2001 16:01:10 -0700 To: "Jim Whitehead" From: Daniel Brotsky Cc: , "'WebDAV'" Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: RE: Digest Authentication Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5461 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: At 11:04 AM -0700 10/23/01, Jim Whitehead wrote: > > You're saying that if I run my server in an environment that doesn't allow >> me to present Digest in the WWW-Authenticate headers, then that's OK, as >> long as there's a checkbox for Digest somewhere and I've unchecked it? > >Just thought of another example. The Apache server "supports" Digest >authentication, even though the process of enabling it involves installing a >new module (mod_auth_digest). In the case of Apache, it is possible to >create a server that does not have any Digest authentication code in the >running server executable. > >Thus, Apache is an existence proof of "supporting" Digest, while not >compromising security in environments where characteristics of the Digest >implementation are unacceptable. > I'm sorry, but this response seems like it completely misses the point that Dylan is making about testability. There is no principled way to distinguish between altering a configuration file and "writing code," and I very much doubt that you could come up with language that makes this distinction that this group is willing to put into the spec. Without such language, there is no way to test server compliance with the requirement that a server "MUST support digest authentication without the server administrator writing code," which is apparently what you meant the spec to say (as opposed to what it actually says, which I would argue is more naturally interpreted as "no server configuration can be considered a compliant WebDAV server unless all challenges it issues against its WebDAV URLs contain a WWW-authentication header specifying digest authentication.") I also believe that this discussion, so far, misses the larger point someone raise a while ago about "WebDAV has *nothing* to say about authentication." I believe that: 1. WebDAV is intended to be a pure HTTP 1.1 extension (as explicitly defined and allowed for in the HTTP 1.1 spec). 2. Like all "good extensions" :^), it should have absolutely nothing in it except specification of the semantics of its extension methods and the semantics of its extension headers. 3. The IETF concern about future protocol specs requiring stronger authentication than basic makes perfect sense for protocols that are not HTTP extensions but can't sensibly be taken as a mandate for HTTP extensions: such protocols ARE simply a form of HTTP 1.1. To see point 3 clearly, consider that WebDAV servers needn't implement digest over the GET, HEAD, and POST methods, because those methods are HTTP 1.1 methods and so their semantics can't be redefined by the WebDAV spec. Putting a requirement for digest authentication in the WebDAV spec is a no-op except for the extension methods, and thus does not promote security in any effective way. I believe that if the IETF really wants servers that obey its protocols to enforce something stronger than basic, then the security group had better write a very short RFC that updates 2068 and says "HTTP 1.1 servers, including those that implement HTTP 1.1 extensions, MUST implement either digest or a more secure authentication scheme whenever they require authentication for a request made over an insecure connection." Then they should move as quickly as possible to promote that RFC along the standards track. Holding HTTP 1.1 extensions hostage to a policy that's not applied to HTTP 1.1 is a non-starter position: there will never be any HTTP 1.1 extension that supports as much authenticated traffic as plain old HTTP 1.1 does. dan -- Daniel Brotsky, Adobe Systems tel 408-536-4150, pager 877-704-4062 2-way pager email: From w3c-dist-auth-request@w3.org Wed Oct 24 10:58:30 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02496 for ; Wed, 24 Oct 2001 10:58:29 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id KAA28207; Wed, 24 Oct 2001 10:51:15 -0400 (EDT) Resent-Date: Wed, 24 Oct 2001 10:51:15 -0400 (EDT) Resent-Message-Id: <200110241451.KAA28207@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id KAA28180 for ; Wed, 24 Oct 2001 10:51:10 -0400 (EDT) Received: from opentext.com (drawbridge.opentext.com [204.138.115.3]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id KAA06551 for ; Wed, 24 Oct 2001 10:51:10 -0400 Received: (from root@localhost) by opentext.com (8.9.3/8.9.3) id KAA17863; Wed, 24 Oct 2001 10:50:34 -0400 Received: from 022.dhcp2.liv.opentext.com(172.17.2.22) by krusty.wl.opentext.com via smap (V2.1) id xmaa17810; Wed, 24 Oct 01 10:50:29 -0400 From: "Dylan Barrell" To: , "'Jim Whitehead'" , "'WebDAV'" Date: Wed, 24 Oct 2001 10:49:57 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-Mimeole: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal In-Reply-To: <001e01c15c17$30868510$d482a8c0@mt2k> Subject: RE: Digest Authentication Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5462 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit I agree with Matt - in reality some transport layer security will be used. The real problem with digest is that it makes our server LESS secure. Basic over SSL is actually better. --Dylan From w3c-dist-auth-request@w3.org Thu Oct 25 05:48:43 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12481 for ; Thu, 25 Oct 2001 05:48:43 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id FAA22351; Thu, 25 Oct 2001 05:46:50 -0400 (EDT) Resent-Date: Thu, 25 Oct 2001 05:46:50 -0400 (EDT) Resent-Message-Id: <200110250946.FAA22351@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id FAA22325 for ; Thu, 25 Oct 2001 05:46:31 -0400 (EDT) Received: from fullname.com (IDENT:root@paxil.bluescreen.org [216.160.123.12]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id FAA32285 for ; Thu, 25 Oct 2001 05:46:30 -0400 Received: from wolverine (IDENT:root@paxil.bluescreen.org [216.160.123.12]) (authenticated) by fullname.com (8.11.0/8.11.0) with ESMTP id f9P9eSv22531; Thu, 25 Oct 2001 02:40:29 -0700 Old-X-Envelope-To: w3c-dist-auth@w3.org Message-ID: <00ab01c15d3a$45f0cd60$0200a8c0@wolverine> From: "=?iso-8859-1?B?SvZzaA==?=" To: "Jim Whitehead" , , Date: Thu, 25 Oct 2001 05:48:53 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Subject: I command you to support Digest!!! Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5463 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Here are my thoughts on this. Its a bit late for me, so they might be a bit jumbled.. For those in a hurry, my short answer is: I think that at this time, Digest is no longer the right minimum requirement. Is there some way we can just require an "IETF recognized 'non-plaintext over the wire' authentication system" , such as Digest, Kerberos or SSL+Basic"? My longer explanations... On what/who the requirement applies to... The Requirement applies to implementation, not operation. If you ship a product that claims that it complies with WEBDAV RFC, it must support Digest in the shipped form. If you dont support Digest, then you are not completely compliant. Frankly, I dont think this is such a big deal these days. I imagine a product box or spec that says "Supports WebDAV * " with a footnote below somewhere effectively saying: "* Compliant with RFC XXXX except for Digest Authentication" or "* Conditionally compliant with RFC XXXX. This product does not support Digest" I think its reasonable to have customized versions of products that may only be conditionally compliant. As for servers in operation, it is well known that Operational Policy in an organization may cause a product to be configured in such as way that it does not interoperate with another compliant product. Many specs today seem to have a set of "features" and a minumum required set to be supported, which apply to products claiming compliance yet operators can configure them out of compliance. There is probably some work that should be done to find good language to describe this and differentiate it from "real" requirements that must always be true in both implementation and operation. On Digest as the right choice for the requirement: IMHO, the spirit was "Anyone procuring a product that claims WebDAV RFC compliant must be able to be configured to use a non-plaintext authentication that is recognized by the IETF" Unfortunately, requiring SSL would have been too painful both because it is/was not IPR free and that it is/was considered too hard/heavyweight to require. As a result, Digest was available to be used to solve this problem. Digest was created to fix this problem, of plaintext passwords *over the wire*. I dont think it was obvious at the time how much its implementation would complicate how passwords are stored in practice. Today, I would think that requiring SSL+basic would be less of a hardship than Digest. In my own experience, I know that implementing SSL (for the encryption part at least) was relatively simple and isolated from the rest of the system. In fact, it can be done in a way that applications can use SSL with almost no code changes, similar to socks. Implementing Digest in Windows/IIS was very difficult, since IIS uses authentication integrated with system accounts. Prior to Digest, system passwords were stored in a hash that was incompatible with the digest hash. So some pretty serious architectural changes had to be made to support digest in a non-hacky way. It seems that Daryl has come to a similar realization. I think that at this time, Digest is no longer the right minimum requirement. Is there some way we can just require an "IETF recognized 'non-plaintext over the wire' authentication system, such as Digest, Kerberos or SSL+Basic"? On Testability: Basic Authentication is a required part of HTTP/1.1, testing for that is the same problem as testing for Digest. Depending on your perspective, this reduces to a previously unsolved (or solved) problem. :) From w3c-dist-auth-request@w3.org Thu Oct 25 11:25:20 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21529 for ; Thu, 25 Oct 2001 11:25:20 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id LAA14339; Thu, 25 Oct 2001 11:21:37 -0400 (EDT) Resent-Date: Thu, 25 Oct 2001 11:21:37 -0400 (EDT) Resent-Message-Id: <200110251521.LAA14339@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id LAA14315 for ; Thu, 25 Oct 2001 11:21:31 -0400 (EDT) Received: from adobe.com (smtp-relay-1.adobe.com [192.150.11.1]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id LAA09669 for ; Thu, 25 Oct 2001 11:21:31 -0400 Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by adobe.com (1.0.0/8.11.4) with ESMTP id f9PFLqO03182 for ; Thu, 25 Oct 2001 08:21:52 -0700 (PDT) Received: from mailsj-v1.corp.adobe.com (mailsj-dev.corp.adobe.com [153.32.1.192]) by inner-relay-1.corp.adobe.com (8.11.4/8.11.4) with ESMTP id f9PFLBS06758 for ; Thu, 25 Oct 2001 08:21:11 -0700 (PDT) Received: from larrypad ([130.248.188.138]) by mailsj-v1.corp.adobe.com (Netscape Messaging Server 4.15 v1 Jul 11 2001 16:32:57) with SMTP id GLRPAV00.RAR; Thu, 25 Oct 2001 08:20:55 -0700 From: "Larry Masinter - LMM@acm.org" To: "=?iso-8859-1?B?SvZzaA==?=" , "Jim Whitehead" , , Date: Thu, 25 Oct 2001 08:20:24 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <00ab01c15d3a$45f0cd60$0200a8c0@wolverine> Importance: Normal Subject: RE: I command you to support Digest!!! Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5464 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit In any specification or standard, if you have two options A or B that don't interoperate, you don't get an "interoperable" standard if some people support A but not B, and other people support B but not A. The goal of standards is that there's general interoperability. So a server that only supports basic with SSL may be "secure enough", but it's not "interoperable enough". The standards group must choose a baseline that is both "secure enough" and "interoperable enough". So far, the group chose "must support Digest". If you change it to "must support Digest OR basic+SSL" on the server side, then you're mandating "must support Digest AND basic+SSL" on the client side. This is nice for server implementors but maybe not as nice for client implementors. From w3c-dist-auth-request@w3.org Thu Oct 25 12:34:59 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23216 for ; Thu, 25 Oct 2001 12:34:58 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA20824; Thu, 25 Oct 2001 12:32:47 -0400 (EDT) Resent-Date: Thu, 25 Oct 2001 12:32:47 -0400 (EDT) Resent-Message-Id: <200110251632.MAA20824@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id MAA20803 for ; Thu, 25 Oct 2001 12:32:43 -0400 (EDT) Received: from opentext.com (drawbridge.opentext.com [204.138.115.3]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id MAA21959 for ; Thu, 25 Oct 2001 12:32:42 -0400 Received: from mt2k (212.dhcp.ott.opentext.com [192.168.130.212]) by opentext.com (8.9.3/8.9.3) with SMTP id MAA26005; Thu, 25 Oct 2001 12:31:26 -0400 Reply-To: From: "Matt Timmermans" To: "'Larry Masinter - LMM@acm.org'" , "=?iso-8859-1?Q?'J=F6sh'?=" , "'Jim Whitehead'" , Date: Thu, 25 Oct 2001 12:31:16 -0400 Message-ID: <000701c15d72$787ac050$d482a8c0@mt2k> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Subject: RE: I command you to support Digest!!! Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5465 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Larry Masinter > [...] > The standards group must choose a baseline that is both > "secure enough" and "interoperable enough". So far, the group > chose "must support Digest". If you change it to "must support > Digest OR basic+SSL" on the server side, then you're mandating > "must support Digest AND basic+SSL" on the client side. > > This is nice for server implementors but maybe not as nice for > client implementors. You wouldn't want to tell clients that they have to respond to any particular scheme, because a client might be used in a more restrictive environment. It is no trouble at all, however, to require _clients_ to support (really support!) Digest if they support Basic, because there are no _client-side_ security parameters that Basic meets, but Digest doesn't. From w3c-dist-auth-request@w3.org Thu Oct 25 17:00:11 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00086 for ; Thu, 25 Oct 2001 17:00:09 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA15295; Thu, 25 Oct 2001 16:57:11 -0400 (EDT) Resent-Date: Thu, 25 Oct 2001 16:57:11 -0400 (EDT) Resent-Message-Id: <200110252057.QAA15295@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id QAA15268 for ; Thu, 25 Oct 2001 16:57:01 -0400 (EDT) Received: from fullname.com (IDENT:root@paxil.bluescreen.org [216.160.123.12]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id QAA25511 for ; Thu, 25 Oct 2001 16:56:57 -0400 Received: from wolverine (IDENT:root@paxil.bluescreen.org [216.160.123.12]) (authenticated) by fullname.com (8.11.0/8.11.0) with ESMTP id f9PKofv23185; Thu, 25 Oct 2001 13:50:44 -0700 Old-X-Envelope-To: w3c-dist-auth@w3.org Message-ID: <00ed01c15d97$eb78ec60$0200a8c0@wolverine> From: "=?iso-8859-1?B?SvZzaA==?=" To: "Larry Masinter - LMM@acm.org" , "Jim Whitehead" , , References: Date: Thu, 25 Oct 2001 16:58:37 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Subject: Re: I command you to support Digest!!! Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5466 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 8bit ----- Original Message ----- From: "Larry Masinter - LMM@acm.org" To: "Jösh" ; "Jim Whitehead" ; ; Sent: Thursday, October 25, 2001 11:20 AM Subject: RE: I command you to support Digest!!! > The standards group must choose a baseline that is both > "secure enough" and "interoperable enough". So far, the group > chose "must support Digest". If you change it to "must support > Digest OR basic+SSL" on the server side, then you're mandating > "must support Digest AND basic+SSL" on the client side. > > This is nice for server implementors but maybe not as nice for > client implementors. > Thats a pretty good observation. However, i think digest for server implementors is *hard* while digest for client implementors is *easy*. I think that might be a good plan.. > From w3c-dist-auth-request@w3.org Thu Oct 25 19:55:57 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02472 for ; Thu, 25 Oct 2001 19:55:57 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id TAA23125; Thu, 25 Oct 2001 19:51:21 -0400 (EDT) Resent-Date: Thu, 25 Oct 2001 19:51:21 -0400 (EDT) Resent-Message-Id: <200110252351.TAA23125@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id TAA23105 for ; Thu, 25 Oct 2001 19:51:15 -0400 (EDT) Received: from io.mds.rmit.edu.au (io.mds.rmit.edu.au [131.170.70.10]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id TAA12454 for ; Thu, 25 Oct 2001 19:51:14 -0400 Received: by io.mds.rmit.edu.au (Postfix, from userid 301) id CAE5F49B49; Fri, 26 Oct 2001 09:50:41 +1000 (EST) Date: Fri, 26 Oct 2001 09:50:41 +1000 From: Alan Kent To: w3c-dist-auth@w3.org Message-ID: <20011026095041.A25386@io.mds.rmit.edu.au> References: <00ed01c15d97$eb78ec60$0200a8c0@wolverine> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95i In-Reply-To: =?iso-8859-1?Q?=3C00ed01c15d97$eb78ec60$0200a8c0=40wolverine=3E=3B_from_?= =?iso-8859-1?Q?J=F6sh_on_Thu=2C_Oct_25=2C_2001_at_04:58:37PM_-0400?= Subject: Re: I command you to support Digest!!! Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5467 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: > > The standards group must choose a baseline that is both > > "secure enough" and "interoperable enough". So far, the group > > chose "must support Digest". If you change it to "must support > > Digest OR basic+SSL" on the server side, then you're mandating > > "must support Digest AND basic+SSL" on the client side. > > > > This is nice for server implementors but maybe not as nice for > > client implementors. > > > Thats a pretty good observation. However, i think digest > for server implementors is *hard* while digest for client > implementors is *easy*. For some of our sites, replace *hard* with *impossible*. We do not control the database of user names and passwords. We do not have access to the password, a hashed form of it, or anything. We can only supply details and get back details about the user. Period. For these sites it is impossible to support digest authentication. The customers in these cases *will not* accept having a second copy of the user database. They went to a lot of effort to get single sign on across the organisation. This is my problem, not WebDAV's. I just thought it was worth pointing out again. There was lots of discussion about how you can store hashed versions of the passwords and so its safer etc. However, in many large organisations there is a single group controlling authentication etc and they fight tooth and nail to keep that control - and often rightly so. If security is important, you have to keep your security db secure. Alan From w3c-dist-auth-request@w3.org Thu Oct 25 22:41:36 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06913 for ; Thu, 25 Oct 2001 22:41:35 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id WAA26586; Thu, 25 Oct 2001 22:39:42 -0400 (EDT) Resent-Date: Thu, 25 Oct 2001 22:39:42 -0400 (EDT) Resent-Message-Id: <200110260239.WAA26586@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id WAA26562 for ; Thu, 25 Oct 2001 22:39:33 -0400 (EDT) Received: from adobe.com (smtp-relay-1.adobe.com [192.150.11.1]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id WAA27070 for ; Thu, 25 Oct 2001 22:39:32 -0400 Received: from inner-relay-2.corp.adobe.com ([153.32.1.52]) by adobe.com (1.0.0/8.11.4) with ESMTP id f9Q2dXG28022 for ; Thu, 25 Oct 2001 19:39:33 -0700 (PDT) Received: from mailsj-v1.corp.adobe.com (mailsj-dev.corp.adobe.com [153.32.1.192]) by inner-relay-2.corp.adobe.com (8.11.4/8.11.4) with ESMTP id f9Q2bt110011 for ; Thu, 25 Oct 2001 19:37:55 -0700 (PDT) Received: from larrypad ([130.248.188.133]) by mailsj-v1.corp.adobe.com (Netscape Messaging Server 4.15 v1 Jul 11 2001 16:32:57) with SMTP id GLSKO900.RHB; Thu, 25 Oct 2001 19:38:33 -0700 From: "Larry Masinter" To: "Jason Crawford" Cc: Date: Thu, 25 Oct 2001 19:37:56 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Subject: RE: I command you to support Digest!!! Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5468 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Jason Crawford asked: > Are you expressing a preference for any particular approach with your > posting below? I'm trying to give some guidance about the basic rules of standards making in the IETF: a) the standard should assure interoperability b) the standard should require implementation of security adequate for its stated purpose c) standards should avoid requiring implementation of patented technologies For WebDAV, the stated purpose is "web distributed authoring". Other uses, like for software configuration management or accessing exchange mailboxes, are fine, but they're not the stated purpose. Saying "authentication must be used" doesn't assure interoperability, because the clients might not implement the authentication mechanism that the server requires. Requiring that "the authentication method used must not have passwords in the clear" doesn't help. I think what RFC 2518 says is that WebDAV clients must USE digest authentication for authentication. (a) means that if you have a compliant client and a compliant server, they should work together. Letting servers implement basic with SSL only without requiring clients to implement basic with SSL means you wouldn't have interoperability. Requiring clients to implement SSL means (I think) that you're requiring them to implement patented technology. Not requiring any security means that you break (b). > If not, what would you suggest that the spec say? (Feel free > to post to the list and guide the resolution of this.) I think RFC 2518's "MUST support digest" meets the criteria above, especially if you interpret "support" to mean "actually use as an access authentication method". I suggest that the spec stay as it is in RFC 2518 unless you can come up with something that everyone agrees (1) it's better, and (2) it also meets the criteria. > Also, do you know if the powers that be would accept us either saying > nothing beyond the fact that authentication should be used? No, because of (a); it doesn't guarantee interoperability > If not, would > they accept it if we additionally specify that the authentication schemes > used avoid sending privledged info in the clear? It still doesn't guarantee interoperability. From w3c-dist-auth-request@w3.org Fri Oct 26 13:06:50 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11244 for ; Fri, 26 Oct 2001 13:06:49 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA00354; Fri, 26 Oct 2001 12:56:59 -0400 (EDT) Resent-Date: Fri, 26 Oct 2001 12:56:59 -0400 (EDT) Resent-Message-Id: <200110261656.MAA00354@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id MAA00334 for ; Fri, 26 Oct 2001 12:56:52 -0400 (EDT) Received: from mail0.rawbw.com (mail0.rawbw.com [198.144.192.41]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id MAA19046 for ; Fri, 26 Oct 2001 12:56:52 -0400 Received: from beaver ([198.144.203.248]) by mail0.rawbw.com (8.11.3/8.11.3) with SMTP id f9QGuWA62894; Fri, 26 Oct 2001 09:56:32 -0700 (PDT) (envelope-from lisa@xythos.com) From: "Lisa Dusseault" To: "Larry Masinter" , "Jason Crawford" Cc: Date: Fri, 26 Oct 2001 09:55:48 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: Importance: Normal Subject: RE: I command you to support Digest!!! Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5469 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > I think what RFC 2518 says is that WebDAV clients > must USE digest authentication for authentication. Currently it says "WebDAV applications MUST support the Digest authentication scheme". Yours might be a nice clarification (is an application a client, a server or both?), but we'd have to say something about servers as well. > (a) means that if you have a compliant client and > a compliant server, they should work together. > Letting servers implement basic with SSL only > without requiring clients to implement basic > with SSL means you wouldn't have interoperability. > Requiring clients to implement SSL means (I think) > that you're requiring them to implement patented > technology. What patented technology are you talking about? In practice, SSL requires RSA, but the patent has expired. There are also plenty of unpatented symmetric algorithms usable with SSL. It's true that SSL is patented itself by Netscape but they've released it for royalty-free use (see rfc2246 appendix G.) Is there still an issue with that? Aside from the patent issues, we might consider whether it's now reasonable to require WebDAV clients to support SSL. I agree that it's too weak to say nothing or to say "authentication must be supported"; for the reasons Larry outlines we need to specify which mechanisms. lisa From w3c-dist-auth-request@w3.org Fri Oct 26 13:17:41 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11571 for ; Fri, 26 Oct 2001 13:17:41 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA01924; Fri, 26 Oct 2001 13:10:23 -0400 (EDT) Resent-Date: Fri, 26 Oct 2001 13:10:23 -0400 (EDT) Resent-Message-Id: <200110261710.NAA01924@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id NAA01904 for ; Fri, 26 Oct 2001 13:10:11 -0400 (EDT) Received: from cats.ucsc.edu (rumpleteazer.ucsc.edu [128.114.129.45]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id NAA21009 for ; Fri, 26 Oct 2001 13:10:11 -0400 Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177]) by cats.ucsc.edu (8.9.3/8.8.4.cats-athena) with SMTP id KAA18551 for ; Fri, 26 Oct 2001 10:11:52 -0700 (PDT) From: "Jim Whitehead" To: "WebDAV" Date: Fri, 26 Oct 2001 10:06:16 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: FW: [Moderator Action] cnonce computing ? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5470 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Accidentally caught by the spam filter. I have added Patrick's email address to the accept2 list, so future email from him will not get caught. - Jim -----Original Message----- From: patrick.mourot@online.fr [mailto:patrick.mourot@online.fr] Sent: Friday, October 26, 2001 5:09 AM To: w3c-dist-auth@w3.org Subject: [Moderator Action] cnonce computing ? Sir I'm a bit confused with cnonce in Computing hash values for authentication. RFC 2617 (Basic and Digest Access Authentication), 3.2.2 The Authorization Request Header [...] cnonce This MUST be specified if a qop directive is sent (see above), and MUST NOT be specified if the server did not send a qop directive in the WWW-Authenticate header field. [...] 3.2.2.1 Request-Digest [...] If the "qop" directive is not present (this construction is for compatibility with RFC 2069): request-digest = <"> < KD ( H(A1), unq(nonce-value) ":" H(A2) ) > <"> See below for the definitions for A1 and A2. 3.2.2.2 A1 [...] If the "algorithm" directive's value is "MD5-sess", then A1 is calculated only once - on the first request by the client following receipt of a WWW-Authenticate challenge from the server. It uses the server nonce from that challenge, and the first client nonce value to construct A1 as follows: A1 = H( unq(username-value) ":" unq(realm-value) ":" passwd ) ":" unq(nonce-value) ":" unq(cnonce-value) ^^^^^^^^^^^ If we have no qop and "algorithm" as "MD5-sess", what is cnonce-value since we don't have a cnonce ? Does it happen ? TIA Patrick From w3c-dist-auth-request@w3.org Fri Oct 26 14:53:15 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15430 for ; Fri, 26 Oct 2001 14:53:15 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA16441; Fri, 26 Oct 2001 14:49:48 -0400 (EDT) Resent-Date: Fri, 26 Oct 2001 14:49:48 -0400 (EDT) Resent-Message-Id: <200110261849.OAA16441@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id OAA16414 for ; Fri, 26 Oct 2001 14:49:42 -0400 (EDT) Received: from cats.ucsc.edu (rumpleteazer.ucsc.edu [128.114.129.45]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id OAA03000 for ; Fri, 26 Oct 2001 14:49:42 -0400 Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177]) by cats.ucsc.edu (8.9.3/8.8.4.cats-athena) with SMTP id LAA18497 for ; Fri, 26 Oct 2001 11:51:24 -0700 (PDT) From: "Jim Whitehead" To: "WebDAV" Date: Fri, 26 Oct 2001 11:45:47 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: Metadata Interoperability for Electronic Records Management Workshop Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5471 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit I'm organzing the following workshop on the topic of how best to achieve interoperability of metadata among eletronic records management (ERM) systems, especially government ERM systems. Members of the WebDAV community are welcome to attend. I believe this topic is of crucial importance to enabling the freedom of government records. If a standard mechanism for representing electronic records management metadata in XML could be developed, it would allow WebDAV properties to record this metadata. This, in turn, would allow government agencies to use a DAV server to control the entire lifecycle of their documents, from the initial point of authorship to its archiving and perhaps destruction (according to a records disposition plan). While important for government electronic records management, these capabilities are important for a wide range of document management scenarios, and the existence of interoperable ERM metadata will dramatically increase the value of WebDAV servers in many document management scenarios. An ERM schema increases the freedom of records by making it much easier for government agencies to process public requests for their records. In the US, a standard mechanism is a Freedom of Information Act (FOIA) request -- this metadata will make it much easier to process these requests. As well, it opens the possibility that agencies could regularly open up a many of their records for public review, since these processes could be increasingly automated with better metadata support. For background reading, the 5015.2 standard can be found here: http://jitc.fhu.disa.mil/recmgt/ Details on the workshop follow: Workshop on Metadata Interoperability for Electronic Records Management Date: November 15, 2001, 1-5PM Location: National Archives Building, College Park, Maryland, Lecture Room E Directions: http://www.nara.gov/nara/dc/Archives2_directions.html. Description: As governments, businesses, and organizations around the world increasingly convert their information flows from paper-based to digital, there is an increasing need for electronic records management. In the United States, the functionality standard, DoD 5015.2, "Design Criteria Standard for Electronic Records Management Software Applications" provides a detailed specification of the capabilities required of document management systems to meet government electronic records management needs. DoD 5015.2 is used by the DISA Joint Interoperability Test Command (JITC) to perform certification testing to ensure that systems can meet the requirements stated in the standard. DoD 5015.2 lists numerous metadata items, covering such issues as content disposition, bibliographic metadata, formatting, email-specific metadata, and others. While 5015.2 provides a detailed description of the semantics of each metadata item, it does not describe the format of their contents. As a result, even if two document management systems both meet the 5015.2 standard, there is no guarantee that values from one system can be easily transferred or compared with another. Since 5015.2 only specifies functionality, it is not a solid foundation for interoperability among electronic records management systems. The purpose of this workshop is to begin efforts to create an interoperability standard for electronic records management metadata. Topics for discussion at the workshop include: * What is the scope of the effort? - Just 5015.2 metadata items, or is other standardization necessary? - What are the specific requirements? * Which standards development organization should host the effort? - OASIS, NARA, NIST, ANSI, AIIM :: what are pros/cons of each? * What technologies should be employed? - XML, RDF * How to coordinate with efforts in Australia, UK, and elsewhere? - Do we gain any traction by making this an international effort? * How does this effort interact with existing technologies? - GILS/Z39.50, WebDAV, DASL * Who will lead the effort? Who will participate? - Will this be an open or closed project? If you are planning on attending, please send an email to Jim Whitehead . There is no charge to attend this event. From w3c-dist-auth-request@w3.org Sat Oct 27 16:28:30 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16374 for ; Sat, 27 Oct 2001 16:28:29 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA15507; Sat, 27 Oct 2001 16:24:17 -0400 (EDT) Resent-Date: Sat, 27 Oct 2001 16:24:17 -0400 (EDT) Resent-Message-Id: <200110272024.QAA15507@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id QAA15483 for ; Sat, 27 Oct 2001 16:24:12 -0400 (EDT) Received: from smtp1.Stanford.EDU (smtp1.Stanford.EDU [171.64.14.23]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id QAA28621 for ; Sat, 27 Oct 2001 16:24:12 -0400 Received: from burrito.Stanford.EDU (burrito.Stanford.EDU [128.12.60.117]) by smtp1.Stanford.EDU (8.11.1/8.11.3) with ESMTP id f9RKO8k22128 for ; Sat, 27 Oct 2001 13:24:09 -0700 (PDT) From: Keith Ito To: Webdav WG Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.15 (Preview Release) Date: 27 Oct 2001 13:24:13 -0700 Message-Id: <1004214255.2669.1594.camel@burrito> Mime-Version: 1.0 Subject: webdav ticket draft Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5472 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit I've written a draft on incorporating tickets into WebDAV. Tickets are a means of transferring access privileges through the use of a token presented by a client when requesting a file. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ito-dav-ticket-00.txt At Xythos, we're implementing tickets so that a WebDAV client can offer an "email a link" option on an access-controlled WebDAV resource - the client could request a ticket for the file from the server and then attach it to a URL which can be sent to another user. However, tickets can be used for a number of other purposes as well. Please let me know if there is any interest in pursuing the standardization of tickets. -- Keith From w3c-dist-auth-request@w3.org Mon Oct 29 12:11:58 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20217 for ; Mon, 29 Oct 2001 12:11:58 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA15578; Mon, 29 Oct 2001 12:08:57 -0500 (EST) Resent-Date: Mon, 29 Oct 2001 12:08:57 -0500 (EST) Resent-Message-Id: <200110291708.MAA15578@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id MAA15522 for ; Mon, 29 Oct 2001 12:08:49 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id MAA20205 for ; Mon, 29 Oct 2001 12:08:48 -0500 Received: (qmail 31789 invoked by uid 0); 29 Oct 2001 17:08:17 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mp011-rz3) with SMTP; 29 Oct 2001 17:08:17 -0000 From: "Julian Reschke" To: "Webdav WG" , Date: Mon, 29 Oct 2001 18:09:03 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: Importance: Normal Subject: RE: Content-Type / charset in RFC2518, deltaV and ACL specs Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5473 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi, a related discussion is going on in xml-dev right now [1]. It seems to me it would be wise if WebDAV and related specs would switch to use a content type of application/xml -- at least both server and client implementors should be advised to accept both. Julian [1] From w3c-dist-auth-request@w3.org Mon Oct 29 15:22:01 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25954 for ; Mon, 29 Oct 2001 15:22:00 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA29597; Mon, 29 Oct 2001 15:18:25 -0500 (EST) Resent-Date: Mon, 29 Oct 2001 15:18:25 -0500 (EST) Resent-Message-Id: <200110292018.PAA29597@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id PAA29528 for ; Mon, 29 Oct 2001 15:18:12 -0500 (EST) Received: from cats.ucsc.edu (rumpleteazer.ucsc.edu [128.114.129.45]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id PAA12801 for ; Mon, 29 Oct 2001 15:18:08 -0500 Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177]) by cats.ucsc.edu (8.9.3/8.8.4.cats-athena) with SMTP id MAA03303 for ; Mon, 29 Oct 2001 12:20:19 -0800 (PST) From: "Jim Whitehead" To: "WebDAV" Date: Mon, 29 Oct 2001 12:14:10 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: Ideas: GETSRC & MULTIPUT Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5474 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit I'm interested in the list's thoughts on two ideas for DAV improvements: The first is to introduce a GETSRC method to support access to the unprocessed source of a resource. This would decouple the dynamic response of a resource (GET) from its static source (GETSRC). The second is to introduce the MULTIPUT method to support "PUT with PROPPATCH" scenarios. MULTIPUT would accept some subset of multipart MIME packages and atomically write them to the server. This would support the update of a resource and its metadata in one transaction. - Jim From w3c-dist-auth-request@w3.org Mon Oct 29 15:52:51 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26487 for ; Mon, 29 Oct 2001 15:52:51 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA01226; Mon, 29 Oct 2001 15:50:31 -0500 (EST) Resent-Date: Mon, 29 Oct 2001 15:50:31 -0500 (EST) Resent-Message-Id: <200110292050.PAA01226@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id PAA01185 for ; Mon, 29 Oct 2001 15:50:24 -0500 (EST) Received: from adobe.com (smtp-relay-1.adobe.com [192.150.11.1]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id PAA16947 for ; Mon, 29 Oct 2001 15:50:24 -0500 Received: from inner-relay-2.corp.adobe.com ([153.32.1.52]) by adobe.com (1.0.0/8.11.4) with ESMTP id f9TKolL12038 for ; Mon, 29 Oct 2001 12:50:47 -0800 (PST) Received: from mail-hamburg.eur.adobe.com (mail-hamburg [130.248.122.254]) by inner-relay-2.corp.adobe.com (8.11.4/8.11.4) with ESMTP id f9TKn6121657 for ; Mon, 29 Oct 2001 12:49:07 -0800 (PST) Received: from maileurope-ham.eur.adobe.com (maileurope-ham [130.248.122.251]) by mail-hamburg.eur.adobe.com (8.11.4/8.11.4) with ESMTP id f9TKniI01795 for ; Mon, 29 Oct 2001 21:49:45 +0100 (MET) Received: from adobe.com ([130.248.122.95]) by maileurope-ham.eur.adobe.com (Netscape Messaging Server 4.15 ham Jul 11 2001 16:32:57) with ESMTP id GLZJ6V00.AI6; Mon, 29 Oct 2001 21:49:43 +0100 Message-ID: <3BDDC0E6.7D6BA9E9@adobe.com> Date: Mon, 29 Oct 2001 21:49:42 +0100 From: Hartmut Warncke X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Jim Whitehead CC: WebDAV References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: Ideas: GETSRC & MULTIPUT Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5475 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Jim, a great idea, to my mind especially something like the GETSRC mechanism is needed, Best, Hartmut Jim Whitehead wrote: > I'm interested in the list's thoughts on two ideas for DAV improvements: > > The first is to introduce a GETSRC method to support access to the > unprocessed source of a resource. This would decouple the dynamic response > of a resource (GET) from its static source (GETSRC). > > The second is to introduce the MULTIPUT method to support "PUT with > PROPPATCH" scenarios. MULTIPUT would accept some subset of multipart MIME > packages and atomically write them to the server. This would support the > update of a resource and its metadata in one transaction. > > - Jim From w3c-dist-auth-request@w3.org Mon Oct 29 15:55:29 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26664 for ; Mon, 29 Oct 2001 15:55:29 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA01343; Mon, 29 Oct 2001 15:53:53 -0500 (EST) Resent-Date: Mon, 29 Oct 2001 15:53:53 -0500 (EST) Resent-Message-Id: <200110292053.PAA01343@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id PAA01323 for ; Mon, 29 Oct 2001 15:53:47 -0500 (EST) Received: from inet-mail4.oracle.com (inet-mail4.oracle.com [148.87.2.204]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id PAA17331 for ; Mon, 29 Oct 2001 15:53:47 -0500 Received: from rgmgw6.us.oracle.com (rgmgw6.us.oracle.com [138.1.191.15]) by inet-mail4.oracle.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f9TKjXF13146; Mon, 29 Oct 2001 12:45:33 -0800 (PST) Received: from esedlarpc (esedlar-pc-xdsl.us.oracle.com [152.68.17.154]) by rgmgw6.us.oracle.com (Switch-2.1.3/Switch-2.1.0) with SMTP id f9TKrjj02740; Mon, 29 Oct 2001 13:53:45 -0700 (MST) From: "Eric Sedlar" To: "Jim Whitehead" , "WebDAV" Date: Mon, 29 Oct 2001 12:57:42 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal In-Reply-To: Subject: RE: Ideas: GETSRC & MULTIPUT Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5476 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit You should probably include the ACL method in the MULTIPUT. These sound like good ideas, Jim. > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jim Whitehead > Sent: Monday, October 29, 2001 12:14 PM > To: WebDAV > Subject: Ideas: GETSRC & MULTIPUT > > > I'm interested in the list's thoughts on two ideas for DAV improvements: > > The first is to introduce a GETSRC method to support access to the > unprocessed source of a resource. This would decouple the dynamic response > of a resource (GET) from its static source (GETSRC). > > The second is to introduce the MULTIPUT method to support "PUT with > PROPPATCH" scenarios. MULTIPUT would accept some subset of multipart MIME > packages and atomically write them to the server. This would support the > update of a resource and its metadata in one transaction. > > - Jim > > From w3c-dist-auth-request@w3.org Mon Oct 29 15:56:14 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26689 for ; Mon, 29 Oct 2001 15:56:13 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA01417; Mon, 29 Oct 2001 15:54:28 -0500 (EST) Resent-Date: Mon, 29 Oct 2001 15:54:28 -0500 (EST) Resent-Message-Id: <200110292054.PAA01417@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id PAA01391 for ; Mon, 29 Oct 2001 15:54:19 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id PAA17462 for ; Mon, 29 Oct 2001 15:54:19 -0500 Received: (qmail 1986 invoked by uid 0); 29 Oct 2001 20:53:47 -0000 Received: from pd9535140.dip.t-dialin.net (HELO lisa) (217.83.81.64) by mail.gmx.net (mp003-rz3) with SMTP; 29 Oct 2001 20:53:47 -0000 From: "Julian Reschke" To: "Jim Whitehead" , "WebDAV" Date: Mon, 29 Oct 2001 21:54:34 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Subject: RE: Ideas: GETSRC & MULTIPUT Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5477 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jim Whitehead > Sent: Monday, October 29, 2001 9:14 PM > To: WebDAV > Subject: Ideas: GETSRC & MULTIPUT > > > I'm interested in the list's thoughts on two ideas for DAV improvements: Jim, I think both address real-world needs, and non-proprietary solutions would be welcome. > The first is to introduce a GETSRC method to support access to the > unprocessed source of a resource. This would decouple the dynamic response > of a resource (GET) from its static source (GETSRC). Yes. This could replace Microsoft's "Translate" header. However, it would also need to address which set of live properties (src or dynamic) PROPFIND is supposed to report. See also the discussion in [1]. > The second is to introduce the MULTIPUT method to support "PUT with > PROPPATCH" scenarios. MULTIPUT would accept some subset of multipart MIME > packages and atomically write them to the server. This would support the > update of a resource and its metadata in one transaction. Sounds good. [1] From w3c-dist-auth-request@w3.org Mon Oct 29 16:20:12 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27302 for ; Mon, 29 Oct 2001 16:20:11 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA02602; Mon, 29 Oct 2001 16:18:28 -0500 (EST) Resent-Date: Mon, 29 Oct 2001 16:18:28 -0500 (EST) Resent-Message-Id: <200110292118.QAA02602@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id QAA02577 for ; Mon, 29 Oct 2001 16:18:23 -0500 (EST) Received: from sus-ma1it00.rational.com (ext-37184.rational.com [192.229.37.184]) by tux.w3.org (8.9.3/8.9.3) with SMTP id QAA20181 for ; Mon, 29 Oct 2001 16:18:23 -0500 Received: from 192.168.215.70 by sus-ma1it00.rational.com (InterScan E-Mail VirusWall NT); Mon, 29 Oct 2001 16:17:48 -0500 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id <4D31HFXD>; Mon, 29 Oct 2001 16:17:48 -0500 Message-ID: <3906C56A7BD1F54593344C05BD1374B103F8AD0E@SUS-MA1IT01> From: "Clemm, Geoff" To: WebDAV Date: Mon, 29 Oct 2001 16:17:46 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Ideas: GETSRC & MULTIPUT Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5478 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Why isn't GETSRC just a GET on the DAV:dst of the DAV:source property? (If it is just a shorthand for this, I'm against the redundant marshalling of this request through a new method). As for MULTIPUT, that sounds fine to me, but it should be accompanied by a MULTIGET, which would allow reading of a resource and its metadata in one transaction. Cheers, Geoff -----Original Message----- From: Jim Whitehead [mailto:ejw@cse.ucsc.edu] Sent: Monday, October 29, 2001 3:14 PM To: WebDAV Subject: Ideas: GETSRC & MULTIPUT I'm interested in the list's thoughts on two ideas for DAV improvements: The first is to introduce a GETSRC method to support access to the unprocessed source of a resource. This would decouple the dynamic response of a resource (GET) from its static source (GETSRC). The second is to introduce the MULTIPUT method to support "PUT with PROPPATCH" scenarios. MULTIPUT would accept some subset of multipart MIME packages and atomically write them to the server. This would support the update of a resource and its metadata in one transaction. - Jim From w3c-dist-auth-request@w3.org Mon Oct 29 16:36:44 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27783 for ; Mon, 29 Oct 2001 16:36:43 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA03177; Mon, 29 Oct 2001 16:35:08 -0500 (EST) Resent-Date: Mon, 29 Oct 2001 16:35:08 -0500 (EST) Resent-Message-Id: <200110292135.QAA03177@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id QAA03150 for ; Mon, 29 Oct 2001 16:35:03 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id QAA22041 for ; Mon, 29 Oct 2001 16:35:02 -0500 Received: (qmail 5875 invoked by uid 0); 29 Oct 2001 21:34:31 -0000 Received: from pd9535140.dip.t-dialin.net (HELO lisa) (217.83.81.64) by mail.gmx.net (mp001-rz3) with SMTP; 29 Oct 2001 21:34:31 -0000 From: "Julian Reschke" To: "Clemm, Geoff" , "WebDAV" Date: Mon, 29 Oct 2001 22:35:18 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <3906C56A7BD1F54593344C05BD1374B103F8AD0E@SUS-MA1IT01> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Subject: RE: Ideas: GETSRC & MULTIPUT Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5479 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Geoff, I'd like to see how the DAV:dst in WebDAV can support what Microsoft is doing with their Translate header (namely, having the source and the dynamic content at the same URL). See also my comments in Julian > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff > Sent: Monday, October 29, 2001 10:18 PM > To: WebDAV > Subject: RE: Ideas: GETSRC & MULTIPUT > > > Why isn't GETSRC just a GET on the DAV:dst of the DAV:source property? > (If it is just a shorthand for this, I'm against the redundant marshalling > of this request through a new method). > > As for MULTIPUT, that sounds fine to me, but it should be accompanied by > a MULTIGET, which would allow reading of a resource and its metadata in > one transaction. > > Cheers, > Geoff > > -----Original Message----- > From: Jim Whitehead [mailto:ejw@cse.ucsc.edu] > Sent: Monday, October 29, 2001 3:14 PM > To: WebDAV > Subject: Ideas: GETSRC & MULTIPUT > > > I'm interested in the list's thoughts on two ideas for DAV improvements: > > The first is to introduce a GETSRC method to support access to the > unprocessed source of a resource. This would decouple the dynamic response > of a resource (GET) from its static source (GETSRC). > > The second is to introduce the MULTIPUT method to support "PUT with > PROPPATCH" scenarios. MULTIPUT would accept some subset of multipart MIME > packages and atomically write them to the server. This would support the > update of a resource and its metadata in one transaction. > > - Jim > From w3c-dist-auth-request@w3.org Mon Oct 29 16:58:16 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28502 for ; Mon, 29 Oct 2001 16:58:16 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA04558; Mon, 29 Oct 2001 16:55:52 -0500 (EST) Resent-Date: Mon, 29 Oct 2001 16:55:52 -0500 (EST) Resent-Message-Id: <200110292155.QAA04558@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id QAA04538 for ; Mon, 29 Oct 2001 16:55:42 -0500 (EST) Received: from sus-ma1it00.rational.com (ext-37184.rational.com [192.229.37.184]) by tux.w3.org (8.9.3/8.9.3) with SMTP id QAA24479 for ; Mon, 29 Oct 2001 16:55:42 -0500 Received: from 192.168.215.70 by sus-ma1it00.rational.com (InterScan E-Mail VirusWall NT); Mon, 29 Oct 2001 16:55:11 -0500 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id <4D31HJC3>; Mon, 29 Oct 2001 16:55:11 -0500 Message-ID: <3906C56A7BD1F54593344C05BD1374B103F8AD10@SUS-MA1IT01> From: "Clemm, Geoff" To: WebDAV Date: Mon, 29 Oct 2001 16:55:09 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Ideas: GETSRC & MULTIPUT Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5480 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: In general, I believe having distinct URL's for different resources is far superior to defining new methods. How would you set access control on the "source" resource? How would you get the properties of the "source" resource? If you have a URL for the source resource, all this is straightforward ... but if you have something like a GETSRC method, the only thing you can do with the "source" is get its content. Cheers, Geoff -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de] Sent: Monday, October 29, 2001 4:35 PM To: Clemm, Geoff; WebDAV Subject: RE: Ideas: GETSRC & MULTIPUT Geoff, I'd like to see how the DAV:dst in WebDAV can support what Microsoft is doing with their Translate header (namely, having the source and the dynamic content at the same URL). See also my comments in Julian > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff > Sent: Monday, October 29, 2001 10:18 PM > To: WebDAV > Subject: RE: Ideas: GETSRC & MULTIPUT > > > Why isn't GETSRC just a GET on the DAV:dst of the DAV:source property? > (If it is just a shorthand for this, I'm against the redundant marshalling > of this request through a new method). > > As for MULTIPUT, that sounds fine to me, but it should be accompanied by > a MULTIGET, which would allow reading of a resource and its metadata in > one transaction. > > Cheers, > Geoff > > -----Original Message----- > From: Jim Whitehead [mailto:ejw@cse.ucsc.edu] > Sent: Monday, October 29, 2001 3:14 PM > To: WebDAV > Subject: Ideas: GETSRC & MULTIPUT > > > I'm interested in the list's thoughts on two ideas for DAV improvements: > > The first is to introduce a GETSRC method to support access to the > unprocessed source of a resource. This would decouple the dynamic response > of a resource (GET) from its static source (GETSRC). > > The second is to introduce the MULTIPUT method to support "PUT with > PROPPATCH" scenarios. MULTIPUT would accept some subset of multipart MIME > packages and atomically write them to the server. This would support the > update of a resource and its metadata in one transaction. > > - Jim > From w3c-dist-auth-request@w3.org Mon Oct 29 17:05:01 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28767 for ; Mon, 29 Oct 2001 17:05:00 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA05193; Mon, 29 Oct 2001 17:03:21 -0500 (EST) Resent-Date: Mon, 29 Oct 2001 17:03:21 -0500 (EST) Resent-Message-Id: <200110292203.RAA05193@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id RAA05166 for ; Mon, 29 Oct 2001 17:03:12 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id RAA25217 for ; Mon, 29 Oct 2001 17:03:11 -0500 Received: (qmail 18345 invoked by uid 0); 29 Oct 2001 22:02:40 -0000 Received: from pd9535140.dip.t-dialin.net (HELO lisa) (217.83.81.64) by mail.gmx.net (mp003-rz3) with SMTP; 29 Oct 2001 22:02:40 -0000 From: "Julian Reschke" To: "Clemm, Geoff" , "WebDAV" Date: Mon, 29 Oct 2001 23:03:27 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <3906C56A7BD1F54593344C05BD1374B103F8AD10@SUS-MA1IT01> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Subject: RE: Ideas: GETSRC & MULTIPUT Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5481 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Well. There's RFC2518, and there's what Microsoft does. Has anybody actually *implemented* RFC2518 this way? I haven't seen any implementation, so I guess it's at a minimum underspecified or nor particulary well explained... Julian > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff > Sent: Monday, October 29, 2001 10:55 PM > To: WebDAV > Subject: RE: Ideas: GETSRC & MULTIPUT > > > In general, I believe having distinct URL's for different resources > is far superior to defining new methods. How would you set access > control on the "source" resource? How would you get the properties of > the "source" resource? If you have a URL for the source resource, > all this is straightforward ... but if you have something like a GETSRC > method, the only thing you can do with the "source" is get its content. > > Cheers, > Geoff > > -----Original Message----- > From: Julian Reschke [mailto:julian.reschke@gmx.de] > Sent: Monday, October 29, 2001 4:35 PM > To: Clemm, Geoff; WebDAV > Subject: RE: Ideas: GETSRC & MULTIPUT > > > Geoff, > > I'd like to see how the DAV:dst in WebDAV can support what Microsoft is > doing with their Translate header (namely, having the source and > the dynamic > content at the same URL). > > See also my comments in > > > > Julian > > > -----Original Message----- > > From: w3c-dist-auth-request@w3.org > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff > > Sent: Monday, October 29, 2001 10:18 PM > > To: WebDAV > > Subject: RE: Ideas: GETSRC & MULTIPUT > > > > > > Why isn't GETSRC just a GET on the DAV:dst of the DAV:source property? > > (If it is just a shorthand for this, I'm against the redundant > marshalling > > of this request through a new method). > > > > As for MULTIPUT, that sounds fine to me, but it should be accompanied by > > a MULTIGET, which would allow reading of a resource and its metadata in > > one transaction. > > > > Cheers, > > Geoff > > > > -----Original Message----- > > From: Jim Whitehead [mailto:ejw@cse.ucsc.edu] > > Sent: Monday, October 29, 2001 3:14 PM > > To: WebDAV > > Subject: Ideas: GETSRC & MULTIPUT > > > > > > I'm interested in the list's thoughts on two ideas for DAV improvements: > > > > The first is to introduce a GETSRC method to support access to the > > unprocessed source of a resource. This would decouple the > dynamic response > > of a resource (GET) from its static source (GETSRC). > > > > The second is to introduce the MULTIPUT method to support "PUT with > > PROPPATCH" scenarios. MULTIPUT would accept some subset of > multipart MIME > > packages and atomically write them to the server. This would support the > > update of a resource and its metadata in one transaction. > > > > - Jim > > > From w3c-dist-auth-request@w3.org Mon Oct 29 17:29:46 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29407 for ; Mon, 29 Oct 2001 17:29:46 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA08217; Mon, 29 Oct 2001 17:28:03 -0500 (EST) Resent-Date: Mon, 29 Oct 2001 17:28:03 -0500 (EST) Resent-Message-Id: <200110292228.RAA08217@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id RAA08194 for ; Mon, 29 Oct 2001 17:27:56 -0500 (EST) Received: from mutley.ebuilt.net (nat.ebuilt.com [209.216.46.200]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id RAA27757 for ; Mon, 29 Oct 2001 17:27:57 -0500 Received: (from root@localhost) by mutley.ebuilt.net (8.11.1/8.11.1) id f9TMRFL27853 for ; Mon, 29 Oct 2001 14:27:15 -0800 Received: from waka.ebuilt.net (IDENT:root@i199.ir.ebuilt.net [10.1.2.199]) by mutley.ebuilt.net (8.11.1/8.11.1) with ESMTP id f9TMRFO27772; Mon, 29 Oct 2001 14:27:15 -0800 Received: (from fielding@localhost) by waka.ebuilt.net (8.11.0/8.11.0) id f9TMPK008373; Mon, 29 Oct 2001 14:25:20 -0800 Date: Mon, 29 Oct 2001 14:25:20 -0800 From: "Roy T. Fielding" To: Jim Whitehead Cc: WebDAV Message-ID: <20011029142520.D8295@waka.ebuilt.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.20i X-AntiVirus: scanned for viruses by AMaViS 0.2.1-pre3 (http://amavis.org/) Subject: Re: Ideas: GETSRC & MULTIPUT Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5482 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: On Mon, Oct 29, 2001 at 12:14:10PM -0800, Jim Whitehead wrote: > I'm interested in the list's thoughts on two ideas for DAV improvements: > > The first is to introduce a GETSRC method to support access to the > unprocessed source of a resource. This would decouple the dynamic response > of a resource (GET) from its static source (GETSRC). That would, of course, be completely contrary to the HTTP design and further propagate the mistake of not accessing properties as resources. Just use the source link. > The second is to introduce the MULTIPUT method to support "PUT with > PROPPATCH" scenarios. MULTIPUT would accept some subset of multipart MIME > packages and atomically write them to the server. This would support the > update of a resource and its metadata in one transaction. Please choose a better name -- MPUT and MULTIPUT means multiple PUT requests, which was already tried and abandoned. Maybe you can call it PKG. Or just define a mapping to transactions and leave them as separate requests. ....Roy From w3c-dist-auth-request@w3.org Mon Oct 29 19:09:58 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00632 for ; Mon, 29 Oct 2001 19:09:58 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id TAA13776; Mon, 29 Oct 2001 19:07:46 -0500 (EST) Resent-Date: Mon, 29 Oct 2001 19:07:46 -0500 (EST) Resent-Message-Id: <200110300007.TAA13776@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id TAA13756 for ; Mon, 29 Oct 2001 19:07:39 -0500 (EST) Received: from cats.ucsc.edu (rumpleteazer.ucsc.edu [128.114.129.45]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id TAA06145 for ; Mon, 29 Oct 2001 19:07:39 -0500 Received: from Tycho (dhcp-55-194.cse.ucsc.edu [128.114.55.194]) by cats.ucsc.edu (8.9.3/8.8.4.cats-athena) with SMTP id QAA12098; Mon, 29 Oct 2001 16:09:08 -0800 (PST) From: "Jim Whitehead" To: "Roy T. Fielding" Cc: "WebDAV" Date: Mon, 29 Oct 2001 16:02:57 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <20011029142520.D8295@waka.ebuilt.net> Subject: RE: Ideas: GETSRC & MULTIPUT Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5483 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Roy, > That would, of course, be completely contrary to the HTTP design and > further propagate the mistake of not accessing properties as resources. > Just use the source link. The source link didn't work. Telling people to use the source link is not, IMO, productive. GETSRC could be defined as something like, "returns to the client a representation of the resource suitable for editing in an authoring client", so we avoid issues of getting at the "true" state of the resource. GETSRC wouldn't have the same caching properties as GET; I don't see that as being a big problem for authoring. So, which specific HTTP design principle(s) does this proposal violate? > > The second is to introduce the MULTIPUT method to support "PUT with > > PROPPATCH" scenarios. MULTIPUT would accept some subset of > multipart MIME > > packages and atomically write them to the server. This would support the > > update of a resource and its metadata in one transaction. > > Please choose a better name -- MPUT and MULTIPUT means multiple > PUT requests, which was already tried and abandoned. Maybe you can call it > PKG. Or just define a mapping to transactions and leave them as separate > requests. I don't want to do arbitrary transactions, since that dramatically increases the implementation burden. But I'd be happy to call it something different. - Jim From w3c-dist-auth-request@w3.org Mon Oct 29 19:16:15 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00710 for ; Mon, 29 Oct 2001 19:16:15 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id TAA13987; Mon, 29 Oct 2001 19:14:48 -0500 (EST) Resent-Date: Mon, 29 Oct 2001 19:14:48 -0500 (EST) Resent-Message-Id: <200110300014.TAA13987@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id TAA13962 for ; Mon, 29 Oct 2001 19:14:40 -0500 (EST) Received: from cats.ucsc.edu (rumpleteazer.ucsc.edu [128.114.129.45]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id TAA06686 for ; Mon, 29 Oct 2001 19:14:35 -0500 Received: from Tycho (dhcp-55-194.cse.ucsc.edu [128.114.55.194]) by cats.ucsc.edu (8.9.3/8.8.4.cats-athena) with SMTP id QAA14092; Mon, 29 Oct 2001 16:16:46 -0800 (PST) From: "Jim Whitehead" To: "Clemm, Geoff" , "WebDAV" Date: Mon, 29 Oct 2001 16:10:35 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <3906C56A7BD1F54593344C05BD1374B103F8AD0E@SUS-MA1IT01> Subject: RE: Ideas: GETSRC & MULTIPUT Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5484 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > Why isn't GETSRC just a GET on the DAV:dst of the DAV:source property? > (If it is just a shorthand for this, I'm against the redundant marshalling > of this request through a new method). The source link has not been implemented. We don't currently have two interoperable implementations. Thus, according to IETF policy, the source link goes away in the revision of 2518. At that point, we have no mechanism for accessing the unprocessed source of a link. Hence, no duplication of mechanism. Being a pragmatist, the source link hasn't worked. To me, this suggests a different approach. I like a new method better than the Translate header, since we're really asking for a different aspect of the state of the resource than a GET. > As for MULTIPUT, that sounds fine to me, but it should be accompanied by > a MULTIGET, which would allow reading of a resource and its metadata in > one transaction. I think the case for MULTIGET is much weaker. A client cannot easily implement a PUT/PROPPATCH transaction with existing methods. If one of the two methods fails, it's hard for the client to rollback. That is, MULTIPUT/MPUT/PKG is not a network optimization -- it's accomplishing something that is difficult, if not impossible, for a client to do right now. But, if a client does a LOCK (exclusive), GET, PROPFIND, it is guaranteed to get the properties that are consistent with the body of the resource. - Jim From w3c-dist-auth-request@w3.org Mon Oct 29 19:23:03 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00763 for ; Mon, 29 Oct 2001 19:23:02 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id TAA14226; Mon, 29 Oct 2001 19:21:38 -0500 (EST) Resent-Date: Mon, 29 Oct 2001 19:21:38 -0500 (EST) Resent-Message-Id: <200110300021.TAA14226@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id TAA14206 for ; Mon, 29 Oct 2001 19:21:34 -0500 (EST) Received: from cats.ucsc.edu (rumpleteazer.ucsc.edu [128.114.129.45]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id TAA07169 for ; Mon, 29 Oct 2001 19:21:34 -0500 Received: from Tycho (dhcp-55-194.cse.ucsc.edu [128.114.55.194]) by cats.ucsc.edu (8.9.3/8.8.4.cats-athena) with SMTP id QAA16531; Mon, 29 Oct 2001 16:23:46 -0800 (PST) From: "Jim Whitehead" To: "Clemm, Geoff" , "WebDAV" Date: Mon, 29 Oct 2001 16:17:35 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <3906C56A7BD1F54593344C05BD1374B103F8AD10@SUS-MA1IT01> Subject: RE: Ideas: GETSRC & MULTIPUT Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5485 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit These are very good questions. One possible set of answers: > In general, I believe having distinct URL's for different resources > is far superior to defining new methods. How would you set access > control on the "source" resource? The dav:readsrc privilege. > How would you get the properties of the "source" resource? In this model it's not a different resource, so you'd use PROPFIND. If you want information about the src, then dav:srccontentlength, dav:srcetag, dav:srccreationdate, dav:srclastmodified... properties would need to be defined. - Jim From w3c-dist-auth-request@w3.org Mon Oct 29 19:26:34 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00804 for ; Mon, 29 Oct 2001 19:26:34 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id TAA14359; Mon, 29 Oct 2001 19:24:53 -0500 (EST) Resent-Date: Mon, 29 Oct 2001 19:24:53 -0500 (EST) Resent-Message-Id: <200110300024.TAA14359@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id TAA14339 for ; Mon, 29 Oct 2001 19:24:46 -0500 (EST) Received: from mutley.ebuilt.net (nat.ebuilt.com [209.216.46.200]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id TAA07409 for ; Mon, 29 Oct 2001 19:24:46 -0500 Received: (from root@localhost) by mutley.ebuilt.net (8.11.1/8.11.1) id f9U0OG104335 for ; Mon, 29 Oct 2001 16:24:16 -0800 Received: from waka.ebuilt.net (IDENT:root@i199.ir.ebuilt.net [10.1.2.199]) by mutley.ebuilt.net (8.11.1/8.11.1) with ESMTP id f9U0OFO04254; Mon, 29 Oct 2001 16:24:15 -0800 Received: (from fielding@localhost) by waka.ebuilt.net (8.11.0/8.11.0) id f9U0Lvx08680; Mon, 29 Oct 2001 16:21:57 -0800 Date: Mon, 29 Oct 2001 16:21:57 -0800 From: "Roy T. Fielding" To: Jim Whitehead Cc: WebDAV Message-ID: <20011029162157.A8666@waka.ebuilt.net> References: <20011029142520.D8295@waka.ebuilt.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.20i X-AntiVirus: scanned for viruses by AMaViS 0.2.1-pre3 (http://amavis.org/) Subject: Re: Ideas: GETSRC & MULTIPUT Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5486 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: > The source link didn't work. Telling people to use the source link is not, > IMO, productive. Under what conditions did it not work? Do you mean just never implemented? > GETSRC could be defined as something like, "returns to the client a > representation of the resource suitable for editing in an authoring client", > so we avoid issues of getting at the "true" state of the resource. GETSRC > wouldn't have the same caching properties as GET; I don't see that as being > a big problem for authoring. > > So, which specific HTTP design principle(s) does this proposal violate? The one that calls for different resources to be accessed using different URI. The set of source URI for some other URI are different resources. Since there can be many more than one source per representation, the notion of creating a new method to avoid one indirection is just wrong. ....Roy From w3c-dist-auth-request@w3.org Mon Oct 29 19:41:40 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00953 for ; Mon, 29 Oct 2001 19:41:40 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id TAA14975; Mon, 29 Oct 2001 19:39:52 -0500 (EST) Resent-Date: Mon, 29 Oct 2001 19:39:52 -0500 (EST) Resent-Message-Id: <200110300039.TAA14975@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id TAA14955 for ; Mon, 29 Oct 2001 19:39:47 -0500 (EST) Received: from mutley.ebuilt.net (nat.ebuilt.com [209.216.46.200]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id TAA08436 for ; Mon, 29 Oct 2001 19:39:47 -0500 Received: (from root@localhost) by mutley.ebuilt.net (8.11.1/8.11.1) id f9U0dGu11506 for ; Mon, 29 Oct 2001 16:39:16 -0800 Received: from waka.ebuilt.net (IDENT:root@i199.ir.ebuilt.net [10.1.2.199]) by mutley.ebuilt.net (8.11.1/8.11.1) with ESMTP id f9U0dFO11425; Mon, 29 Oct 2001 16:39:16 -0800 Received: (from fielding@localhost) by waka.ebuilt.net (8.11.0/8.11.0) id f9U0bFm08727; Mon, 29 Oct 2001 16:37:15 -0800 Date: Mon, 29 Oct 2001 16:37:15 -0800 From: "Roy T. Fielding" To: Jim Whitehead Cc: "Clemm, Geoff" , WebDAV Message-ID: <20011029163715.B8666@waka.ebuilt.net> References: <3906C56A7BD1F54593344C05BD1374B103F8AD0E@SUS-MA1IT01> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.20i X-AntiVirus: scanned for viruses by AMaViS 0.2.1-pre3 (http://amavis.org/) Subject: Re: Ideas: GETSRC & MULTIPUT Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5487 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: On Mon, Oct 29, 2001 at 04:10:35PM -0800, Jim Whitehead wrote: > > Why isn't GETSRC just a GET on the DAV:dst of the DAV:source property? > > (If it is just a shorthand for this, I'm against the redundant marshalling > > of this request through a new method). > > The source link has not been implemented. We don't currently have two > interoperable implementations. Thus, according to IETF policy, the source > link goes away in the revision of 2518. If you change the protocol to add GETSRC, then there is no point in revising RFC 2518 -- it would have to recycle at Proposed. I think it would make more sense to have the server and client developers explain why they did not implement it and then come up with a solution that they will implement. I certainly don't want to implement a GETSRC method -- that instantly doubles the server's access control complexity and response codes. ....Roy From w3c-dist-auth-request@w3.org Mon Oct 29 19:53:35 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01141 for ; Mon, 29 Oct 2001 19:53:35 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id TAA16508; Mon, 29 Oct 2001 19:51:41 -0500 (EST) Resent-Date: Mon, 29 Oct 2001 19:51:41 -0500 (EST) Resent-Message-Id: <200110300051.TAA16508@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id TAA16460 for ; Mon, 29 Oct 2001 19:51:30 -0500 (EST) Received: from lsmail.office.lightsurf.com (lsmail.office.lightsurf.com [204.30.31.25]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id TAA09529 for ; Mon, 29 Oct 2001 19:51:30 -0500 Received: from urchin (urchin.office.lightsurf.com [10.10.10.133]) by lsmail.office.lightsurf.com (Mirapoint) with SMTP id AAM71518; Mon, 29 Oct 2001 16:50:56 -0800 (PST) Reply-To: From: "Adam Freeman" To: "Roy T. Fielding" , "Jim Whitehead" Cc: "WebDAV" Date: Mon, 29 Oct 2001 16:51:01 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <20011029162157.A8666@waka.ebuilt.net> Subject: RE: Ideas: GETSRC & MULTIPUT Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5488 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello, While the link property is a little funky, it addresses a common problem: having two (OR MORE) different sets of properties for the same resource. Having a GETSRC and a GET for the same resource limits you to having two representations of the resource, the original and the modified (or authored or whatever you want to call it). What if you want a third representation of that resource? With the link property, you can accomplish that (I think). GETSRC should return the same thing that a GET without any properties should return. It seems redundant. Why not just have more than one set of properties. GET with blank properties is the same as GETSRC. @m -----Original Message----- From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Roy T. Fielding Sent: Monday, October 29, 2001 4:22 PM To: Jim Whitehead Cc: WebDAV Subject: Re: Ideas: GETSRC & MULTIPUT > The source link didn't work. Telling people to use the source link is not, > IMO, productive. Under what conditions did it not work? Do you mean just never implemented? > GETSRC could be defined as something like, "returns to the client a > representation of the resource suitable for editing in an authoring client", > so we avoid issues of getting at the "true" state of the resource. GETSRC > wouldn't have the same caching properties as GET; I don't see that as being > a big problem for authoring. > > So, which specific HTTP design principle(s) does this proposal violate? The one that calls for different resources to be accessed using different URI. The set of source URI for some other URI are different resources. Since there can be many more than one source per representation, the notion of creating a new method to avoid one indirection is just wrong. ....Roy From w3c-dist-auth-request@w3.org Mon Oct 29 20:23:00 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01488 for ; Mon, 29 Oct 2001 20:22:59 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id UAA17953; Mon, 29 Oct 2001 20:20:56 -0500 (EST) Resent-Date: Mon, 29 Oct 2001 20:20:56 -0500 (EST) Resent-Message-Id: <200110300120.UAA17953@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id UAA17886 for ; Mon, 29 Oct 2001 20:20:39 -0500 (EST) Received: from cats.ucsc.edu (rumpleteazer.ucsc.edu [128.114.129.45]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id UAA12296 for ; Mon, 29 Oct 2001 20:20:39 -0500 Received: from Tycho (dhcp-55-194.cse.ucsc.edu [128.114.55.194]) by cats.ucsc.edu (8.9.3/8.8.4.cats-athena) with SMTP id RAA02490; Mon, 29 Oct 2001 17:22:53 -0800 (PST) From: "Jim Whitehead" To: "Roy T. Fielding" Cc: "WebDAV" Date: Mon, 29 Oct 2001 17:16:41 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <20011029162157.A8666@waka.ebuilt.net> Importance: Normal Subject: RE: Ideas: GETSRC & MULTIPUT Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5489 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > Under what conditions did it not work? Do you mean just never > implemented? The source link was never implemented. The two reasons I have heard for this (there may be more) are: (a) Server implementors did not want to handle the namespace complexity of automatically creating new areas of the namespace for source resources. That is, on most servers, the source resources would be "synthetic" -- the server would be making up the URL for the source resource, and would be managing interactions with this synthetic resource. (b) There was insufficient direction given to client implementors on how to use and handle the source link, especially in the case of multiple sources for a given resource. The user interfaces of almost all existing DAV clients implicitly assume there is just a single "source" representation for a resource. Perhaps DAV's closeness to a traditional network file system protocol is coming back to haunt us. Certainly, it would involve significant UI and operational shifts to accommodate more. I think existing client UIs could handle a standard mechanism to get at 1 source representation for a resource. I do not think they can handle a mechanism that provides access to multiple source representations. Efforts to do so will, like the source link, be ignored. I think it is instructive that the only mechanism that has gained any traction so far is the Translate header, which provides access to one source representation. - Jim From w3c-dist-auth-request@w3.org Mon Oct 29 20:28:10 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01592 for ; Mon, 29 Oct 2001 20:28:10 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id UAA18136; Mon, 29 Oct 2001 20:23:28 -0500 (EST) Resent-Date: Mon, 29 Oct 2001 20:23:28 -0500 (EST) Resent-Message-Id: <200110300123.UAA18136@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id UAA18105 for ; Mon, 29 Oct 2001 20:23:19 -0500 (EST) Received: from cats.ucsc.edu (rumpleteazer.ucsc.edu [128.114.129.45]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id UAA12539 for ; Mon, 29 Oct 2001 20:23:19 -0500 Received: from Tycho (dhcp-55-194.cse.ucsc.edu [128.114.55.194]) by cats.ucsc.edu (8.9.3/8.8.4.cats-athena) with SMTP id RAA03009; Mon, 29 Oct 2001 17:25:33 -0800 (PST) From: "Jim Whitehead" To: "Roy T. Fielding" Cc: "WebDAV" Date: Mon, 29 Oct 2001 17:19:21 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <20011029163715.B8666@waka.ebuilt.net> Importance: Normal Subject: RE: Ideas: GETSRC & MULTIPUT Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5490 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > If you change the protocol to add GETSRC, then there is no point in > revising RFC 2518 -- it would have to recycle at Proposed. My assumption is that revising 2518 will take some time. If a new mechanism for getting access to the source link is developed, and sent to proposed in a separate RFC, I suspect we could get two interoperable implementations before the end of the 2518 revision period, and hence include the new mechanism, since it too woul dbe at Draft status then. > I > think it would make more sense to have the server and client developers > explain why they did not implement it and then come up with a solution > that they will implement. I am all in favor of developing a solution client and server implementors will code. > I certainly don't want to implement a GETSRC method -- that > instantly doubles > the server's access control complexity and response codes. Other ideas? - Jim From w3c-dist-auth-request@w3.org Mon Oct 29 22:04:10 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03729 for ; Mon, 29 Oct 2001 22:04:10 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id VAA23527; Mon, 29 Oct 2001 21:58:46 -0500 (EST) Resent-Date: Mon, 29 Oct 2001 21:58:46 -0500 (EST) Resent-Message-Id: <200110300258.VAA23527@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id VAA23462 for ; Mon, 29 Oct 2001 21:58:35 -0500 (EST) Received: from io.mds.rmit.edu.au (io.mds.rmit.edu.au [131.170.70.10]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id VAA23305 for ; Mon, 29 Oct 2001 21:58:34 -0500 Received: by io.mds.rmit.edu.au (Postfix, from userid 301) id 1CF2949B49; Tue, 30 Oct 2001 13:57:57 +1100 (EST) Date: Tue, 30 Oct 2001 13:57:56 +1100 From: Alan Kent To: WebDAV Message-ID: <20011030135756.B26015@io.mds.rmit.edu.au> References: <3906C56A7BD1F54593344C05BD1374B103F8AD0E@SUS-MA1IT01> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95i In-Reply-To: ; from Jim Whitehead on Mon, Oct 29, 2001 at 04:10:35PM -0800 Subject: Re: Ideas: GETSRC & MULTIPUT Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5491 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: I am uneasy about a single URL being effectively bound to two resources (GET and GETSRC return different resources). It opens a potential can of worms in that every HTTP method (HEAD, PROPFIND, LOCK, ...) then potentially needs to be duplicated. And how do I know that GETSRC will work? (Is it defined for all resources no matter what type they are?) Personally I would feel more comfortable with either the current 'source' scheme, another HTTP header field applicable to all requests, or a parameter on the URL or something (/foo.html and /foo.html;getsrc). I can see the cleaness of making one URL computed from the other (identical in the proposed scheme, computed in the ;getsrc parameter scheme above) but I dislike one URL identifying multiple resources and the riple through all the other methods that would be required. Alan From w3c-dist-auth-request@w3.org Mon Oct 29 22:14:15 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03805 for ; Mon, 29 Oct 2001 22:14:14 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id WAA24732; Mon, 29 Oct 2001 22:09:15 -0500 (EST) Resent-Date: Mon, 29 Oct 2001 22:09:15 -0500 (EST) Resent-Message-Id: <200110300309.WAA24732@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id WAA24665 for ; Mon, 29 Oct 2001 22:09:01 -0500 (EST) Received: from io.mds.rmit.edu.au (io.mds.rmit.edu.au [131.170.70.10]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id WAA24417 for ; Mon, 29 Oct 2001 22:09:01 -0500 Received: by io.mds.rmit.edu.au (Postfix, from userid 301) id 8D41A49B49; Tue, 30 Oct 2001 14:08:29 +1100 (EST) Date: Tue, 30 Oct 2001 14:08:29 +1100 From: Alan Kent To: WebDAV Message-ID: <20011030140829.C26015@io.mds.rmit.edu.au> References: <3906C56A7BD1F54593344C05BD1374B103F8AD10@SUS-MA1IT01> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95i In-Reply-To: ; from Jim Whitehead on Mon, Oct 29, 2001 at 04:17:35PM -0800 Subject: Re: Ideas: GETSRC & MULTIPUT Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5492 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: On Mon, Oct 29, 2001 at 04:17:35PM -0800, Jim Whitehead wrote: > > How would you get the properties of the "source" resource? > > In this model it's not a different resource, so you'd use PROPFIND. If you > want information about the src, then dav:srccontentlength, dav:srcetag, > dav:srccreationdate, dav:srclastmodified... properties would need to be > defined. > > - Jim I would find this hard to swallow. I am uncomfortable about a CGI-BIN script and the output of the script being called the same resource in WebDAV. All of WebDAV would have to be carefully reworked to get this concept in. And what about CGI-BIN scripts which took parameters or things from the URL? The following URLs could all be the same CGI-BIN script /cgi-bin/foo /cgi-bin/foo/bar /cgi-bin/foo?name=bar Does GETSRC on all three return the same CGI-BIN script? Does a LOCK on /cgi-bin/foo also lock the other two as well? etc. I just feels messy to me. I personally think the output of a script and the script itself are different resources. DeltaV for example uses different URLs for all the version resources etc. Using a different scheme suddenly in WebDAV feels against the grain. Alan From w3c-dist-auth-request@w3.org Mon Oct 29 22:16:21 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03818 for ; Mon, 29 Oct 2001 22:16:21 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id WAA24961; Mon, 29 Oct 2001 22:11:41 -0500 (EST) Resent-Date: Mon, 29 Oct 2001 22:11:41 -0500 (EST) Resent-Message-Id: <200110300311.WAA24961@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id WAA24927 for ; Mon, 29 Oct 2001 22:11:32 -0500 (EST) Received: from inet-mail3.oracle.com (inet-mail3.oracle.com [148.87.2.203]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id WAA24568 for ; Mon, 29 Oct 2001 22:11:33 -0500 Received: from rgmgw5.us.oracle.com (rgmgw5.us.oracle.com [138.1.191.14]) by inet-mail3.oracle.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f9U35ru13761; Mon, 29 Oct 2001 19:05:53 -0800 (PST) Received: from esedcarlaptop (dhcp-4op7-4op8-east-130-35-171-71.us.oracle.com [130.35.171.71]) by rgmgw5.us.oracle.com (Switch-2.1.3/Switch-2.1.0) with SMTP id f9U3BVD03378; Mon, 29 Oct 2001 20:11:31 -0700 (MST) From: "Eric Sedlar" To: "Clemm, Geoff" , "WebDAV" Date: Mon, 29 Oct 2001 19:11:13 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <3906C56A7BD1F54593344C05BD1374B103F8AD10@SUS-MA1IT01> Subject: RE: Ideas: GETSRC & MULTIPUT Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5493 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit The fact that you can't do anything with the source is kind of specious. You can view the "GET" method as "execute the OPEN action on this resource" and GETSRC as the get (that gives you the data you just PUT into the resource). Anything other than GET that you do to the "source" resource will operate in the same way as on the original resource, so I think that using another resource is a poor model. -----Original Message----- From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff Sent: Monday, October 29, 2001 1:55 PM To: WebDAV Subject: RE: Ideas: GETSRC & MULTIPUT In general, I believe having distinct URL's for different resources is far superior to defining new methods. How would you set access control on the "source" resource? How would you get the properties of the "source" resource? If you have a URL for the source resource, all this is straightforward ... but if you have something like a GETSRC method, the only thing you can do with the "source" is get its content. Cheers, Geoff -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de] Sent: Monday, October 29, 2001 4:35 PM To: Clemm, Geoff; WebDAV Subject: RE: Ideas: GETSRC & MULTIPUT Geoff, I'd like to see how the DAV:dst in WebDAV can support what Microsoft is doing with their Translate header (namely, having the source and the dynamic content at the same URL). See also my comments in Julian > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff > Sent: Monday, October 29, 2001 10:18 PM > To: WebDAV > Subject: RE: Ideas: GETSRC & MULTIPUT > > > Why isn't GETSRC just a GET on the DAV:dst of the DAV:source property? > (If it is just a shorthand for this, I'm against the redundant marshalling > of this request through a new method). > > As for MULTIPUT, that sounds fine to me, but it should be accompanied by > a MULTIGET, which would allow reading of a resource and its metadata in > one transaction. > > Cheers, > Geoff > > -----Original Message----- > From: Jim Whitehead [mailto:ejw@cse.ucsc.edu] > Sent: Monday, October 29, 2001 3:14 PM > To: WebDAV > Subject: Ideas: GETSRC & MULTIPUT > > > I'm interested in the list's thoughts on two ideas for DAV improvements: > > The first is to introduce a GETSRC method to support access to the > unprocessed source of a resource. This would decouple the dynamic response > of a resource (GET) from its static source (GETSRC). > > The second is to introduce the MULTIPUT method to support "PUT with > PROPPATCH" scenarios. MULTIPUT would accept some subset of multipart MIME > packages and atomically write them to the server. This would support the > update of a resource and its metadata in one transaction. > > - Jim > From w3c-dist-auth-request@w3.org Mon Oct 29 22:41:09 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05045 for ; Mon, 29 Oct 2001 22:41:09 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id WAA27711; Mon, 29 Oct 2001 22:36:13 -0500 (EST) Resent-Date: Mon, 29 Oct 2001 22:36:13 -0500 (EST) Resent-Message-Id: <200110300336.WAA27711@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id WAA27662 for ; Mon, 29 Oct 2001 22:35:59 -0500 (EST) Received: from sus-ma1it00.rational.com (ext-37184.rational.com [192.229.37.184]) by tux.w3.org (8.9.3/8.9.3) with SMTP id WAA26791 for ; Mon, 29 Oct 2001 22:35:59 -0500 Received: from 192.168.215.70 by sus-ma1it00.rational.com (InterScan E-Mail VirusWall NT); Mon, 29 Oct 2001 22:35:28 -0500 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id <4D31HY6M>; Mon, 29 Oct 2001 22:35:28 -0500 Message-ID: <3906C56A7BD1F54593344C05BD1374B104AC78FD@SUS-MA1IT01> From: "Clemm, Geoff" To: WebDAV Date: Mon, 29 Oct 2001 22:35:27 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Ideas: GETSRC & MULTIPUT Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5494 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: From: Jim Whitehead [mailto:ejw@cse.ucsc.edu] These are very good questions. One possible set of answers: > In general, I believe having distinct URL's for different resources > is far superior to defining new methods. How would you set access > control on the "source" resource? The dav:readsrc privilege. Since it is likely that the privileges for the "source" resource will be very different from those on the "non-source" resource, I'll also need a dav:writesrc, etc, effectively doubling the privilege space, just so that the server can avoid allocating a new URL to the source resource? In many cases, there actually will already be a separate URL (e.g. a /xxx.jsp resource which generates the /xxx.html file). Also, what about PUT? Is an authoring client going to do a PUT to /xxx.html in .jsp format, and then a GET will return something in .html format? Then what happens when a naive client tries to PUT something in .html format to /xxx.html, and then get some unexpected error message (or even worse, the html file will just overwrite the .jsp resource and generate strange errors at the next GET). Looks like we probably should have a PUTSRC, to match the GETSRC. > How would you get the properties of the "source" resource? In this model it's not a different resource, so you'd use PROPFIND. If you want information about the src, then dav:srccontentlength, dav:srcetag, dav:srccreationdate, dav:srclastmodified... properties would need to be defined. It probably would make more sense to just have a PROPFINDSRC. And probably a COPYSRC. And an xxxSRC for any new WebDAV method that could reasonably be applied to either the original resource or to the "source". I continue to believe that GETSRC (and its other xxxSRC friends) would be a very unfortunate direction to pursue. In particular, I think having the separate URL is a clear win for clients. I'd be interested in even a partially compelling story from the server vendors as to why they cannot generate additional URL's for the source resources (or in many cases, expose the source resource URL, when it already has its own URL). I'd much rather do nothing here, than do something wrong. Cheers, Geoff From w3c-dist-auth-request@w3.org Mon Oct 29 22:53:43 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05175 for ; Mon, 29 Oct 2001 22:53:43 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id WAA28812; Mon, 29 Oct 2001 22:48:49 -0500 (EST) Resent-Date: Mon, 29 Oct 2001 22:48:49 -0500 (EST) Resent-Message-Id: <200110300348.WAA28812@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id WAA28763 for ; Mon, 29 Oct 2001 22:48:28 -0500 (EST) Received: from sus-ma1it00.rational.com (ext-37184.rational.com [192.229.37.184]) by tux.w3.org (8.9.3/8.9.3) with SMTP id WAA27749 for ; Mon, 29 Oct 2001 22:48:28 -0500 Received: from 192.168.215.70 by sus-ma1it00.rational.com (InterScan E-Mail VirusWall NT); Mon, 29 Oct 2001 22:47:57 -0500 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id <4D31HZJW>; Mon, 29 Oct 2001 22:47:57 -0500 Message-ID: <3906C56A7BD1F54593344C05BD1374B104AC7900@SUS-MA1IT01> From: "Clemm, Geoff" To: WebDAV Date: Mon, 29 Oct 2001 22:47:55 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Ideas: GETSRC & MULTIPUT Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5495 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: From: Eric Sedlar [mailto:eric.sedlar@oracle.com] The fact that you can't do anything with the source is kind of specious. You can view the "GET" method as "execute the OPEN action on this resource" and GETSRC as the get (that gives you the data you just PUT into the resource). Anything other than GET that you do to the "source" resource will operate in the same way as on the original resource, so I think that using another resource is a poor model. What about the "DAV:getcontentlength" property? And the "last accessed" date? And the "read" ACL (i.e. everyone that can read the result can read the source)? And for this kind of resource, you use GETSRC to retrieve what you just PUT, while for most other resources, you use GET to retrieve what you just PUT? In many cases, page caching on the server means that there commonly are two different files being stored on the server. And that sometimes the source file is not even on the same server as the derived file. The "separate resource" model seems pretty reasonable to me. Cheers, Geoff From w3c-dist-auth-request@w3.org Tue Oct 30 02:28:54 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22035 for ; Tue, 30 Oct 2001 02:28:54 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id CAA17654; Tue, 30 Oct 2001 02:25:51 -0500 (EST) Resent-Date: Tue, 30 Oct 2001 02:25:51 -0500 (EST) Resent-Message-Id: <200110300725.CAA17654@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id CAA17517 for ; Tue, 30 Oct 2001 02:25:32 -0500 (EST) Received: from kurgan.lyra.org (kurgan.lyra.org [198.144.203.198]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id CAA18267 for ; Tue, 30 Oct 2001 02:25:31 -0500 Received: (from gstein@localhost) by kurgan.lyra.org (8.9.3/8.9.3) id XAA06288 for w3c-dist-auth@w3.org; Mon, 29 Oct 2001 23:31:31 -0800 X-Authentication-Warning: kurgan.lyra.org: gstein set sender to gstein@lyra.org using -f Date: Mon, 29 Oct 2001 23:31:31 -0800 From: Greg Stein To: WebDAV Message-ID: <20011029233131.A6221@lyra.org> Mail-Followup-To: WebDAV References: <3906C56A7BD1F54593344C05BD1374B104AC78FD@SUS-MA1IT01> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <3906C56A7BD1F54593344C05BD1374B104AC78FD@SUS-MA1IT01>; from gclemm@rational.com on Mon, Oct 29, 2001 at 10:35:27PM -0500 X-URL: http://www.lyra.org/greg/ Subject: Re: Ideas: GETSRC & MULTIPUT Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5496 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: On Mon, Oct 29, 2001 at 10:35:27PM -0500, Clemm, Geoff wrote: >... > I continue to believe that GETSRC (and its other xxxSRC friends) > would be a very unfortunate direction to pursue. In particular, > I think having the separate URL is a clear win for clients. I'd Agreed. > be interested in even a partially compelling story from the server > vendors as to why they cannot generate additional URL's for the > source resources (or in many cases, expose the source resource URL, > when it already has its own URL). No reason here other than "haven't spent time on it (yet)." I pretty much know how I'd do it -- there isn't any technical problem with it. One new directive and a little code to auto-generate the DAV:link property. If client were pushing for it, then I probably would have coded it already. Kind of a chicken and egg thing. Cheers, -g -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Tue Oct 30 02:54:16 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22443 for ; Tue, 30 Oct 2001 02:54:16 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id CAA22780; Tue, 30 Oct 2001 02:49:16 -0500 (EST) Resent-Date: Tue, 30 Oct 2001 02:49:16 -0500 (EST) Resent-Message-Id: <200110300749.CAA22780@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id CAA22759 for ; Tue, 30 Oct 2001 02:49:08 -0500 (EST) Received: from inet-mail3.oracle.com (inet-mail3.oracle.com [148.87.2.203]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id CAA22435 for ; Tue, 30 Oct 2001 02:49:08 -0500 Received: from rgmgw6.us.oracle.com (rgmgw6.us.oracle.com [138.1.191.15]) by inet-mail3.oracle.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f9U7hSu16469 for ; Mon, 29 Oct 2001 23:43:28 -0800 (PST) Received: from esedlarpc (esedlar-pc-xdsl.us.oracle.com [152.68.17.154]) by rgmgw6.us.oracle.com (Switch-2.1.3/Switch-2.1.0) with SMTP id f9U7n6j27403 for ; Tue, 30 Oct 2001 00:49:06 -0700 (MST) From: "Eric Sedlar" To: "WebDAV" Date: Mon, 29 Oct 2001 23:53:03 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal In-Reply-To: <3906C56A7BD1F54593344C05BD1374B104AC7900@SUS-MA1IT01> Subject: RE: Ideas: GETSRC & MULTIPUT Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5497 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Geoff, I'm still not buying it. > What about the "DAV:getcontentlength" property? This is actually kind of a stupid property for the generated content, since it is usually impossible to know the length of the data that will be output before actually generating it. > And the "last accessed" date? Is there a DAV: property for that? > And the "read" ACL (i.e. everyone that > can read the result can read the source)? Perhaps, GET should be restricted by a dav:get privilege, or else GET should be restricted by a dav:execute privilege if the contents is generated. > And for this kind of resource, you use GETSRC to retrieve what > you just PUT, while for most other resources, you use GET to > retrieve what you just PUT? > GETSRC will always retrieve what you PUT. GET is the equivalent of a doubleclick on a file in windows--it runs some type-dependent "open" functionality. > In many cases, page caching on the server > means that there commonly are two different files being stored > on the server. And that sometimes the source file is not even > on the same server as the derived file. > Caching generated output may or may not make sense, depending on how that generation is done. I think the stretch is treating generated content as file. Let's say my .jsp file generates my shopping cart page from some rows in a database. You generally don't know the length, modification date, or other normal file-like properties for generated output. The modification date of the shopping cart is the time the last item in the cart was modified, and most database applications don't track this on a per-row basis. --Eric From w3c-dist-auth-request@w3.org Tue Oct 30 03:45:21 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22795 for ; Tue, 30 Oct 2001 03:45:21 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id DAA27955; Tue, 30 Oct 2001 03:36:59 -0500 (EST) Resent-Date: Tue, 30 Oct 2001 03:36:59 -0500 (EST) Resent-Message-Id: <200110300836.DAA27955@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id DAA27919 for ; Tue, 30 Oct 2001 03:36:42 -0500 (EST) Received: from mutley.ebuilt.net (nat.ebuilt.com [209.216.46.200]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id DAA27405 for ; Tue, 30 Oct 2001 03:36:42 -0500 Received: (from root@localhost) by mutley.ebuilt.net (8.11.1/8.11.1) id f9U8a7n02737 for ; Tue, 30 Oct 2001 00:36:07 -0800 Received: from waka.ebuilt.net (IDENT:root@i199.ir.ebuilt.net [10.1.2.199]) by mutley.ebuilt.net (8.11.1/8.11.1) with ESMTP id f9U8a7O02656; Tue, 30 Oct 2001 00:36:07 -0800 Received: (from fielding@localhost) by waka.ebuilt.net (8.11.0/8.11.0) id f9U8WjD09537; Tue, 30 Oct 2001 00:32:45 -0800 Date: Tue, 30 Oct 2001 00:32:45 -0800 From: "Roy T. Fielding" To: Jim Whitehead Cc: WebDAV Message-ID: <20011030003245.A9518@waka.ebuilt.net> References: <20011029162157.A8666@waka.ebuilt.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.20i X-AntiVirus: scanned for viruses by AMaViS 0.2.1-pre3 (http://amavis.org/) Subject: Re: Ideas: GETSRC & MULTIPUT Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5498 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: On Mon, Oct 29, 2001 at 05:16:41PM -0800, Jim Whitehead wrote: > > Under what conditions did it not work? Do you mean just never > > implemented? > > The source link was never implemented. Well, that's a hell of a lot easier to fix than to rewrite a standard and all of the models upon which it is based. > The two reasons I have heard for this (there may be more) are: > > (a) Server implementors did not want to handle the namespace complexity of > automatically creating new areas of the namespace for source resources. That > is, on most servers, the source resources would be "synthetic" -- the server > would be making up the URL for the source resource, and would be managing > interactions with this synthetic resource. Huh? Then how are they going to handle the different access control and behavior necessary for synthetic versus static resources? You can't PUT to a CGI script's synthesis URI and expect to edit the source because it is the Common Gateway Interface, which necessarily requires that the PUT be gatewayed through to the script itself. Trust me on this one -- the notion of GETSRC as you described it cannot be implemented on the Web. That only makes sense for files, not resources, and even then only files that do not contain any subsidiary resources as inclusions. > (b) There was insufficient direction given to client implementors on how to > use and handle the source link, especially in the case of multiple sources > for a given resource. The user interfaces of almost all existing DAV clients > implicitly assume there is just a single "source" representation for a > resource. Perhaps DAV's closeness to a traditional network file system > protocol is coming back to haunt us. Certainly, it would involve significant > UI and operational shifts to accommodate more. So the solution is to make it impossibe to edit resources that consist of multiple sources? That'll really piss off my customer who has spent most of this year creating a site that is entirely controlled by a content management system, where each resource consists of a dynamic mapping to a database entity catalog. Each Web page consists of dozens of source elements. It isn't using webdav right now, but it would be a shame if webdav couldn't support existing CMS functionality. > I think existing client UIs could handle a standard mechanism to get at 1 > source representation for a resource. I do not think they can handle a > mechanism that provides access to multiple source representations. Efforts > to do so will, like the source link, be ignored. I think it is instructive > that the only mechanism that has gained any traction so far is the Translate > header, which provides access to one source representation. If it doesn't support the Web, then it doesn't qualify for the name WebDAV. Feel free to define yet another distributed filesystem protocol within any other working group of the IETF. I'd rather wait until it gets implemented correctly than reduce the standard to something that doesn't meet the need. ....Roy From w3c-dist-auth-request@w3.org Tue Oct 30 07:22:58 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25319 for ; Tue, 30 Oct 2001 07:22:58 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id HAA14806; Tue, 30 Oct 2001 07:09:34 -0500 (EST) Resent-Date: Tue, 30 Oct 2001 07:09:34 -0500 (EST) Resent-Message-Id: <200110301209.HAA14806@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id HAA14783 for ; Tue, 30 Oct 2001 07:09:28 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id HAA17859 for ; Tue, 30 Oct 2001 07:09:28 -0500 Received: (qmail 31857 invoked by uid 0); 30 Oct 2001 12:09:16 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mp003-rz3) with SMTP; 30 Oct 2001 12:09:16 -0000 From: "Julian Reschke" To: "Jim Whitehead" , "Roy T. Fielding" Cc: "WebDAV" Date: Tue, 30 Oct 2001 13:09:56 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: Importance: Normal Subject: RE: Ideas: GETSRC & MULTIPUT Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5499 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jim Whitehead > Sent: Tuesday, October 30, 2001 2:17 AM > To: Roy T. Fielding > Cc: WebDAV > Subject: RE: Ideas: GETSRC & MULTIPUT > > > > Under what conditions did it not work? Do you mean just never > > implemented? > > The source link was never implemented. > > The two reasons I have heard for this (there may be more) are: > > ... > > (b) There was insufficient direction given to client implementors > on how to > use and handle the source link, especially in the case of multiple sources > for a given resource. The user interfaces of almost all existing > DAV clients > implicitly assume there is just a single "source" representation for a > resource. Perhaps DAV's closeness to a traditional network file system > protocol is coming back to haunt us. Certainly, it would involve > significant > UI and operational shifts to accommodate more. > > I think existing client UIs could handle a standard mechanism to get at 1 > source representation for a resource. I do not think they can handle a > mechanism that provides access to multiple source representations. Efforts > to do so will, like the source link, be ignored. I think it is instructive > that the only mechanism that has gained any traction so far is > the Translate > header, which provides access to one source representation. I don't quite agree. If a client is able to select an optional source resource, it should't have problems offering a selection multiple sources. However, the server would need to assist in labeling them. Currently, the RFC only gives the following example: Source http://foo.bar/program http://foo.bar/src/main.c Library http://foo.bar/program http://foo.bar/src/main.lib Makefile http://foo.bar/program http://foo.bar/src/makefile In this example the resource http://foo.bar/program has a source property that contains three links. Each link contains three elements, two of which, src and dst, are part of the DAV schema defined in this document, and one which is defined by the schema http://www.foocorp.com/project/ (Source, Library, and Makefile). A client which only implements the elements in the DAV spec will not understand the foocorp elements and will ignore them, thus seeing the expected source and destination links. An enhanced client may know about the foocorp elements and be able to present the user with additional information about the links. This example demonstrates the power of XML markup, allowing element values to be enhanced without breaking older clients. This is extremely confusing (at least it was to me), because: - the individual link elements have a src element that is identical to the request URI (which isn't shown). Why does it exist at all? - there's no common way for a client to decide what kind of line this is. So, taking this in account and moving to a XLink-compatible syntax would give us instead: source file library file makefile A UI could then use the text content of the D:source element as a human-readable description of the type of link. From w3c-dist-auth-request@w3.org Tue Oct 30 09:12:06 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00558 for ; Tue, 30 Oct 2001 09:12:06 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id JAA24462; Tue, 30 Oct 2001 09:09:14 -0500 (EST) Resent-Date: Tue, 30 Oct 2001 09:09:14 -0500 (EST) Resent-Message-Id: <200110301409.JAA24462@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id JAA24429 for ; Tue, 30 Oct 2001 09:08:59 -0500 (EST) Received: from opentext.com (drawbridge.opentext.com [204.138.115.3]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id JAA00358 for ; Tue, 30 Oct 2001 09:08:59 -0500 Received: (from root@localhost) by opentext.com (8.9.3/8.9.3) id JAA15425; Tue, 30 Oct 2001 09:08:25 -0500 Received: from 111.dhcp11.opentext.com(172.21.11.111) by krusty.wl.opentext.com via smap (V2.1) id xmaa15395; Tue, 30 Oct 01 09:08:22 -0500 From: "Dylan Barrell" To: "Clemm, Geoff" , "WebDAV" Date: Tue, 30 Oct 2001 09:07:50 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: <3906C56A7BD1F54593344C05BD1374B103F8AD0E@SUS-MA1IT01> Subject: RE: Ideas: GETSRC & MULTIPUT Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5500 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit The reason for MULTIPUT is so that servers can enforce property rules on resources when they are created. MULTIGET doesn't add any additional value so I could live without MULTIGET. --Dylan > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff > Sent: Monday, October 29, 2001 4:18 PM > To: WebDAV > Subject: RE: Ideas: GETSRC & MULTIPUT > > > Why isn't GETSRC just a GET on the DAV:dst of the DAV:source property? > (If it is just a shorthand for this, I'm against the redundant marshalling > of this request through a new method). > > As for MULTIPUT, that sounds fine to me, but it should be accompanied by > a MULTIGET, which would allow reading of a resource and its metadata in > one transaction. > > Cheers, > Geoff > > -----Original Message----- > From: Jim Whitehead [mailto:ejw@cse.ucsc.edu] > Sent: Monday, October 29, 2001 3:14 PM > To: WebDAV > Subject: Ideas: GETSRC & MULTIPUT > > > I'm interested in the list's thoughts on two ideas for DAV improvements: > > The first is to introduce a GETSRC method to support access to the > unprocessed source of a resource. This would decouple the dynamic response > of a resource (GET) from its static source (GETSRC). > > The second is to introduce the MULTIPUT method to support "PUT with > PROPPATCH" scenarios. MULTIPUT would accept some subset of multipart MIME > packages and atomically write them to the server. This would support the > update of a resource and its metadata in one transaction. > > - Jim From w3c-dist-auth-request@w3.org Tue Oct 30 09:21:24 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01001 for ; Tue, 30 Oct 2001 09:21:23 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id JAA26332; Tue, 30 Oct 2001 09:19:13 -0500 (EST) Resent-Date: Tue, 30 Oct 2001 09:19:13 -0500 (EST) Resent-Message-Id: <200110301419.JAA26332@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id JAA26298 for ; Tue, 30 Oct 2001 09:19:07 -0500 (EST) Received: from opentext.com (drawbridge.opentext.com [204.138.115.3]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id JAA02229 for ; Tue, 30 Oct 2001 09:19:07 -0500 Received: (from root@localhost) by opentext.com (8.9.3/8.9.3) id JAA18583; Tue, 30 Oct 2001 09:18:36 -0500 Received: from 111.dhcp11.opentext.com(172.21.11.111) by krusty.wl.opentext.com via smap (V2.1) id xma018556; Tue, 30 Oct 01 09:18:32 -0500 From: "Dylan Barrell" To: "Clemm, Geoff" , "WebDAV" Date: Tue, 30 Oct 2001 09:17:59 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: <3906C56A7BD1F54593344C05BD1374B103F8AD10@SUS-MA1IT01> Subject: RE: Ideas: GETSRC & MULTIPUT Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5501 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit This gets into the realm of renditions... I agree with Geoff, alternative renditions of a resource should be different URLs, however we should define mechanisms for creatung these renditions from the original resource (perhaps the concept of a "master" resource and related "renditions") and being able to determine the master and the renditions from the properties on each. --Dylan > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff > Sent: Monday, October 29, 2001 4:55 PM > To: WebDAV > Subject: RE: Ideas: GETSRC & MULTIPUT > > > In general, I believe having distinct URL's for different resources > is far superior to defining new methods. How would you set access > control on the "source" resource? How would you get the properties of > the "source" resource? If you have a URL for the source resource, > all this is straightforward ... but if you have something like a GETSRC > method, the only thing you can do with the "source" is get its content. > > Cheers, > Geoff > > -----Original Message----- > From: Julian Reschke [mailto:julian.reschke@gmx.de] > Sent: Monday, October 29, 2001 4:35 PM > To: Clemm, Geoff; WebDAV > Subject: RE: Ideas: GETSRC & MULTIPUT > > > Geoff, > > I'd like to see how the DAV:dst in WebDAV can support what Microsoft is > doing with their Translate header (namely, having the source and > the dynamic > content at the same URL). > > See also my comments in > > > > Julian > > > -----Original Message----- > > From: w3c-dist-auth-request@w3.org > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff > > Sent: Monday, October 29, 2001 10:18 PM > > To: WebDAV > > Subject: RE: Ideas: GETSRC & MULTIPUT > > > > > > Why isn't GETSRC just a GET on the DAV:dst of the DAV:source property? > > (If it is just a shorthand for this, I'm against the redundant > marshalling > > of this request through a new method). > > > > As for MULTIPUT, that sounds fine to me, but it should be accompanied by > > a MULTIGET, which would allow reading of a resource and its metadata in > > one transaction. > > > > Cheers, > > Geoff > > > > -----Original Message----- > > From: Jim Whitehead [mailto:ejw@cse.ucsc.edu] > > Sent: Monday, October 29, 2001 3:14 PM > > To: WebDAV > > Subject: Ideas: GETSRC & MULTIPUT > > > > > > I'm interested in the list's thoughts on two ideas for DAV improvements: > > > > The first is to introduce a GETSRC method to support access to the > > unprocessed source of a resource. This would decouple the > dynamic response > > of a resource (GET) from its static source (GETSRC). > > > > The second is to introduce the MULTIPUT method to support "PUT with > > PROPPATCH" scenarios. MULTIPUT would accept some subset of > multipart MIME > > packages and atomically write them to the server. This would support the > > update of a resource and its metadata in one transaction. > > > > - Jim > > From w3c-dist-auth-request@w3.org Tue Oct 30 09:21:33 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01017 for ; Tue, 30 Oct 2001 09:21:33 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id JAA26368; Tue, 30 Oct 2001 09:19:22 -0500 (EST) Resent-Date: Tue, 30 Oct 2001 09:19:22 -0500 (EST) Resent-Message-Id: <200110301419.JAA26368@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id JAA26300 for ; Tue, 30 Oct 2001 09:19:07 -0500 (EST) Received: from opentext.com (drawbridge.opentext.com [204.138.115.3]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id JAA02230 for ; Tue, 30 Oct 2001 09:19:07 -0500 Received: (from root@localhost) by opentext.com (8.9.3/8.9.3) id JAA18585; Tue, 30 Oct 2001 09:18:37 -0500 Received: from 111.dhcp11.opentext.com(172.21.11.111) by krusty.wl.opentext.com via smap (V2.1) id xmaa18556; Tue, 30 Oct 01 09:18:33 -0500 From: "Dylan Barrell" To: "Roy T. Fielding" , "Jim Whitehead" Cc: "WebDAV" Date: Tue, 30 Oct 2001 09:18:00 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: <20011029142520.D8295@waka.ebuilt.net> Subject: RE: Ideas: GETSRC & MULTIPUT Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5502 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Transactions are overkill for this simple single operation. I prefer a single put with a package made up of different parts - I don't care what we call that. --Dylan > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Roy T. Fielding > Sent: Monday, October 29, 2001 5:25 PM > To: Jim Whitehead > Cc: WebDAV > Subject: Re: Ideas: GETSRC & MULTIPUT > > > On Mon, Oct 29, 2001 at 12:14:10PM -0800, Jim Whitehead wrote: > > I'm interested in the list's thoughts on two ideas for DAV improvements: > > > > The first is to introduce a GETSRC method to support access to the > > unprocessed source of a resource. This would decouple the > dynamic response > > of a resource (GET) from its static source (GETSRC). > > That would, of course, be completely contrary to the HTTP design and > further propagate the mistake of not accessing properties as resources. > Just use the source link. > > > The second is to introduce the MULTIPUT method to support "PUT with > > PROPPATCH" scenarios. MULTIPUT would accept some subset of > multipart MIME > > packages and atomically write them to the server. This would support the > > update of a resource and its metadata in one transaction. > > Please choose a better name -- MPUT and MULTIPUT means multiple > PUT requests, > which was already tried and abandoned. Maybe you can call it > PKG. Or just > define a mapping to transactions and leave them as separate requests. > > ....Roy From w3c-dist-auth-request@w3.org Tue Oct 30 10:01:21 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03120 for ; Tue, 30 Oct 2001 10:01:21 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id JAA00884; Tue, 30 Oct 2001 09:55:06 -0500 (EST) Resent-Date: Tue, 30 Oct 2001 09:55:06 -0500 (EST) Resent-Message-Id: <200110301455.JAA00884@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id JAA00838 for ; Tue, 30 Oct 2001 09:54:52 -0500 (EST) Received: from sus-ma1it00.rational.com (ext-37184.rational.com [192.229.37.184]) by tux.w3.org (8.9.3/8.9.3) with SMTP id JAA08535 for ; Tue, 30 Oct 2001 09:54:51 -0500 Received: from 192.168.215.70 by sus-ma1it00.rational.com (InterScan E-Mail VirusWall NT); Tue, 30 Oct 2001 09:54:17 -0500 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id <4D312YWS>; Tue, 30 Oct 2001 09:54:16 -0500 Message-ID: <3906C56A7BD1F54593344C05BD1374B104AC79D9@SUS-MA1IT01> From: "Clemm, Geoff" To: WebDAV Date: Tue, 30 Oct 2001 09:54:15 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Ideas: GETSRC & MULTIPUT Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5503 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: I agree that that PATCHPUT (aka MULTIPUT) is of significantly more value than FINDGET, so I withdraw my suggestion that it be accompanied by FINDGET. I see good arguments for and against PATCHPUT, so I will sit on the fence on this one. Cheers, Geoff -----Original Message----- From: Dylan Barrell [mailto:dbarrell@opentext.com] Sent: Tuesday, October 30, 2001 9:08 AM To: Clemm, Geoff; WebDAV Subject: RE: Ideas: GETSRC & MULTIPUT The reason for MULTIPUT is so that servers can enforce property rules on resources when they are created. MULTIGET doesn't add any additional value so I could live without MULTIGET. --Dylan > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff > Sent: Monday, October 29, 2001 4:18 PM > To: WebDAV > Subject: RE: Ideas: GETSRC & MULTIPUT > > > Why isn't GETSRC just a GET on the DAV:dst of the DAV:source property? > (If it is just a shorthand for this, I'm against the redundant marshalling > of this request through a new method). > > As for MULTIPUT, that sounds fine to me, but it should be accompanied by > a MULTIGET, which would allow reading of a resource and its metadata in > one transaction. > > Cheers, > Geoff > > -----Original Message----- > From: Jim Whitehead [mailto:ejw@cse.ucsc.edu] > Sent: Monday, October 29, 2001 3:14 PM > To: WebDAV > Subject: Ideas: GETSRC & MULTIPUT > > > I'm interested in the list's thoughts on two ideas for DAV improvements: > > The first is to introduce a GETSRC method to support access to the > unprocessed source of a resource. This would decouple the dynamic response > of a resource (GET) from its static source (GETSRC). > > The second is to introduce the MULTIPUT method to support "PUT with > PROPPATCH" scenarios. MULTIPUT would accept some subset of multipart MIME > packages and atomically write them to the server. This would support the > update of a resource and its metadata in one transaction. > > - Jim From w3c-dist-auth-request@w3.org Tue Oct 30 11:43:57 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06631 for ; Tue, 30 Oct 2001 11:43:57 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id LAA00435; Tue, 30 Oct 2001 11:39:32 -0500 (EST) Resent-Date: Tue, 30 Oct 2001 11:39:32 -0500 (EST) Resent-Message-Id: <200110301639.LAA00435@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id LAA00384 for ; Tue, 30 Oct 2001 11:39:17 -0500 (EST) Received: from mailhost1.dircon.co.uk (mailhost1.dircon.co.uk [194.112.32.65]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id LAA32617 for ; Tue, 30 Oct 2001 11:39:12 -0500 Received: from natkinwkstn (th-en136-181.pool.dircon.co.uk [194.112.54.181]) by mailhost1.dircon.co.uk (8.9.3/8.9.3) with ESMTP id QAA01630 for ; Tue, 30 Oct 2001 16:39:04 GMT Message-ID: <004001c16161$50c3b650$0300000a@natkinwkstn> From: "Nicholas Atkinson" To: "WebDAV" References: Date: Tue, 30 Oct 2001 16:31:07 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2462.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000 Subject: Re: Ideas: GETSRC & MULTIPUT Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5504 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi there Is there any documentation available which describes what Microsoft are doing with their Translate Header? (I have tried the archive of this list but the search facility is not working). Does the Apache web server support something similar? nik ----- Original Message ----- From: "Julian Reschke" To: "Clemm, Geoff" ; "WebDAV" Sent: 29 October 2001 21:35 Subject: RE: Ideas: GETSRC & MULTIPUT > Geoff, > > I'd like to see how the DAV:dst in WebDAV can support what Microsoft is > doing with their Translate header (namely, having the source and the dynamic > content at the same URL). > > See also my comments in > > > > Julian > > > -----Original Message----- > > From: w3c-dist-auth-request@w3.org > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff > > Sent: Monday, October 29, 2001 10:18 PM > > To: WebDAV > > Subject: RE: Ideas: GETSRC & MULTIPUT > > > > > > Why isn't GETSRC just a GET on the DAV:dst of the DAV:source property? > > (If it is just a shorthand for this, I'm against the redundant marshalling > > of this request through a new method). > > > > As for MULTIPUT, that sounds fine to me, but it should be accompanied by > > a MULTIGET, which would allow reading of a resource and its metadata in > > one transaction. > > > > Cheers, > > Geoff > > > > -----Original Message----- > > From: Jim Whitehead [mailto:ejw@cse.ucsc.edu] > > Sent: Monday, October 29, 2001 3:14 PM > > To: WebDAV > > Subject: Ideas: GETSRC & MULTIPUT > > > > > > I'm interested in the list's thoughts on two ideas for DAV improvements: > > > > The first is to introduce a GETSRC method to support access to the > > unprocessed source of a resource. This would decouple the dynamic response > > of a resource (GET) from its static source (GETSRC). > > > > The second is to introduce the MULTIPUT method to support "PUT with > > PROPPATCH" scenarios. MULTIPUT would accept some subset of multipart MIME > > packages and atomically write them to the server. This would support the > > update of a resource and its metadata in one transaction. > > > > - Jim > > > From w3c-dist-auth-request@w3.org Tue Oct 30 12:37:32 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08345 for ; Tue, 30 Oct 2001 12:37:31 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA07068; Tue, 30 Oct 2001 12:35:29 -0500 (EST) Resent-Date: Tue, 30 Oct 2001 12:35:29 -0500 (EST) Resent-Message-Id: <200110301735.MAA07068@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id MAA07010 for ; Tue, 30 Oct 2001 12:35:23 -0500 (EST) Received: from front1.mail.megapathdsl.net (front1.mail.megapathdsl.net [66.80.60.31]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id MAA11627 for ; Tue, 30 Oct 2001 12:35:22 -0500 Received: from [64.139.0.223] (HELO beaver) by front1.mail.megapathdsl.net (CommuniGate Pro SMTP 3.4.8a) with SMTP id 10008266; Tue, 30 Oct 2001 09:34:26 -0800 From: "Lisa Dusseault" To: "Clemm, Geoff" , "WebDAV" Date: Tue, 30 Oct 2001 09:34:02 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <3906C56A7BD1F54593344C05BD1374B103F8AD10@SUS-MA1IT01> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Subject: RE: Ideas: GETSRC & MULTIPUT Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5505 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit You know, you can turn that idea on its head and it makes sense. With dynamic content and something like a GETSRC method, the only thing you can do with the dynamically-generated content is GET it. This is the way a lot of dynamic content actually seem to work: e.g. the file is the .jsp file, the "real" content of the file is pretty much the source code. Permissions on the .jsp file determine who can read or write it. With this view of things, PROPPATCH, PROPFIND, PUT all affect the .jsp file. The only thing that differs between a .jsp file and a .txt file in the same directory is that an innocent GET request returns dynamic content in the .jsp case. I agree that when dynamic content is generated certain other ways, e.g. multiple source files which compile together to form a program that is run out of cgi-bin, the situation is much different. Both GETSRC and the Microsoft solution (translate header) are not very well suited to the multiple-source-file solution on the face of it. I guess it's an issue that sometimes it makes most sense to use the same URL for both source and result, and sometimes it makes most sense not to. lisa > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff > Sent: October 29, 2001 1:55 PM > To: WebDAV > Subject: RE: Ideas: GETSRC & MULTIPUT > > > In general, I believe having distinct URL's for different resources > is far superior to defining new methods. How would you set access > control on the "source" resource? How would you get the properties of > the "source" resource? If you have a URL for the source resource, > all this is straightforward ... but if you have something like a GETSRC > method, the only thing you can do with the "source" is get its content. > > Cheers, > Geoff > > -----Original Message----- > From: Julian Reschke [mailto:julian.reschke@gmx.de] > Sent: Monday, October 29, 2001 4:35 PM > To: Clemm, Geoff; WebDAV > Subject: RE: Ideas: GETSRC & MULTIPUT > > > Geoff, > > I'd like to see how the DAV:dst in WebDAV can support what Microsoft is > doing with their Translate header (namely, having the source and > the dynamic > content at the same URL). > > See also my comments in > > > > Julian > > > -----Original Message----- > > From: w3c-dist-auth-request@w3.org > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff > > Sent: Monday, October 29, 2001 10:18 PM > > To: WebDAV > > Subject: RE: Ideas: GETSRC & MULTIPUT > > > > > > Why isn't GETSRC just a GET on the DAV:dst of the DAV:source property? > > (If it is just a shorthand for this, I'm against the redundant > marshalling > > of this request through a new method). > > > > As for MULTIPUT, that sounds fine to me, but it should be accompanied by > > a MULTIGET, which would allow reading of a resource and its metadata in > > one transaction. > > > > Cheers, > > Geoff > > > > -----Original Message----- > > From: Jim Whitehead [mailto:ejw@cse.ucsc.edu] > > Sent: Monday, October 29, 2001 3:14 PM > > To: WebDAV > > Subject: Ideas: GETSRC & MULTIPUT > > > > > > I'm interested in the list's thoughts on two ideas for DAV improvements: > > > > The first is to introduce a GETSRC method to support access to the > > unprocessed source of a resource. This would decouple the > dynamic response > > of a resource (GET) from its static source (GETSRC). > > > > The second is to introduce the MULTIPUT method to support "PUT with > > PROPPATCH" scenarios. MULTIPUT would accept some subset of > multipart MIME > > packages and atomically write them to the server. This would support the > > update of a resource and its metadata in one transaction. > > > > - Jim > > From w3c-dist-auth-request@w3.org Tue Oct 30 13:07:10 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09568 for ; Tue, 30 Oct 2001 13:07:09 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA11217; Tue, 30 Oct 2001 13:04:28 -0500 (EST) Resent-Date: Tue, 30 Oct 2001 13:04:28 -0500 (EST) Resent-Message-Id: <200110301804.NAA11217@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id NAA11197 for ; Tue, 30 Oct 2001 13:04:23 -0500 (EST) Received: from front2.mail.megapathdsl.net (front2.mail.megapathdsl.net [66.80.60.30]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id NAA16707 for ; Tue, 30 Oct 2001 13:04:23 -0500 Received: from [64.139.0.223] (HELO beaver) by front2.mail.megapathdsl.net (CommuniGate Pro SMTP 3.4.8a) with SMTP id 10363316; Tue, 30 Oct 2001 10:03:26 -0800 From: "Lisa Dusseault" To: "Nicholas Atkinson" , "WebDAV" Date: Tue, 30 Oct 2001 10:03:03 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <004001c16161$50c3b650$0300000a@natkinwkstn> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Subject: RE: Ideas: GETSRC & MULTIPUT Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5506 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit I know a little bit about the philosophical design, hope this helps. The "Translate" header is a bit of a mis-nomer. You could probably more accurately call it "Author-Mode" and switch the true/false values. When Translate is not present, or Translate: F, it means the client is a browser, or an authoring client in browsing mode. The HTTP/WebDAV should therefore apply appropriate transforms, such as generating dynamic content. When Translate: T is in the request, it means the client is in authoring mode. The most clearly affected method is GET because the source is returned instead of the transformed result, but the header is actually sent on all requests from the client at this time. This means that a server is potentially capable of using the Translate header to decide how to calculate 'getcontentlength' in response to a PROPFIND -- it may even be possible to calculate the length of the source when Translate is True and the length of the generated content when Translate is False. I believe that for many methods (COPY, MOVE) the behaviour is the same whether Translate is T or F. Note however that the information about what mode the client is in is still there, should the server ever need to make a distinction between two behaviours on the basis of whether the client is authoring or not. Obviously this doesn't work directly for CGI scripts or (this is the Microsoft solution after all) ISAPI. I think it's possible to turn on WebDAV access to the files that compose one of these types of Web plugins, but since the model is more file access than Web access, these would have different URLs and there might not be a clear way of seeing the link between the dynamic URL and the source URLs. Still, there hasn't been clear demand from customers for shared authoring of these types of things right on the Web server -- I'd suspect most serious Web programming teams would use a real source server, perhaps a staging sever, and a production server, all with different URLs. Lisa > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Nicholas Atkinson > Sent: October 30, 2001 8:31 AM > To: WebDAV > Subject: Re: Ideas: GETSRC & MULTIPUT > > > Hi there > > Is there any documentation available which describes what Microsoft are > doing with their Translate Header? (I have tried the archive of this list > but the search facility is not working). > > Does the Apache web server support something similar? > > nik > > ----- Original Message ----- > From: "Julian Reschke" > To: "Clemm, Geoff" ; "WebDAV" > Sent: 29 October 2001 21:35 > Subject: RE: Ideas: GETSRC & MULTIPUT > > > > Geoff, > > > > I'd like to see how the DAV:dst in WebDAV can support what Microsoft is > > doing with their Translate header (namely, having the source and the > dynamic > > content at the same URL). > > > > See also my comments in > > > > > > > > Julian > > > > > -----Original Message----- > > > From: w3c-dist-auth-request@w3.org > > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff > > > Sent: Monday, October 29, 2001 10:18 PM > > > To: WebDAV > > > Subject: RE: Ideas: GETSRC & MULTIPUT > > > > > > > > > Why isn't GETSRC just a GET on the DAV:dst of the DAV:source property? > > > (If it is just a shorthand for this, I'm against the redundant > marshalling > > > of this request through a new method). > > > > > > As for MULTIPUT, that sounds fine to me, but it should be > accompanied by > > > a MULTIGET, which would allow reading of a resource and its > metadata in > > > one transaction. > > > > > > Cheers, > > > Geoff > > > > > > -----Original Message----- > > > From: Jim Whitehead [mailto:ejw@cse.ucsc.edu] > > > Sent: Monday, October 29, 2001 3:14 PM > > > To: WebDAV > > > Subject: Ideas: GETSRC & MULTIPUT > > > > > > > > > I'm interested in the list's thoughts on two ideas for DAV > improvements: > > > > > > The first is to introduce a GETSRC method to support access to the > > > unprocessed source of a resource. This would decouple the dynamic > response > > > of a resource (GET) from its static source (GETSRC). > > > > > > The second is to introduce the MULTIPUT method to support "PUT with > > > PROPPATCH" scenarios. MULTIPUT would accept some subset of multipart > MIME > > > packages and atomically write them to the server. This would > support the > > > update of a resource and its metadata in one transaction. > > > > > > - Jim > > > > > From w3c-dist-auth-request@w3.org Tue Oct 30 14:15:13 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11932 for ; Tue, 30 Oct 2001 14:15:13 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA24768; Tue, 30 Oct 2001 14:12:40 -0500 (EST) Resent-Date: Tue, 30 Oct 2001 14:12:40 -0500 (EST) Resent-Message-Id: <200110301912.OAA24768@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id OAA24737 for ; Tue, 30 Oct 2001 14:12:34 -0500 (EST) Received: from opentext.com (drawbridge.opentext.com [204.138.115.3]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id OAA28204 for ; Tue, 30 Oct 2001 14:12:34 -0500 Received: from mt2k (212.dhcp.ott.opentext.com [192.168.130.212]) by opentext.com (8.9.3/8.9.3) with SMTP id OAA15383; Tue, 30 Oct 2001 14:11:30 -0500 Reply-To: From: "Matt Timmermans" To: "'Jim Whitehead'" , "'Roy T. Fielding'" Cc: "'WebDAV'" Date: Tue, 30 Oct 2001 14:11:27 -0500 Message-ID: <000901c16176$ad991310$d482a8c0@mt2k> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: Subject: RE: Ideas: GETSRC & MULTIPUT Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5507 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit GETSRC is evil: 1) It's strictly less powerful than the source link. What are you going to do about synthetic _collections_, and multiple synthetic resources with the same source, or a synthetic document with a source collection (i.e., a compiled source tree)? 2) It's incompatible with existing DAV clients. Everyone who writes a DAV client has to know that they must set Translate: F if they want to work properly with IIS. You'd force everyone to retrofit to call GETSRC in place of GET. 3) It doesn't even satisfy Microsoft's requirements. Translate: F works for all methods, not just GET. 4) It breaks the symmetry that HTTP requires between GET and PUT. > -----Original Message----- > From: Jim Whitehead > > The source link was never implemented. > > The two reasons I have heard for this (there may be more) are: I think the big one is that, in most cases, it isn't necessary. If the web site has a source tree, it's not unreasonable to expect the web site authors to know where that source tree is. They are the authors, after all. > (a) Server implementors did not want to handle the namespace > complexity of > automatically creating new areas of the namespace for source > resources. That > is, on most servers, the source resources would be > "synthetic" -- the server > would be making up the URL for the source resource, and would > be managing > interactions with this synthetic resource. There isn't a requirement to automatically synthesize parts of the namespace. In fact, what I can easily do Today does everything but fill in the source links. I just have to map two virtual directories to the same location -- one view tree at http://me.com/* and one source tree at http://me.com/~src/*. On the latter directory, I can disable script execution, grant source editing and browsing permissions, and require stronger authentication. What Today's web servers don't do is fill in the source link, because in most cases they can't know how to do it properly. Oh sure, a Web server might be able to supply a sourcelink for /cgi/mycgi.exe, but it can't provide a source link for /cgi/mycgi.exe/doc1, because it doesn't know where my CGI gets its information from. Similarly, of course, the Web server can't implement GETSRC on /cgi/mycgi.exe/doc1. It's the CGI's job to fill in those source links if it wants to. > [...] > I think existing client UIs could handle a standard mechanism > to get at 1 source representation for a resource. I do not think they can handle a > mechanism that provides access to multiple source representations. You're right, but a "source representation" is not necessarily an entity body. All we really need is some language that tells a client how to extract a URI for the source from the source link property, i.e., a single source link, or a "main" source link, or some such thing. What the source link gets you is a File/Edit item on the menu when you view the page in a Web browser. The appropriate thing to do when that item is selected is clear if you have a single source link -- you PROPFIND it to determine DAV:resourcetype and DAV:getcontenttype, and then open the link in whatever client application is appropriate for editing that type of resource. If the source resource is a jsp or asp page, then the source file will open in the appropriate editor. If the source resource is a collection, then it will open in your default WebDAV explorer. GETSRC has a much reduced scope. > Efforts > to do so will, like the source link, be ignored. I think it > is instructive > that the only mechanism that has gained any traction so far > is the Translate > header, which provides access to one source representation. That's not all that Translate: does. Translate: F disables script processing. If you PUT to a CGI with Translate: F, you overwrite the CGI. If you leave out the header, then the CGI processes the request. If you PROPFIND mycgi.exe with Translate:F, you get properties of the executable file. Without the header, you might get DAV:resroucetype=DAV:collection and some children. If you PROPFIND mycgi.exe/somedir with Translate: F, you get 404 or 409. If you leave out the header, the CGI might give you the properties of a synthetic DAV-compliant resource. In short, Translate: F and GETSRC are not equivalent in functionality, and MS's decision to use Translate: F does not support adding GETSRC to the RFC. Moving on... There is, however, a real problem with the source link in 2518 -- it's a property, and only works for resources that are DAV-compliant. A CGI, for example, is a simple way to synthesize a Web page. There is no reason for that synthetic resource to be DAV-compliant at all. CGI authors don't want to go through all the trouble of implementing PROPFIND just so they don't have to remember where the source tree is. How many other methods will CGI authors have to implement to convince the browser that it should do a PROPFIND in the first place? If we want to provide a really useful link to source representations, it needs to be a simple header that CGIs can just stick in their responses. We could define the DAV-source: header to point the the "primary source" for that resource. We can keep the existing source link for DAV-compliant synthetic resources if we describe the mapping between the two. From w3c-dist-auth-request@w3.org Tue Oct 30 15:35:34 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13775 for ; Tue, 30 Oct 2001 15:35:34 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA08008; Tue, 30 Oct 2001 15:19:57 -0500 (EST) Resent-Date: Tue, 30 Oct 2001 15:19:57 -0500 (EST) Resent-Message-Id: <200110302019.PAA08008@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id PAA07985 for ; Tue, 30 Oct 2001 15:19:51 -0500 (EST) Received: from inet-mail4.oracle.com (inet-mail4.oracle.com [148.87.2.204]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id PAA07147 for ; Tue, 30 Oct 2001 15:19:51 -0500 Received: from rgmgw1.us.oracle.com (rgmgw1.us.oracle.com [138.1.191.10]) by inet-mail4.oracle.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f9UKBYY18485 for ; Tue, 30 Oct 2001 12:11:34 -0800 (PST) Received: from esedcarlaptop (dhcp-4op7-4op8-east-130-35-171-71.us.oracle.com [130.35.171.71]) by rgmgw1.us.oracle.com (Switch-2.1.3/Switch-2.1.0) with SMTP id f9UKJl226173 for ; Tue, 30 Oct 2001 13:19:47 -0700 (MST) From: "Eric Sedlar" To: "WebDAV" Date: Tue, 30 Oct 2001 12:19:27 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <20011030140829.C26015@io.mds.rmit.edu.au> Subject: RE: GETSRC & MULTIPUT Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5508 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit The fundamental question that must be addressed is whether or not the source resource and the output resource are the same. To me, the question boils down to wanting to have symmetry in my methods. If I call PROPPATCH, I can then use PROPFIND to see the properties I just wrote. We need the same thing for PUT. If I call PUT on a URL, I want a method that gets me back the stuff I just PUT at that URL. Even if I have a script that handles multiple resources, such as a program called "foo.pl", that can handle /cgi-bin/foo.pl AND /cgi-bin/foo.pl/werf the argument doesn't really apply, since generally /cgi-bin/foo.pl/werf will not respond to PUT or PROPPATCH. It's not really a WebDAV resource. Here's what WebDAV really needs: * a method called READ and a method called WRITE * The WRITE method can be used to write the dead properties and contents of a resource in a single atomic transaction. * The READ method can be used to read the dead properties and contents of the resource EXACTLY as stored by the most recent PROPPATCH/PUT/ACL/WRITE method stored them This would address both of the needs that Jim cites. We could also be extra clever and perhaps add another header called Property-Length that specifies the byte length of the property data within the message body, so that we don't have to use multipart/mime encoding for the contents (which can be computationally expensive). --Eric From w3c-dist-auth-request@w3.org Tue Oct 30 16:05:05 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14321 for ; Tue, 30 Oct 2001 16:05:05 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA12012; Tue, 30 Oct 2001 16:03:16 -0500 (EST) Resent-Date: Tue, 30 Oct 2001 16:03:16 -0500 (EST) Resent-Message-Id: <200110302103.QAA12012@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id QAA11988 for ; Tue, 30 Oct 2001 16:03:10 -0500 (EST) Received: from lsmail.office.lightsurf.com (lsmail.office.lightsurf.com [204.30.31.25]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id QAA13465 for ; Tue, 30 Oct 2001 16:03:10 -0500 Received: from urchin (urchin.office.lightsurf.com [10.10.10.133]) by lsmail.office.lightsurf.com (Mirapoint) with SMTP id AAM73237; Tue, 30 Oct 2001 13:03:03 -0800 (PST) Reply-To: From: "Adam Freeman" To: "Eric Sedlar" , "WebDAV" Date: Tue, 30 Oct 2001 13:03:03 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Subject: RE: GETSRC & MULTIPUT Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5509 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello, 1) new methods (GETSRC, READ, WRITE) should be avoided if possible. There are plenty of methods in webdav already. 2) webdav turns a website into a file system. What does webdav seem to be missing? A good clean concept of a soft link. 3) what webdav needs is something analogous to a soft link in a file system. The soft link resource can have a different set of properties than the original resource. 4) if you start from the file system concept, then you think about how webdav should make this look transparent to the client (just like a soft link in the file system would look but it might have a different set of properties on it than another soft link or the original file) 5) Using webdav currently, I could mimic this by using PUT on a .url file (that links to the original source) and then using PROPPATCH on that .url file. PROPFIND then returns a different set of properties for that .url file than the original resource but GET returns the original source bits. This works with mod_dav.so. @m -----Original Message----- From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Eric Sedlar Sent: Tuesday, October 30, 2001 12:19 PM To: WebDAV Subject: RE: GETSRC & MULTIPUT The fundamental question that must be addressed is whether or not the source resource and the output resource are the same. To me, the question boils down to wanting to have symmetry in my methods. If I call PROPPATCH, I can then use PROPFIND to see the properties I just wrote. We need the same thing for PUT. If I call PUT on a URL, I want a method that gets me back the stuff I just PUT at that URL. Even if I have a script that handles multiple resources, such as a program called "foo.pl", that can handle /cgi-bin/foo.pl AND /cgi-bin/foo.pl/werf the argument doesn't really apply, since generally /cgi-bin/foo.pl/werf will not respond to PUT or PROPPATCH. It's not really a WebDAV resource. Here's what WebDAV really needs: * a method called READ and a method called WRITE * The WRITE method can be used to write the dead properties and contents of a resource in a single atomic transaction. * The READ method can be used to read the dead properties and contents of the resource EXACTLY as stored by the most recent PROPPATCH/PUT/ACL/WRITE method stored them This would address both of the needs that Jim cites. We could also be extra clever and perhaps add another header called Property-Length that specifies the byte length of the property data within the message body, so that we don't have to use multipart/mime encoding for the contents (which can be computationally expensive). --Eric From w3c-dist-auth-request@w3.org Tue Oct 30 16:18:55 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14532 for ; Tue, 30 Oct 2001 16:18:55 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA12969; Tue, 30 Oct 2001 16:16:26 -0500 (EST) Resent-Date: Tue, 30 Oct 2001 16:16:26 -0500 (EST) Resent-Message-Id: <200110302116.QAA12969@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id QAA12949 for ; Tue, 30 Oct 2001 16:16:21 -0500 (EST) Received: from inet-mail4.oracle.com (inet-mail4.oracle.com [148.87.2.204]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id QAA15057 for ; Tue, 30 Oct 2001 16:16:22 -0500 Received: from rgmgw1.us.oracle.com (rgmgw1.us.oracle.com [138.1.191.10]) by inet-mail4.oracle.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f9UL87Y19959 for ; Tue, 30 Oct 2001 13:08:07 -0800 (PST) Received: from esedcarlaptop (dhcp-4op7-4op8-east-130-35-171-71.us.oracle.com [130.35.171.71]) by rgmgw1.us.oracle.com (Switch-2.1.3/Switch-2.1.0) with SMTP id f9ULGK222125 for ; Tue, 30 Oct 2001 14:16:20 -0700 (MST) From: "Eric Sedlar" To: "WebDAV" Date: Tue, 30 Oct 2001 13:15:59 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: Subject: RE: GETSRC & MULTIPUT Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5510 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit I'm not sure you really addressed the requirements that Jim has: * atomic read/write of contents & properties * getting the source file for generated content vs. getting the generated output The notion of symbolic links potentially has the problem where GET doesn't return the same stuff as PUT stored, but typically (on a filesystem), you can use read() to get the contents you just did a write() on, even if the pathname is a symbolic link. I guess I don't see symbolic links (or BINDings in the WebDAV parlance) as relevant to this discussion. -----Original Message----- From: Adam Freeman [mailto:afreeman@lightsurf.com] Sent: Tuesday, October 30, 2001 1:03 PM To: Eric Sedlar; WebDAV Subject: RE: GETSRC & MULTIPUT Hello, 1) new methods (GETSRC, READ, WRITE) should be avoided if possible. There are plenty of methods in webdav already. 2) webdav turns a website into a file system. What does webdav seem to be missing? A good clean concept of a soft link. 3) what webdav needs is something analogous to a soft link in a file system. The soft link resource can have a different set of properties than the original resource. 4) if you start from the file system concept, then you think about how webdav should make this look transparent to the client (just like a soft link in the file system would look but it might have a different set of properties on it than another soft link or the original file) 5) Using webdav currently, I could mimic this by using PUT on a .url file (that links to the original source) and then using PROPPATCH on that .url file. PROPFIND then returns a different set of properties for that .url file than the original resource but GET returns the original source bits. This works with mod_dav.so. @m -----Original Message----- From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Eric Sedlar Sent: Tuesday, October 30, 2001 12:19 PM To: WebDAV Subject: RE: GETSRC & MULTIPUT The fundamental question that must be addressed is whether or not the source resource and the output resource are the same. To me, the question boils down to wanting to have symmetry in my methods. If I call PROPPATCH, I can then use PROPFIND to see the properties I just wrote. We need the same thing for PUT. If I call PUT on a URL, I want a method that gets me back the stuff I just PUT at that URL. Even if I have a script that handles multiple resources, such as a program called "foo.pl", that can handle /cgi-bin/foo.pl AND /cgi-bin/foo.pl/werf the argument doesn't really apply, since generally /cgi-bin/foo.pl/werf will not respond to PUT or PROPPATCH. It's not really a WebDAV resource. Here's what WebDAV really needs: * a method called READ and a method called WRITE * The WRITE method can be used to write the dead properties and contents of a resource in a single atomic transaction. * The READ method can be used to read the dead properties and contents of the resource EXACTLY as stored by the most recent PROPPATCH/PUT/ACL/WRITE method stored them This would address both of the needs that Jim cites. We could also be extra clever and perhaps add another header called Property-Length that specifies the byte length of the property data within the message body, so that we don't have to use multipart/mime encoding for the contents (which can be computationally expensive). --Eric From w3c-dist-auth-request@w3.org Tue Oct 30 16:40:48 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15359 for ; Tue, 30 Oct 2001 16:40:47 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA15060; Tue, 30 Oct 2001 16:37:30 -0500 (EST) Resent-Date: Tue, 30 Oct 2001 16:37:30 -0500 (EST) Resent-Message-Id: <200110302137.QAA15060@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id QAA14873 for ; Tue, 30 Oct 2001 16:37:00 -0500 (EST) Received: from sus-ma1it00.rational.com (ext-37184.rational.com [192.229.37.184]) by tux.w3.org (8.9.3/8.9.3) with SMTP id QAA17298 for ; Tue, 30 Oct 2001 16:32:07 -0500 Received: from 192.168.215.70 by sus-ma1it00.rational.com (InterScan E-Mail VirusWall NT); Tue, 30 Oct 2001 16:31:36 -0500 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id <4D31J93M>; Tue, 30 Oct 2001 16:31:36 -0500 Message-ID: <3906C56A7BD1F54593344C05BD1374B103F8AD19@SUS-MA1IT01> From: "Clemm, Geoff" To: WebDAV Date: Tue, 30 Oct 2001 16:31:34 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="windows-1252" Subject: RE: GETSRC & MULTIPUT Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5511 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: As a minor point, "redirect references" are the WebDAV equivalent of symbolic links, while "bindings" are the WebDAV equivalent of hard links. Cheers, Geoff -----Original Message----- From: Eric Sedlar [mailto:eric.sedlar@oracle.com] ... I guess I don't see symbolic links (or BINDings in the WebDAV parlance) as relevant to this discussion. -----Original Message----- From: Adam Freeman [mailto:afreeman@lightsurf.com] Hello, 1) new methods (GETSRC, READ, WRITE) should be avoided if possible. There are plenty of methods in webdav already. 2) webdav turns a website into a file system. What does webdav seem to be missing? A good clean concept of a soft link. 3) what webdav needs is something analogous to a soft link in a file system. The soft link resource can have a different set of properties than the original resource. 4) if you start from the file system concept, then you think about how webdav should make this look transparent to the client (just like a soft link in the file system would look but it might have a different set of properties on it than another soft link or the original file) 5) Using webdav currently, I could mimic this by using PUT on a .url file (that links to the original source) and then using PROPPATCH on that .url file. PROPFIND then returns a different set of properties for that .url file than the original resource but GET returns the original source bits. This works with mod_dav.so. @m -----Original Message----- From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Eric Sedlar Sent: Tuesday, October 30, 2001 12:19 PM To: WebDAV Subject: RE: GETSRC & MULTIPUT The fundamental question that must be addressed is whether or not the source resource and the output resource are the same. To me, the question boils down to wanting to have symmetry in my methods. If I call PROPPATCH, I can then use PROPFIND to see the properties I just wrote. We need the same thing for PUT. If I call PUT on a URL, I want a method that gets me back the stuff I just PUT at that URL. Even if I have a script that handles multiple resources, such as a program called "foo.pl", that can handle /cgi-bin/foo.pl AND /cgi-bin/foo.pl/werf the argument doesn't really apply, since generally /cgi-bin/foo.pl/werf will not respond to PUT or PROPPATCH. It's not really a WebDAV resource. Here's what WebDAV really needs: * a method called READ and a method called WRITE * The WRITE method can be used to write the dead properties and contents of a resource in a single atomic transaction. * The READ method can be used to read the dead properties and contents of the resource EXACTLY as stored by the most recent PROPPATCH/PUT/ACL/WRITE method stored them This would address both of the needs that Jim cites. We could also be extra clever and perhaps add another header called Property-Length that specifies the byte length of the property data within the message body, so that we don't have to use multipart/mime encoding for the contents (which can be computationally expensive). --Eric From w3c-dist-auth-request@w3.org Tue Oct 30 17:05:50 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15822 for ; Tue, 30 Oct 2001 17:05:50 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA17251; Tue, 30 Oct 2001 17:02:42 -0500 (EST) Resent-Date: Tue, 30 Oct 2001 17:02:42 -0500 (EST) Resent-Message-Id: <200110302202.RAA17251@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id RAA17227 for ; Tue, 30 Oct 2001 17:02:35 -0500 (EST) Received: from cats.ucsc.edu (rumpleteazer.ucsc.edu [128.114.129.45]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id RAA20975 for ; Tue, 30 Oct 2001 17:02:35 -0500 Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177]) by cats.ucsc.edu (8.9.3/8.8.4.cats-athena) with SMTP id OAA28399; Tue, 30 Oct 2001 14:04:57 -0800 (PST) From: "Jim Whitehead" To: "Roy T. Fielding" Cc: "WebDAV" Date: Tue, 30 Oct 2001 13:58:36 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <20011030003245.A9518@waka.ebuilt.net> Importance: Normal Subject: RE: Ideas: GETSRC & MULTIPUT Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5512 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Roy Fielding writes: > So the solution is to make it impossibe to edit resources that consist of > multiple sources? That'll really piss off my customer who has spent most > of this year creating a site that is entirely controlled by a content > management system, where each resource consists of a dynamic mapping to a > database entity catalog. Each Web page consists of dozens of > source elements. How would you propose that authoring tools present this scenario to their users? The tool does a PROPFIND, gets back the source property, and finds there are dozens of links. Now what? You could pop up a list of the sources, and say "pick one". But without providing any guidance as to which source corresponds with a particular aspect of the browser-based view, the user doesn't have much guidance on which one to select. It doesn't sound like a compelling user experience. There are two kinds of authoring tools: ones that are structure aware, and ones that are not. Structure-aware tools (i.e., a tool that understands a given page is comprised of N other pieces) will be programmed to know the relationship between sub-elements and the end-user visible Web page, and will have developed a naming convention that it understands. The source property won't provide these tools much value. Structure unaware tools just allow the user to pick a URL and edit it. There is no notion of structure. Such a tool could use the source property to find other parts, but could still only allow a user to pick one of them to individually edit. A person using these tools would eventually need to understand the naming convention used by the parts and the whole. Hence, I'm not convinced the source property, as currently defined, provides much value to any known class of client. There are really several classes here: (a) when the mapping of resource to authorable subparts is 1::many (b) when the mapping of resource to authorable subparts is 1::1 (as with server-side includes), and the authorable rendition of the resource isn't returned by GET (c) when the mapping of resource to authorable subparts is 1::1, and the authorable rendition of the resource *is* returned by GET (e.g., a Word document) Something like "the inverse of PUT" would be handy for case (b). WebDAV only provides good support for cases (c) (Office, Acrobat, drive mappers) & (a) (Go Live, Dreamweaver). > Feel free to define yet another distributed filesystem protocol within any > other working group of the IETF. I'd rather wait until it gets > implemented correctly than reduce the standard to something that doesn't > meet the need. Today, the most frequently used WebDAV client is Web Folders. A valid way to view WebDAV is as a network file system protocol. While this was never my goal, the fact remains that the majority of WebDAV users would never notice if PROPPATCH, LOCK, and UNLOCK were turned off. This is changing as more full-featured collaborative authoring clients become available, and enter into widespread use. But right now, and into the forseeable future, DAV as Web Filesystem is an important user model. - Jim From w3c-dist-auth-request@w3.org Tue Oct 30 17:07:14 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15844 for ; Tue, 30 Oct 2001 17:07:14 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA17328; Tue, 30 Oct 2001 17:04:57 -0500 (EST) Resent-Date: Tue, 30 Oct 2001 17:04:57 -0500 (EST) Resent-Message-Id: <200110302204.RAA17328@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id RAA17308 for ; Tue, 30 Oct 2001 17:04:52 -0500 (EST) Received: from lsmail.office.lightsurf.com (lsmail.office.lightsurf.com [204.30.31.25]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id RAA21237 for ; Tue, 30 Oct 2001 17:04:52 -0500 Received: from urchin (urchin.office.lightsurf.com [10.10.10.133]) by lsmail.office.lightsurf.com (Mirapoint) with SMTP id AAM73396; Tue, 30 Oct 2001 14:04:49 -0800 (PST) Reply-To: From: "Adam Freeman" To: "Eric Sedlar" , "WebDAV" Date: Tue, 30 Oct 2001 14:04:49 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Subject: RE: GETSRC & MULTIPUT Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5513 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit BIND does not behave like a softlink. BIND binds all properties from the linked resource to the original and vice versa. I just went to explorer, created a shortcut to a file. The created date on the shortcut is different than on the original. My point is there should be some properties that can be different on the softlink than on the original and I do not think BIND provides for that. Redirect references suck because the server has to issue a 302 and the client has to make another roundtrip. This could be a problem especially for low network latency and bandwidth situations. I think there was some other kind of reference that would do the trick (indirect reference or something like that) but as far as getting this implemented within RFC 2518??? The link property that is part of RFC 2518 should do what I'm talking about. The only question is which properties are malleable between the softlink and the original. @m -----Original Message----- From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Eric Sedlar Sent: Tuesday, October 30, 2001 1:16 PM To: WebDAV Subject: RE: GETSRC & MULTIPUT I'm not sure you really addressed the requirements that Jim has: * atomic read/write of contents & properties * getting the source file for generated content vs. getting the generated output The notion of symbolic links potentially has the problem where GET doesn't return the same stuff as PUT stored, but typically (on a filesystem), you can use read() to get the contents you just did a write() on, even if the pathname is a symbolic link. I guess I don't see symbolic links (or BINDings in the WebDAV parlance) as relevant to this discussion. -----Original Message----- From: Adam Freeman [mailto:afreeman@lightsurf.com] Sent: Tuesday, October 30, 2001 1:03 PM To: Eric Sedlar; WebDAV Subject: RE: GETSRC & MULTIPUT Hello, 1) new methods (GETSRC, READ, WRITE) should be avoided if possible. There are plenty of methods in webdav already. 2) webdav turns a website into a file system. What does webdav seem to be missing? A good clean concept of a soft link. 3) what webdav needs is something analogous to a soft link in a file system. The soft link resource can have a different set of properties than the original resource. 4) if you start from the file system concept, then you think about how webdav should make this look transparent to the client (just like a soft link in the file system would look but it might have a different set of properties on it than another soft link or the original file) 5) Using webdav currently, I could mimic this by using PUT on a .url file (that links to the original source) and then using PROPPATCH on that .url file. PROPFIND then returns a different set of properties for that .url file than the original resource but GET returns the original source bits. This works with mod_dav.so. @m -----Original Message----- From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Eric Sedlar Sent: Tuesday, October 30, 2001 12:19 PM To: WebDAV Subject: RE: GETSRC & MULTIPUT The fundamental question that must be addressed is whether or not the source resource and the output resource are the same. To me, the question boils down to wanting to have symmetry in my methods. If I call PROPPATCH, I can then use PROPFIND to see the properties I just wrote. We need the same thing for PUT. If I call PUT on a URL, I want a method that gets me back the stuff I just PUT at that URL. Even if I have a script that handles multiple resources, such as a program called "foo.pl", that can handle /cgi-bin/foo.pl AND /cgi-bin/foo.pl/werf the argument doesn't really apply, since generally /cgi-bin/foo.pl/werf will not respond to PUT or PROPPATCH. It's not really a WebDAV resource. Here's what WebDAV really needs: * a method called READ and a method called WRITE * The WRITE method can be used to write the dead properties and contents of a resource in a single atomic transaction. * The READ method can be used to read the dead properties and contents of the resource EXACTLY as stored by the most recent PROPPATCH/PUT/ACL/WRITE method stored them This would address both of the needs that Jim cites. We could also be extra clever and perhaps add another header called Property-Length that specifies the byte length of the property data within the message body, so that we don't have to use multipart/mime encoding for the contents (which can be computationally expensive). --Eric From w3c-dist-auth-request@w3.org Tue Oct 30 17:08:50 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15864 for ; Tue, 30 Oct 2001 17:08:50 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA17556; Tue, 30 Oct 2001 17:06:32 -0500 (EST) Resent-Date: Tue, 30 Oct 2001 17:06:32 -0500 (EST) Resent-Message-Id: <200110302206.RAA17556@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id RAA17526 for ; Tue, 30 Oct 2001 17:06:26 -0500 (EST) Received: from cats.ucsc.edu (rumpleteazer.ucsc.edu [128.114.129.45]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id RAA21378 for ; Tue, 30 Oct 2001 17:06:25 -0500 Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177]) by cats.ucsc.edu (8.9.3/8.8.4.cats-athena) with SMTP id OAA29673; Tue, 30 Oct 2001 14:08:41 -0800 (PST) From: "Jim Whitehead" To: "Lisa Dusseault" , "WebDAV" Date: Tue, 30 Oct 2001 14:02:21 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: Importance: Normal Subject: RE: Ideas: GETSRC & MULTIPUT Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5514 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Lisa Dusseault writes: > This is the way a lot of dynamic content actually seem to work: e.g. the > file is the .jsp file, the "real" content of the file is pretty much the > source code. Permissions on the .jsp file determine who can read or write > it. With this view of things, PROPPATCH, PROPFIND, PUT all > affect the .jsp file. The only thing that differs between a .jsp file > and a .txt file in the same directory is that an innocent GET request > returns dynamic content in the .jsp case. Yes, this is what I had in mind for GETSRC. - Jim From w3c-dist-auth-request@w3.org Tue Oct 30 17:23:47 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16103 for ; Tue, 30 Oct 2001 17:23:46 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA19053; Tue, 30 Oct 2001 17:21:48 -0500 (EST) Resent-Date: Tue, 30 Oct 2001 17:21:48 -0500 (EST) Resent-Message-Id: <200110302221.RAA19053@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id RAA19011 for ; Tue, 30 Oct 2001 17:21:32 -0500 (EST) Received: from lsmail.office.lightsurf.com (lsmail.office.lightsurf.com [204.30.31.25]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id RAA23127 for ; Tue, 30 Oct 2001 17:21:33 -0500 Received: from urchin (urchin.office.lightsurf.com [10.10.10.133]) by lsmail.office.lightsurf.com (Mirapoint) with SMTP id AAM73432; Tue, 30 Oct 2001 14:21:27 -0800 (PST) Reply-To: From: "Adam Freeman" To: "Eric Sedlar" , "WebDAV" Date: Tue, 30 Oct 2001 14:21:27 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Subject: RE: GETSRC & MULTIPUT Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5515 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Actually, I did address these requirements with my 5th point. This was an example of my "hack" to do what you are talking about with the existing mod_dav.so. If you put a .url file that is a link to the original source, doing a proppatch and propfind on this url file is atomic. Doing proppatch and propfind on the original source is atomic as well. Doing a put and get on either should put or get the same source bits. In my opinion, it should not be up to the webdav server to decide what to do with those source bits. This should be proxied through another server or handled by the client. For example, if I have a resource that has been rotated, the webdav server shouldn't do the rotation. This should be done by another server or the client itself. @m -----Original Message----- From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Eric Sedlar Sent: Tuesday, October 30, 2001 1:16 PM To: WebDAV Subject: RE: GETSRC & MULTIPUT I'm not sure you really addressed the requirements that Jim has: * atomic read/write of contents & properties * getting the source file for generated content vs. getting the generated output The notion of symbolic links potentially has the problem where GET doesn't return the same stuff as PUT stored, but typically (on a filesystem), you can use read() to get the contents you just did a write() on, even if the pathname is a symbolic link. I guess I don't see symbolic links (or BINDings in the WebDAV parlance) as relevant to this discussion. -----Original Message----- From: Adam Freeman [mailto:afreeman@lightsurf.com] Sent: Tuesday, October 30, 2001 1:03 PM To: Eric Sedlar; WebDAV Subject: RE: GETSRC & MULTIPUT Hello, 1) new methods (GETSRC, READ, WRITE) should be avoided if possible. There are plenty of methods in webdav already. 2) webdav turns a website into a file system. What does webdav seem to be missing? A good clean concept of a soft link. 3) what webdav needs is something analogous to a soft link in a file system. The soft link resource can have a different set of properties than the original resource. 4) if you start from the file system concept, then you think about how webdav should make this look transparent to the client (just like a soft link in the file system would look but it might have a different set of properties on it than another soft link or the original file) 5) Using webdav currently, I could mimic this by using PUT on a .url file (that links to the original source) and then using PROPPATCH on that .url file. PROPFIND then returns a different set of properties for that .url file than the original resource but GET returns the original source bits. This works with mod_dav.so. @m -----Original Message----- From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Eric Sedlar Sent: Tuesday, October 30, 2001 12:19 PM To: WebDAV Subject: RE: GETSRC & MULTIPUT The fundamental question that must be addressed is whether or not the source resource and the output resource are the same. To me, the question boils down to wanting to have symmetry in my methods. If I call PROPPATCH, I can then use PROPFIND to see the properties I just wrote. We need the same thing for PUT. If I call PUT on a URL, I want a method that gets me back the stuff I just PUT at that URL. Even if I have a script that handles multiple resources, such as a program called "foo.pl", that can handle /cgi-bin/foo.pl AND /cgi-bin/foo.pl/werf the argument doesn't really apply, since generally /cgi-bin/foo.pl/werf will not respond to PUT or PROPPATCH. It's not really a WebDAV resource. Here's what WebDAV really needs: * a method called READ and a method called WRITE * The WRITE method can be used to write the dead properties and contents of a resource in a single atomic transaction. * The READ method can be used to read the dead properties and contents of the resource EXACTLY as stored by the most recent PROPPATCH/PUT/ACL/WRITE method stored them This would address both of the needs that Jim cites. We could also be extra clever and perhaps add another header called Property-Length that specifies the byte length of the property data within the message body, so that we don't have to use multipart/mime encoding for the contents (which can be computationally expensive). --Eric From w3c-dist-auth-request@w3.org Tue Oct 30 19:28:59 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17614 for ; Tue, 30 Oct 2001 19:28:59 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id TAA29703; Tue, 30 Oct 2001 19:26:02 -0500 (EST) Resent-Date: Tue, 30 Oct 2001 19:26:02 -0500 (EST) Resent-Message-Id: <200110310026.TAA29703@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id TAA29677 for ; Tue, 30 Oct 2001 19:25:55 -0500 (EST) Received: from mutley.ebuilt.net (nat.ebuilt.com [209.216.46.200]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id TAA03953 for ; Tue, 30 Oct 2001 19:25:55 -0500 Received: (from root@localhost) by mutley.ebuilt.net (8.11.1/8.11.1) id f9V0PLb21830 for ; Tue, 30 Oct 2001 16:25:21 -0800 Received: from waka.ebuilt.net (IDENT:root@i199.ir.ebuilt.net [10.1.2.199]) by mutley.ebuilt.net (8.11.1/8.11.1) with ESMTP id f9V0PKO21749; Tue, 30 Oct 2001 16:25:20 -0800 Received: (from fielding@localhost) by waka.ebuilt.net (8.11.0/8.11.0) id f9V0MsC02289; Tue, 30 Oct 2001 16:22:54 -0800 Date: Tue, 30 Oct 2001 16:22:54 -0800 From: "Roy T. Fielding" To: Eric Sedlar Cc: WebDAV Message-ID: <20011030162254.A2241@waka.ebuilt.net> References: <20011030140829.C26015@io.mds.rmit.edu.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.20i X-AntiVirus: scanned for viruses by AMaViS 0.2.1-pre3 (http://amavis.org/) Subject: Re: GETSRC & MULTIPUT Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5516 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: On Tue, Oct 30, 2001 at 12:19:27PM -0800, Eric Sedlar wrote: > The fundamental question that must be addressed is whether or not the source > resource and the output resource are the same. To me, the question boils > down to wanting to have symmetry in my methods. If I call PROPPATCH, I can > then use PROPFIND to see the properties I just wrote. We need the same > thing for PUT. If I call PUT on a URL, I want a method that gets me back > the stuff I just PUT at that URL. GET already provides that -- if you can successfully invoke PUT on a resource, then a GET on that same resource will be the stuff that you PUT (assuming no other actions occurred in-between). However, PUT is not allowed on many resources, specifically those resources that only exist as a synthesis of other resources. The source links, which were present in the original HTTP/1.1 proposal and later transformed into a property in 2518, tell the client how it can edit that resource given that authoring on the same URI is not possible, period. ....Roy From w3c-dist-auth-request@w3.org Tue Oct 30 19:34:40 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17738 for ; Tue, 30 Oct 2001 19:34:40 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id TAA00262; Tue, 30 Oct 2001 19:32:56 -0500 (EST) Resent-Date: Tue, 30 Oct 2001 19:32:56 -0500 (EST) Resent-Message-Id: <200110310032.TAA00262@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id TAA00240 for ; Tue, 30 Oct 2001 19:32:51 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id TAA04724 for ; Tue, 30 Oct 2001 19:32:50 -0500 Received: (qmail 4845 invoked by uid 0); 31 Oct 2001 00:32:26 -0000 Received: from pd95354fe.dip.t-dialin.net (HELO lisa) (217.83.84.254) by mail.gmx.net (mp004-rz3) with SMTP; 31 Oct 2001 00:32:26 -0000 From: "Julian Reschke" To: "Roy T. Fielding" , "Eric Sedlar" Cc: "WebDAV" Date: Wed, 31 Oct 2001 01:33:12 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <20011030162254.A2241@waka.ebuilt.net> Subject: RE: GETSRC & MULTIPUT Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5517 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Roy T. Fielding > Sent: Wednesday, October 31, 2001 1:23 AM > To: Eric Sedlar > Cc: WebDAV > Subject: Re: GETSRC & MULTIPUT > > > On Tue, Oct 30, 2001 at 12:19:27PM -0800, Eric Sedlar wrote: > > The fundamental question that must be addressed is whether or > not the source > > resource and the output resource are the same. To me, the > question boils > > down to wanting to have symmetry in my methods. If I call > PROPPATCH, I can > > then use PROPFIND to see the properties I just wrote. We need the same > > thing for PUT. If I call PUT on a URL, I want a method that > gets me back > > the stuff I just PUT at that URL. > > GET already provides that -- if you can successfully invoke PUT on a > resource, then a GET on that same resource will be the stuff that you PUT > (assuming no other actions occurred in-between). > > However, PUT is not allowed on many resources, specifically those > resources > that only exist as a synthesis of other resources. The source > links, which > were present in the original HTTP/1.1 proposal and later transformed into > a property in 2518, tell the client how it can edit that resource > given that > authoring on the same URI is not possible, period. Well, that's interesting to know, but -- from looking at RFC2518 this is just "hear-say". What you say makes sense, but it's certainly not what RFC2518 says (or doesn't say: that when a resource has a source property it can't be PUT to). From w3c-dist-auth-request@w3.org Tue Oct 30 19:57:34 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17949 for ; Tue, 30 Oct 2001 19:57:34 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id TAA01834; Tue, 30 Oct 2001 19:55:59 -0500 (EST) Resent-Date: Tue, 30 Oct 2001 19:55:59 -0500 (EST) Resent-Message-Id: <200110310055.TAA01834@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id TAA01798 for ; Tue, 30 Oct 2001 19:55:51 -0500 (EST) Received: from mutley.ebuilt.net (nat.ebuilt.com [209.216.46.200]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id TAA06738 for ; Tue, 30 Oct 2001 19:55:51 -0500 Received: (from root@localhost) by mutley.ebuilt.net (8.11.1/8.11.1) id f9V0tKA06515 for ; Tue, 30 Oct 2001 16:55:20 -0800 Received: from waka.ebuilt.net (IDENT:root@i199.ir.ebuilt.net [10.1.2.199]) by mutley.ebuilt.net (8.11.1/8.11.1) with ESMTP id f9V0tKO06433; Tue, 30 Oct 2001 16:55:20 -0800 Received: (from fielding@localhost) by waka.ebuilt.net (8.11.0/8.11.0) id f9V0rKQ02400; Tue, 30 Oct 2001 16:53:20 -0800 Date: Tue, 30 Oct 2001 16:53:20 -0800 From: "Roy T. Fielding" To: Julian Reschke Cc: Eric Sedlar , WebDAV Message-ID: <20011030165320.A2378@waka.ebuilt.net> References: <20011030162254.A2241@waka.ebuilt.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.20i X-AntiVirus: scanned for viruses by AMaViS 0.2.1-pre3 (http://amavis.org/) Subject: Re: GETSRC & MULTIPUT Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5518 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: > > On Tue, Oct 30, 2001 at 12:19:27PM -0800, Eric Sedlar wrote: > > > The fundamental question that must be addressed is whether or > > not the source > > > resource and the output resource are the same. To me, the > > question boils > > > down to wanting to have symmetry in my methods. If I call > > PROPPATCH, I can > > > then use PROPFIND to see the properties I just wrote. We need the same > > > thing for PUT. If I call PUT on a URL, I want a method that > > gets me back > > > the stuff I just PUT at that URL. > > > > GET already provides that -- if you can successfully invoke PUT on a > > resource, then a GET on that same resource will be the stuff that you PUT > > (assuming no other actions occurred in-between). > > > > However, PUT is not allowed on many resources, specifically those > > resources > > that only exist as a synthesis of other resources. The source > > links, which > > were present in the original HTTP/1.1 proposal and later transformed into > > a property in 2518, tell the client how it can edit that resource > > given that > > authoring on the same URI is not possible, period. > > Well, that's interesting to know, but -- from looking at RFC2518 this is > just "hear-say". What you say makes sense, but it's certainly not what > RFC2518 says (or doesn't say: that when a resource has a source property it > can't be PUT to). It is theoretically possible for a synthetic resource to be edited by GET and PUT of its representation, assuming that the server is smart enough to derive the individual source changes from the modified representation. However, that is not an issue, since from the client's perspective it seems to be editing a static representation. The whole point of the source links is to allow the server to tell the client that "Hey, I'm not smart enough to figure out editing on this interface, you need to go over to this list of things and edit them individually." That is a condition of interoperability that is necessary to communicate between the server and client due to the nature of Web resources. There are other conditions in which the source URI would differ from the "normal" GET URI, such as when authoring is only allowed on a staging server. In those cases as well, a GETSRC method or Translate header field simply will not work. I cannot understand why it would even be considered. I am sure that the RFC can be improved to spell this out in more detail, but that is not unusual for this stage of the standardization process. ....Roy It doesn't say that, and nothing I said implies it would. You are reversing the implication of what I said, which isn't valid logic. From w3c-dist-auth-request@w3.org Wed Oct 31 05:43:46 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09768 for ; Wed, 31 Oct 2001 05:43:46 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id FAA02297; Wed, 31 Oct 2001 05:41:26 -0500 (EST) Resent-Date: Wed, 31 Oct 2001 05:41:26 -0500 (EST) Resent-Message-Id: <200110311041.FAA02297@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id FAA02272 for ; Wed, 31 Oct 2001 05:41:01 -0500 (EST) Received: from kurgan.lyra.org (test.webdav.org [198.144.203.199] (may be forged)) by tux.w3.org (8.9.3/8.9.3) with ESMTP id FAA24142 for ; Wed, 31 Oct 2001 05:41:00 -0500 Received: (from gstein@localhost) by kurgan.lyra.org (8.9.3/8.9.3) id CAA08262; Wed, 31 Oct 2001 02:47:01 -0800 X-Authentication-Warning: kurgan.lyra.org: gstein set sender to gstein@lyra.org using -f Date: Wed, 31 Oct 2001 02:47:01 -0800 From: Greg Stein To: Nicholas Atkinson Cc: WebDAV Message-ID: <20011031024701.M6221@lyra.org> Mail-Followup-To: Nicholas Atkinson , WebDAV References: <004001c16161$50c3b650$0300000a@natkinwkstn> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <004001c16161$50c3b650$0300000a@natkinwkstn>; from nik@casawana.com on Tue, Oct 30, 2001 at 04:31:07PM -0000 X-URL: http://www.lyra.org/greg/ Subject: Re: Ideas: GETSRC & MULTIPUT Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5519 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: On Tue, Oct 30, 2001 at 04:31:07PM -0000, Nicholas Atkinson wrote: > Hi there > > Is there any documentation available which describes what Microsoft are > doing with their Translate Header? (I have tried the archive of this list > but the search facility is not working). > > Does the Apache web server support something similar? Nope. Generally, I recommend that people set up a second set of URLs to access the CGIs, PHP scripts, or whatever. That second space can disable the CGI/PHP/whatever execution and treat all content as text/plain. The URLs can be somewhere else on the server, or a different port. Cheers, -g -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Wed Oct 31 05:57:00 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09869 for ; Wed, 31 Oct 2001 05:56:59 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id FAA02922; Wed, 31 Oct 2001 05:55:14 -0500 (EST) Resent-Date: Wed, 31 Oct 2001 05:55:14 -0500 (EST) Resent-Message-Id: <200110311055.FAA02922@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id FAA02885 for ; Wed, 31 Oct 2001 05:55:06 -0500 (EST) Received: from kurgan.lyra.org (test.webdav.org [198.144.203.199] (may be forged)) by tux.w3.org (8.9.3/8.9.3) with ESMTP id FAA25233 for ; Wed, 31 Oct 2001 05:55:04 -0500 Received: (from gstein@localhost) by kurgan.lyra.org (8.9.3/8.9.3) id DAA08273; Wed, 31 Oct 2001 03:00:43 -0800 X-Authentication-Warning: kurgan.lyra.org: gstein set sender to gstein@lyra.org using -f Date: Wed, 31 Oct 2001 03:00:43 -0800 From: Greg Stein To: Jim Whitehead Cc: "Roy T. Fielding" , WebDAV Message-ID: <20011031030043.N6221@lyra.org> Mail-Followup-To: Jim Whitehead , "Roy T. Fielding" , WebDAV References: <20011030003245.A9518@waka.ebuilt.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from ejw@cse.ucsc.edu on Tue, Oct 30, 2001 at 01:58:36PM -0800 X-URL: http://www.lyra.org/greg/ Subject: Re: Ideas: GETSRC & MULTIPUT Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5520 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: On Tue, Oct 30, 2001 at 01:58:36PM -0800, Jim Whitehead wrote: >... > There are two kinds of authoring tools: ones that are structure aware, and > ones that are not. Structure-aware tools (i.e., a tool that understands a > given page is comprised of N other pieces) will be programmed to know the > relationship between sub-elements and the end-user visible Web page, and > will have developed a naming convention that it understands. The source > property won't provide these tools much value. > > Structure unaware tools just allow the user to pick a URL and edit it. There > is no notion of structure. Such a tool could use the source property to find > other parts, but could still only allow a user to pick one of them to > individually edit. A person using these tools would eventually need to > understand the naming convention used by the parts and the whole. > > Hence, I'm not convinced the source property, as currently defined, provides > much value to any known class of client. That is an improper conclusion. You only posed two cases, and both deal with a resource that is comprised of many other resources. If a resource is produced from a *single* item, then the source property is of tremendous value. That unaware tool will take me there, and I can get my editing done. Nothing complicated there, yet incredibly useful. > There are really several classes here: > > (a) when the mapping of resource to authorable subparts is 1::many > (b) when the mapping of resource to authorable subparts is 1::1 (as with > server-side includes), and the authorable rendition of the resource isn't > returned by GET > (c) when the mapping of resource to authorable subparts is 1::1, and the > authorable rendition of the resource *is* returned by GET (e.g., a Word > document) > > Something like "the inverse of PUT" would be handy for case (b). WebDAV only > provides good support for cases (c) (Office, Acrobat, drive mappers) & (a) > (Go Live, Dreamweaver). WebDAV also provides quite fine support for (b). I've got empirical evidence of people doing exactly that. I've done it myself. Don't warp your cases so that you can draw a desired conclusion :-) The 1::many problem is hard, sure. But the existing solution provides structure for that. Maybe you could argue some extensions, such as a DAV:displayname for each link pair, but the concept is sound. > > Feel free to define yet another distributed filesystem protocol within any > > other working group of the IETF. I'd rather wait until it gets > > implemented correctly than reduce the standard to something that doesn't > > meet the need. > > Today, the most frequently used WebDAV client is Web Folders. A valid way > to view WebDAV is as a network file system protocol. While this was never my > goal, the fact remains that the majority of WebDAV users would never notice > if PROPPATCH, LOCK, and UNLOCK were turned off. This is changing as more > full-featured collaborative authoring clients become available, and enter > into widespread use. But right now, and into the forseeable future, DAV as > Web Filesystem is an important user model. Okay, fine. But what does that have to do with GETSRC or the source property? Great -- so people can browse... what about it? The capabilities offered by Web Folders are also going to be independent of the source stuff we're discussing. Cheers, -g -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Wed Oct 31 10:11:37 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21214 for ; Wed, 31 Oct 2001 10:11:37 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id KAA21159; Wed, 31 Oct 2001 10:07:23 -0500 (EST) Resent-Date: Wed, 31 Oct 2001 10:07:23 -0500 (EST) Resent-Message-Id: <200110311507.KAA21159@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id KAA21132 for ; Wed, 31 Oct 2001 10:07:04 -0500 (EST) Received: from opentext.com (drawbridge.opentext.com [204.138.115.3]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id KAA18532 for ; Wed, 31 Oct 2001 10:07:04 -0500 Received: (from root@localhost) by opentext.com (8.9.3/8.9.3) id KAA09248; Wed, 31 Oct 2001 10:06:25 -0500 Received: from 022.dhcp2.liv.opentext.com(172.17.2.22) by krusty.wl.opentext.com via smap (V2.1) id xma009230; Wed, 31 Oct 01 10:06:22 -0500 From: "Dylan Barrell" To: "Eric Sedlar" , "WebDAV" Date: Wed, 31 Oct 2001 10:05:47 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: Subject: RE: GETSRC & MULTIPUT Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5521 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit In order to frame this discussion of what we need to do we need to agree on the requirements. So lets step up a level and talk about the requirements that need to be met before we get embroiled in a discussion on implementation as most of these arguments could then be settled by referring back to the requirements. @Jim - how to we proceed on this type of activity? --Dylan > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Eric Sedlar > Sent: Tuesday, October 30, 2001 4:16 PM > To: WebDAV > Subject: RE: GETSRC & MULTIPUT > > > I'm not sure you really addressed the requirements that Jim has: > > * atomic read/write of contents & properties > * getting the source file for generated content vs. getting the generated > output > > The notion of symbolic links potentially has the problem where GET doesn't > return the > same stuff as PUT stored, but typically (on a filesystem), you can use > read() to get > the contents you just did a write() on, even if the pathname is a symbolic > link. > > I guess I don't see symbolic links (or BINDings in the WebDAV parlance) as > relevant > to this discussion. > > -----Original Message----- > From: Adam Freeman [mailto:afreeman@lightsurf.com] > Sent: Tuesday, October 30, 2001 1:03 PM > To: Eric Sedlar; WebDAV > Subject: RE: GETSRC & MULTIPUT > > Hello, > 1) new methods (GETSRC, READ, WRITE) should be avoided if > possible. There > are plenty of methods in webdav already. > 2) webdav turns a website into a file system. What does webdav > seem to be > missing? A good clean concept of a soft link. > 3) what webdav needs is something analogous to a soft link in a file > system. The soft link resource can have a different set of > properties than > the original resource. > 4) if you start from the file system concept, then you think about how > webdav should make this look transparent to the client (just like a soft > link in the file system would look but it might have a different set of > properties on it than another soft link or the original file) > 5) Using webdav currently, I could mimic this by using PUT on a .url file > (that links to the original source) and then using PROPPATCH on that .url > file. PROPFIND then returns a different set of properties for that .url > file than the original resource but GET returns the original source bits. > This works with mod_dav.so. > @m > > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Eric Sedlar > Sent: Tuesday, October 30, 2001 12:19 PM > To: WebDAV > Subject: RE: GETSRC & MULTIPUT > > > The fundamental question that must be addressed is whether or not > the source > resource and the output resource are the same. To me, the question boils > down to wanting to have symmetry in my methods. If I call > PROPPATCH, I can > then use PROPFIND to see the properties I just wrote. We need the same > thing for PUT. If I call PUT on a URL, I want a method that gets me back > the stuff I just PUT at that URL. > > Even if I have a script that handles multiple resources, such as a program > called "foo.pl", that can handle > > /cgi-bin/foo.pl > > AND > > /cgi-bin/foo.pl/werf > > the argument doesn't really apply, since generally > /cgi-bin/foo.pl/werf will > not respond to PUT or PROPPATCH. It's not really a WebDAV resource. > > Here's what WebDAV really needs: > > * a method called READ and a method called WRITE > * The WRITE method can be used to write the dead properties and > contents of > a resource in a single atomic transaction. > * The READ method can be used to read the dead properties and contents of > the resource EXACTLY as stored by the most recent PROPPATCH/PUT/ACL/WRITE > method stored them > > This would address both of the needs that Jim cites. We could > also be extra > clever and perhaps add another header called Property-Length that > specifies > the byte length of the property data within the message body, so that we > don't have to use multipart/mime encoding for the contents (which can be > computationally expensive). > > --Eric > > From w3c-dist-auth-request@w3.org Wed Oct 31 15:01:38 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29366 for ; Wed, 31 Oct 2001 15:01:38 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA00278; Wed, 31 Oct 2001 14:58:34 -0500 (EST) Resent-Date: Wed, 31 Oct 2001 14:58:34 -0500 (EST) Resent-Message-Id: <200110311958.OAA00278@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id OAA00239 for ; Wed, 31 Oct 2001 14:58:25 -0500 (EST) Received: from cats.ucsc.edu (rumpleteazer.ucsc.edu [128.114.129.45]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id OAA28491 for ; Wed, 31 Oct 2001 14:58:23 -0500 Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177]) by cats.ucsc.edu (8.9.3/8.8.4.cats-athena) with SMTP id MAA01004 for ; Wed, 31 Oct 2001 12:00:12 -0800 (PST) From: "Jim Whitehead" To: "WebDAV" Date: Wed, 31 Oct 2001 11:53:41 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Subject: Re: Ideas: GETSRC & MULTIPUT Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5522 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Accidentally caught by the spam filter. I have added "Kantz@wegalink.de" to the accept2 list, so future emails from this address will go straight through. - Jim -----Original Message----- From: Eckhard Kantz [mailto:Kantz@wegalink.de] Sent: Wednesday, October 31, 2001 5:15 AM To: WebDAV Subject: [Moderator Action] Re: Ideas: GETSRC & MULTIPUT ...sorry for the length of my comment: RFC2518 is most likely the biggest step towards balancing the data transfer between an Internet client and server that went mainly from a server to clients since HTTP was introduced. This is a great progress. There seems to be missing only the tiny detail of how to get access to the source of synthetic web pages in order to satisfy all needs that exist in this context. The more and the longer I try to understand the basic problem behind this discussion the more I came to the conclusion that this can not be the full truth and that it might by necessary to look at it from a higher position, maybe the well known 60.000 feet view. Then it becomes obvious that each URL is actually understood as a source of information, as a unique resource, finally as a unique resource locator that is used to retrive all those information. In this sense all worked fine in the past since a server had full control over the information output of a request against a URL in the server's name space. The only impact that a client had on the presentation of the output was at most to specify some parameters that the server could use or not use. This has changed dramatically with WebDAV. Now the client is said to be the supervisor. The client should be able to specify exactly what the server returns as response to a request. The basic expectation is symmetry, that is at least all what can be PUT to the server can also be GET from the server. Unfortunately, there is only this one URL that exists for a given collection (!!) of information which is usually presented to an end user by a browser application. The question is how to control the different output on protocol level. Actually, what output concepts are needed? (1) The conventional GET output, which is nowadays most often dynamic (2) The one script that is responsible for generating the dynamic output in case this is the only source file (3) A collection of multiple source components (script, database cells, maybe also included pictures, audio, video,...) Additionally one could think of the following: (4) Generate output in a certain format that the client would like to work on, (e.g. html, doc, pdf, txt, ...) in case the server is capable of presenting the information in that format based on preprocessed files or based on converting files on-the-fly (5) Generate output dependent on the capabilities of the presentation device (screen 1024x768, screen 320x200, color/black-white, WAP,...) (6) Generate output dependent on time in order to get past presentations of a web page (e.g. stock market, sports results, weather forcast...) what should not be a major problem for any server having those past data normally stored in its database over a certain period of time It seems that all those wishes could be fulfilled immediately if a given URL could definitely be opened as a collection rather than a file. In this case dependent on what the server is capable of delivering to clients the output could be as follows: GET /foo/bar -> would return dynamic output as usual /foo/bar -> would show all components that the server is willing to expose to clients, e.g. /foo/bar/jsp-script -> the java server page script that generates /foo/bar /foo/bar/doc -> the content of /foo/bar as a MSWord document /foo/bar/pdf -> the content of /foo/bar as a PDF document /foo/bar/database/field1 -> the content of the database field 1 that is used to generate /foo/bar dynamically /foo/bar/database/field2 -> the content of the database field 2 that is used to generate /foo/bar dynamically /foo/bar/logo.jpg -> the logo.jpg picture that is contained in the /foo/bar page /foo/bar/welcome.wav -> the sound file that is played when the page is opened in a browser /foo/bar/wap -> the content of /foo/bar but customized to the capabilities of a WAP display /foo/bar/2001-10-30 -> the content of /foo/bar but generated with past data from October, 30th /foo/bar/2001-10-30/13:05 -> the content of /foo/bar but generated with past data from October, 30th at 1:05 p.m. /foo/bar/2001-10-30/13:05/pdf -> the content of /foo/bar but generated with past data from October, 30th at 1:05 p.m. and converted to a PDF file This all would be feasible with current 2518 if there was a possibility to open a URL explicitly as a collection rather than as a file. In this case all other methods like PUT, PROPPATCH, .. would work as usual since there are separate URLs available for each component of a dynamically generated HTML page. Maybe that some of those components do not make sense to PUT them back to the server, e.g. historical data or an output format that was generated on-the-fly. Fortunately 2518 offers the PROPFIND method to obtain all resource names of a collection as well as their properties. The only thing to do was to let servers expose dynamically generated URLs for all components of a URL during a PROPFIND with depth=1 and to handle PUT and PROPPATCH against those dynamic URLs. Actually, I am not sure if this is the best solution one could think of. It should not be overseen that the URL namespace is double used. However, since the server controls the namespace from its root downwards anyway this might be acceptable. On the other hand there might be better proposals that provide to the desired goal of reading and writing components of a web resource in a specifiable format. Eckhard