From w3c-dist-auth-request@w3.org Tue Feb 1 11:12:30 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23507 for ; Tue, 1 Feb 2000 11:12:30 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id LAA22340; Tue, 1 Feb 2000 11:07:42 -0500 (EST) Resent-Date: Tue, 1 Feb 2000 11:07:42 -0500 (EST) Resent-Message-Id: <200002011607.LAA22340@www19.w3.org> Message-ID: <8E3CFBC709A8D21191A400805F15E0DBD2458C@crte147.wc.eso.mc.xerox.com> From: "Slein, Judith A" To: "'Geoffrey M. Clemm'" , w3c-dist-auth@w3.org Date: Tue, 1 Feb 2000 11:07:02 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Bodies of redirect reference resources Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4009 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list I was just looking back at my notes from the November 1999 IETF meeting. This change was made in response to comments there that we should make redirect references analogous to collections with respect to an entity-body. It should be allowed. Someone might find a use for it in some application even if we haven't thought of one. This would mean that PUT and GET (and, it was suggested, POST) would work with Apply-To-RR. My own preference would be to return to our earlier position that redirect references cannot have content. GET and PUT must fail with Apply-To-RR. I think this would be less confusing. --Judy > -----Original Message----- > From: Geoffrey M. Clemm [mailto:geoffrey.clemm@rational.com] > Sent: Sunday, January 30, 2000 11:45 PM > To: w3c-dist-auth@w3.org > Subject: Re: Bodies of redirect reference resources > > > From: Joe Orton > > To me, the "reference resource" should be a resource in > its own right: a > conceptual thingy which say "No, go to URI Y instead", > when you apply HTTP > methods to it. > > I agree. > > If you are trying to store an entity-body at URI X along > with this RR, then that is two separate resources, one > which has the "No, > go to URI Y instead" semantics, and one which has the > standard "I can > store an entity-body with PUT and give it back with GET" semantics. > > The presence of properties makes this a bit more ambiguous. > If you try > to get the properties of X, it will say "no, go to URI Y > instead". But > the RR X does have properties of its own, that you can obtain with the > Apply-To-RR header. By analogy, it would be reasonable for X to have > an entity-body that you can obtain with the Apply-To-RR header. > This doesn't convince me that RR resources should have entity-bodies, > but it is argument that it is reasonable to do so. > > Unix symlinks have precedent again here: you can't store a > file in a > symlink. Windows shortcuts are the same, I expect. > > Yes. I think this is a good argument against giving them a body ... > people will find this confusing, and experience in other > domains indicate > that an entity body is not needed or appropriate for references. > > > Is there a need to store an extra resource along with every RR > > resource? > > > > The extra resource is minimally needed to store the > information about > > what other resource to redirect to. > > What "information about the other resource" do you want to > store? Why > can't you store it in the properties of the RR? To me the > only vital > information you want to store in the RR is the target of > the reference, > which you have as the DAV:reftarget property. > > I misunderstood you the first time. By "extra resource", I meant the > RR resource itself. You were talking about an extra resource > *in addition* > to the RR resource. I agree that there is no need for an > extra resource > beyond the RR resource. But the RR resource could have an > entity body, > in addition to its properties. > > > We could do any of: > > - get rid of the "an RR resource can have a body" statement > > - get rid of this statement and change the example to say > > the PUT MUST fail. > > - keep the statement, and change the example to say the PUT > > updates the body of the RR resource. > > > That's one vote for choice #3. Anyone else? > > Either you misunderstood, or miscounted :) > > Neither ... mistyped (:-). > > I vote #2: get rid of any mention of "resource body", > and have PUT + GET fail with 4xx if the Apply-To-RR header > is included. > > So we've got a vote for *2*. Anyone else? > > Cheers, > Geoff > From w3c-dist-auth-request@w3.org Tue Feb 1 11:36:28 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24390 for ; Tue, 1 Feb 2000 11:36:27 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id LAA23208; Tue, 1 Feb 2000 11:29:07 -0500 (EST) Resent-Date: Tue, 1 Feb 2000 11:29:07 -0500 (EST) Resent-Message-Id: <200002011629.LAA23208@www19.w3.org> Message-ID: <8E3CFBC709A8D21191A400805F15E0DBD2458D@crte147.wc.eso.mc.xerox.com> From: "Slein, Judith A" To: "'Joe Orton'" , w3c-dist-auth@w3.org Date: Tue, 1 Feb 2000 11:28:43 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Minor nits for redirectref-02 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4010 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list > -----Original Message----- > From: Joe Orton [mailto:joe@orton.demon.co.uk] > Sent: Wednesday, January 26, 2000 5:17 PM > To: w3c-dist-auth@w3.org > Subject: Minor nits for redirectref-02 > > > 1) In the MKRESOURCE response status codes, 423 Locked and 507 > Insufficient storage are included; this seems unnecessary. > 2518 specifies > what these mean. You can't include the full set of valid > status codes in > responses to MKRESOURCE, else you'd have to include all the > normal HTTP > codes too, so why not just stick to new or changed codes? > If anyone finds the inclusion of 423 and 507 helpful, I'd just as leave keep them. Greg has indicated that he does think it's useful to mention existing response codes that might be expected and the circumstances that might cause them to be returned. > 2) MKRESOURCE responses "SHOULD NOT be cached" implies there > are odd cases > when it's okay to cache them, is this right? I know there was no discussion of this issue among the authors of the Redirect References spec. The definition of MKRESOURCE also appears in the DeltaV spec, for which it was originally drafted. Geoff, was there any discussion of SHOULD NOT vs. MUST NOT in the DeltaV working group? Unless there was some good reason for making the weaker statement, we should probably change it to MUST NOT in both specs. > > joe > From w3c-dist-auth-request@w3.org Tue Feb 1 12:51:49 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26729 for ; Tue, 1 Feb 2000 12:51:48 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA25896; Tue, 1 Feb 2000 12:47:30 -0500 (EST) Resent-Date: Tue, 1 Feb 2000 12:47:30 -0500 (EST) Resent-Message-Id: <200002011747.MAA25896@www19.w3.org> Date: Tue, 1 Feb 2000 12:47:07 -0500 From: gclemm@atria.com (Geoffrey M. Clemm) Message-Id: <10002011747.AA01618@tantalum> To: w3c-dist-auth@w3.org Cc: ejw@ics.uci.edu X-Sun-Charset: US-ASCII Subject: RE: Minor nits for redirectref-02 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4011 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list There has been no discussion of this issue in the versioning design team. I personally see no problem with the change from "SHOULD NOT" to "MUST NOT". I believe the wording was originally from Jim Whitehead. Jim? Cheers, Geoff > From w3c-dist-auth-request@w3.org Tue Feb 1 11:29 EST 2000 > > > -----Original Message----- > > From: Joe Orton [mailto:joe@orton.demon.co.uk] > > Sent: Wednesday, January 26, 2000 5:17 PM > > To: w3c-dist-auth@w3.org > > Subject: Minor nits for redirectref-02 > > > > > > 1) In the MKRESOURCE response status codes, 423 Locked and 507 > > Insufficient storage are included; this seems unnecessary. > > 2518 specifies > > what these mean. You can't include the full set of valid > > status codes in > > responses to MKRESOURCE, else you'd have to include all the > > normal HTTP > > codes too, so why not just stick to new or changed codes? > > > > If anyone finds the inclusion of 423 and 507 helpful, I'd just as leave keep > them. Greg has indicated that he does think it's useful to mention existing > response codes that might be expected and the circumstances that might cause > them to be returned. > > > 2) MKRESOURCE responses "SHOULD NOT be cached" implies there > > are odd cases > > when it's okay to cache them, is this right? > > I know there was no discussion of this issue among the authors of the > Redirect References spec. The definition of MKRESOURCE also appears in the > DeltaV spec, for which it was originally drafted. Geoff, was there any > discussion of SHOULD NOT vs. MUST NOT in the DeltaV working group? Unless > there was some good reason for making the weaker statement, we should > probably change it to MUST NOT in both specs. > > > > > joe > > > > From w3c-dist-auth-request@w3.org Tue Feb 1 14:03:49 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29122 for ; Tue, 1 Feb 2000 14:03:48 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA28922; Tue, 1 Feb 2000 13:59:26 -0500 (EST) Resent-Date: Tue, 1 Feb 2000 13:59:26 -0500 (EST) Resent-Message-Id: <200002011859.NAA28922@www19.w3.org> Message-ID: <8E3CFBC709A8D21191A400805F15E0DBD2458E@crte147.wc.eso.mc.xerox.com> From: "Slein, Judith A" To: "'Joe Orton'" , w3c-dist-auth@w3.org Date: Tue, 1 Feb 2000 13:58:58 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Relative URIs in DAV:reftarget Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4012 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list The general tenor of your comments here seems right to me. The whole idea of redirect references is supposed to be that the server never actually has to follow them to their targets. It's not required to guarantee their integrity; it never has to check whether DAV:reftarget actually maps to a resource. They're supposed to be very simple for servers to support using just the 302 capabilities that they already have. My assumption would be that the server just uses the value of DAV:reftarget that is passed in with a MKRESOURCE request exactly as it appears there, and treats DAV:reftarget as a dead property. It's up to the client whether it passes in an absolute or a relative URI. For some applications, like the one you describe where whole hierarchies tend to be moved, a relative URI is preferable. For others, where individual resources tend to get moved, an absolute URI may be preferable. Yes, the server does have to resolve any relative URIs in DAV:reftarget to absolute URIs when it returns the Location header. It sounds as if all this needs clarification in Section 9. > -----Original Message----- > From: Joe Orton [mailto:joe@orton.demon.co.uk] > Sent: Saturday, January 29, 2000 4:48 PM > To: w3c-dist-auth@w3.org > Subject: Relative URIs in DAV:reftarget > > > Section 9 of redirectref-02 talks about resolving relative URI's in > DAV:reftarget. > > It talks about resolving them in the context of a MKRESOURCE > request, and > gives an example of this, but I'm not sure why. This implies > to me that > when a client submits a MKRESOURCE with a relative URI, the > server will > resolve that URI immediately and store it in DAV:reftarget as > an absolute > URI? > > Of course, if you MOVE the reference resource, this is an > important issue: > does the reftarget still point to the same place as before (if it was > resolved at the time of MKRESOURCE), or is it now used > relative to the new > URI of the RR? > > IMO the latter behaviour is strongly desired: if you have a deep > collection heirarchy with some relative cross-referencing amongst the > leaves of the tree, you want them to still work if you rename > a top-level > collection. Unix symlinks are like this if you want some > precedence. (I'm > not sure, but I don't think you can store relative targets in Windows > "shortcuts"?) > > I think the most important point about relative URIs in > DAV:reftarget is > that they must be resolved by the server when it returns the Location > header in a 302 response, since this must be absolute. Other > than that, > the value of this property should be pretty opaque to the server, just > like any other dead property? > > joe > From w3c-dist-auth-request@w3.org Tue Feb 1 16:11:42 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03775 for ; Tue, 1 Feb 2000 16:11:40 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA05236; Tue, 1 Feb 2000 16:07:07 -0500 (EST) Resent-Date: Tue, 1 Feb 2000 16:07:07 -0500 (EST) Resent-Message-Id: <200002012107.QAA05236@www19.w3.org> Message-ID: <7DE119D3D0E15543874F7561EECBDBED02619E3C@BEG.platinum.corp.microsoft.com> From: Yaron Goland To: "'Jim Whitehead'" , WebDAV WG Date: Tue, 1 Feb 2000 13:05:46 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: WG Last Call: Redirect Reference Resources Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4013 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list I would like to formally object to this last call. I apologize for the delay in objecting but I am just now managing to dig my way out of my e-mail after having to fly off to Israel for a family emergency. A last call is an extremely time consuming process requiring members of this WG, who are all volunteers, to turn their attentions to the careful review of the specification and the production of thoughtful comments. In this case, however, the very people who are best qualified to review the redirect draft are the very same people who are currently in the process of providing a review of the bind spec. By issuing a last call we are demanding that individuals, who are for the most part already using what little spare time they have to review the bind spec, also somehow find time to review the redirect reference draft. Given the large number of substantive issues that have already been generated by the BIND spec, given that these issues have already generated several significant alterations to the language of the BIND spec and given that we are barely half way through these issues I believe it is inappropriate now ask the members of this working group to split their focus and provide their full attention to the redirect draft. As such I ask that this last call be postponed until we have finished going through the issues on BIND. Yaron > -----Original Message----- > From: Jim Whitehead [mailto:ejw@ics.uci.edu] > Sent: Tue, January 25, 2000 11:35 AM > To: WebDAV WG > Subject: WG Last Call: Redirect Reference Resources > > > > *** WORKING GROUP LAST CALL FOR COMMENTS *** > > WEBDAV REDIRECT REFERENCE RESOURCES SPECIFICATION > > > http://www.ics.uci.edu/pub/ietf/webdav/collection/draft-ietf-w > ebdav-redirect > ref-protocol-02.txt > > This is the final call for comments from the working group on > the WebDAV > Redirect Reference Resources protocol specification, > draft-ietf-webdav-binding-protocol-02. This last call period begins > immediately, and ends February 22, 2000, at midnight, US > Pacific time. This > allows 4 weeks for review of this specification. > > At the end of the last call period, a new draft will be > issued that resolves > comments raised during the last call period. Depending on > the scope of > changes, there will follow either an immediate call for rough > consensus > (very few changes), or a second last call period (significant > changes). Once > the document represents the rough consensus of the working > group, I will > submit this document to the Internet Engineering Steering > Group (IESG) for > their approval. IESG review involves a (minimum) two week > public last call > for comments review period. This IESG-initiated last call period is in > addition to the working group last call period. > > This document is intended to be a "Proposed Standard". > Quoting from RFC > 2026, "The Internet Standards Process -- Revision 3": > > The entry-level maturity for the standards track is "Proposed > Standard". A specific action by the IESG is required to move a > specification onto the standards track at the "Proposed Standard" > level. > > A Proposed Standard specification is generally stable, has resolved > known design choices, is believed to be well-understood, > has received > significant community review, and appears to enjoy enough community > interest to be considered valuable. However, further experience > might result in a change or even retraction of the specification > before it advances. > > Usually, neither implementation nor operational experience is > required for the designation of a specification as a Proposed > Standard. However, such experience is highly desirable, and will > usually represent a strong argument in favor of a Proposed Standard > designation. > > Many details on the procedures used to develop an IETF > standard can be found > in RFC 2026, available at: > > ftp://ftp.ietf.org/rfc/rfc2026.txt > > If there are any procedural questions or concerns, please do > not hesitate to > contact me, or raise an issue on the list. > > Notes: > > 1) This specification is one of three that have been > developed in tandem, > the other two being the WebDAV Bindings Protocol, > , which just finished > a working group > last call for comments period on January 24, and the Ordered > Collections > Protocol, draft-ietf-webdav-ordering-protocol-02. The > Ordered Collections > Protocol will begin a working group last call for comments period > immediately following the end of this last call period, on > February 23, > 2000. If you wish, you may submit comments on the Ordered Collections > protocol and the Redirect References protocol together during > the present > last call period. > > 2) If you've been waiting for a "stable" version of the > specification before > performing a review, wait no longer. This is it. Assuming the > specification receives only positive feedback, or mostly > minor comments, it > will be submitted to the IESG for approval with no further WG > last call > periods. You should treat this as your last opportunity to > provide feedback > on the specification. Review the specification NOW. > > > - Jim Whitehead > Chair, IETF WEBDAV Working Group > From w3c-dist-auth-request@w3.org Tue Feb 1 16:12:44 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03842 for ; Tue, 1 Feb 2000 16:12:42 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA05308; Tue, 1 Feb 2000 16:08:30 -0500 (EST) Resent-Date: Tue, 1 Feb 2000 16:08:30 -0500 (EST) Resent-Message-Id: <200002012108.QAA05308@www19.w3.org> From: jamsden@us.ibm.com X-Lotus-FromDomain: IBMUS To: w3c-dist-auth@w3.org Message-ID: <85256878.0073F531.00@d54mta03.raleigh.ibm.com> Date: Tue, 1 Feb 2000 16:03:26 -0500 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Atomic Delete and reflecting implementation details in the protocol Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4014 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Just a couple of thoughts on the atomic delete issue. What interests me most is the ability to leverage WebDAV as a standard protocol for mapping multiple client applications to multiple repository managers. This is what interoperability means. In the interest of maximizing the number of available clients, it might also be useful to consider other protocols as candidates for this mapping, in particular the clients that already use these protocols. Managing this many-to-many association cannot be done without work. WebDAV provides us with a place to do this work, but doesn't eliminate it. Knowledge about existing repository managers, file systems, and existing protocols will help us minimize the work required for integration, but also won't eliminate it. There will always be compromises that must be made, and some of them may result in servers that have more or less capability than others. When faced with conflicts, the WebDAV protocol should focus on supporting use cases that have broad user value rather than yield to the implementation details of a particular repository. This is a balance that requires judgment, negotiation, and compromise. So while I appreciate the fact that the Microsoft file system is the most common one in use today, and that it doesn't support binding to collections or atomic delete for good reasons, I don't feel that it is necessarily in the best interests of the WebDAV community to simply adopt the NTFS file system semantics as WebDAV semantics. It is not necessary to have a 1-1 correspondence between the underlying repository and WebDAV semantics. The protocol provides a place to map the WebDAV model to the underlying repository model. This layer will be thick or thin depending on the magnitude of the differences in world views, but in my experience it hasn't been that difficult to build. It is the opportunity to do this work that gives WebDAV its greatest value, not necessarily its ability to avoid the work. As far as delete is concerned, I think delete should simply remove a binding from its parent collection. If there are no other bindings, the server is free to garbage collect or not. If there are other bindings, then they will still work as expected. The protocol does not expose the difference between "real" internal members and bindings. The real resources are only accessible through bindings, and are never accessed directly through the protocol. So it seems to me that delete can always be atomic as it only ever deletes one thing. How, when, and if the garbage is collected is not visible to clients, and since candidates for garbage collection have no other bindings, clients can't access them, and it doesn't matter when they are deleted. How a server maps bindings to its underlying store is also not visible to clients. This could be a simple reflection in the file system, or use a relational database, or do different things for different resources if the WebDAV server supports multiple repository managers. Relying on a 1-1 correspondence between WebDAV resources and a manifestation in the file system would seriously limit WebDAV's appeal. If a repository manager supports multiple protocols, and the protocols are not done through protocol translators to WebDAV or some other common protocol, then a conflict between the protocols could arise. It is the responsibility of the protocol implementers on the shared repository to resolve these conflicts. We cannot reflect them back up into the WebDAV protocol as this would couple the protocol with a particular repository implementation which would in turn limit interoperability and WebDAV adoption. From w3c-dist-auth-request@w3.org Tue Feb 1 17:12:56 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07055 for ; Tue, 1 Feb 2000 17:12:55 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA08820; Tue, 1 Feb 2000 17:08:35 -0500 (EST) Resent-Date: Tue, 1 Feb 2000 17:08:35 -0500 (EST) Resent-Message-Id: <200002012208.RAA08820@www19.w3.org> From: Jim Whitehead To: Yaron Goland , WebDAV WG Date: Tue, 1 Feb 2000 14:03:59 -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) In-Reply-To: <7DE119D3D0E15543874F7561EECBDBED02619E3C@BEG.platinum.corp.microsoft.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Subject: RE: WG Last Call: Redirect Reference Resources Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4015 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit Yaron, First, thank you for sharing your concerns, and also for your diligence in reviewing the Bindings Protocol specification. It's clear to me that you are concerned about whether you will be able to find the time to do a similarly careful job reviewing the Redirect References protocol -- I feel it would be a shame if you were not able to do so. As you might imagine, when considering whether to hold the last call on the Redirect References specifiation, I did give thought to whether this would overly burden the working group given the ongoing discussion of the Binding Protocol. I give my rationale for holding the last call below. The purpose of the last call period is to elicit comments on the specification in order to determine whether it is ready to be advanced to the IESG for consideration as a Proposed Standard. Since the current last call period is four weeks long, and the Redirect References specification is only 27 pages long, I felt this would provide adequate time for review, even by harried IETF volunteers. In contrast, let me note that the WebDAV Distributed Authoring Protocol had an initial last call period of 3 weeks, despite being longer than the Binding Protocol and Redirect References Protocol combined. (Remember this? http://lists.w3.org/Archives/Public/w3c-dist-auth/1998JanMar/0020.html) Since we are currently one week into the four week last call period, it appears there is plenty of time left for working group members to review the specification and post comments. To date, there has been one set of review comments posted to the list by Joe Orton, which is right on track with the number of comments received on the Bindings specification as of one (or even two, if you want to discount the holidays) weeks into that document's last call process. However, your concerns are due not just to the last call of the Redirect References protocol, but to the simultaneous discussions on the last call comments for the Binding protocol, and the Redirect References last call. To this I will note that during the last call on the Bindings Protocol, there were also many other mailing list messages, the existence of which did not harm the last call process. On the other hand, the WebDAV mailing list is currently on track for its busiest quarter ever, with 241 messages exchanged so far in 2000, likely to exceed the highest number ever recorded, of 366 between July and September of last year. So if you're having a hard time keeping up with list email, it may be due to the record volume of mail. :-) Personally, I take this as a good sign that the working group is still active, and capable of handling significant work tasks. As Chair, my preference is to continue with the last call on the Redirect References protocol. The process appears to be on-track, and, excepting your one email, I have received no other evidence it might be broken. Given your concerns, and my desire to ensure you have the ability to perform a thorough review of the specification, I might be convinced to extend the last call period, but I would be hard pressed to extend it for more than a week. If other members of the working group who are considering reviewing the Redirect References specification also feel that they will not have sufficient time to do so in the last call period, please let me know, or post your concerns to the mailing list. - Jim Whitehead Chair, IETF WebDAV Working Group Yaron Goland writes: > I would like to formally object to this last call. I apologize > for the delay in objecting but I am just now managing to dig > my way out of my e-mail after having to fly off to Israel for > a family emergency. > > A last call is an extremely time consuming process requiring > members of this WG, who are all volunteers, to turn their > attentions to the careful review of the specification and the > production of thoughtful comments. > > In this case, however, the very people who are best qualified to > review the redirect draft are the very same people who are > currently in the process of providing a review of the bind spec. > By issuing a last call we are demanding that individuals, who > are for the most part already using what little spare time they > have to review the bind spec, also somehow find time to review the > redirect reference draft. > > Given the large number of substantive issues that have already been > generated by the BIND spec, given that these issues have already generated > several significant alterations to the language of the BIND spec and given > that we are barely half way through these issues I believe it is > inappropriate now ask the members of this working group to split > their focus and provide their full attention to the redirect draft. > > As such I ask that this last call be postponed until we have > finished going through the issues on BIND. From w3c-dist-auth-request@w3.org Wed Feb 2 05:10:44 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02398 for ; Wed, 2 Feb 2000 05:10:44 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id FAA28452; Wed, 2 Feb 2000 05:05:59 -0500 (EST) Resent-Date: Wed, 2 Feb 2000 05:05:59 -0500 (EST) Resent-Message-Id: <200002021005.FAA28452@www19.w3.org> Message-Id: <4.1.20000202105752.00bd6220(null)> X-Sender: (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Wed, 02 Feb 2000 11:03:50 +0100 To: w3c-dist-auth@w3.org From: Jim Davis Cc: LMM@acm.org, abe@yavin4.de Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: PARC PyDAV server returned to operation Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4016 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list The PyDAV server at Xerox PARC is once more in operation. (The host machine was down while being upgraded from SunOS to Linux) See http://sandbox.xerox.com/webdav/ As far as I know, we are still awaiting final legal permission from Xerox to make the source code available. From w3c-dist-auth-request@w3.org Wed Feb 2 12:50:51 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16675 for ; Wed, 2 Feb 2000 12:50:48 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA12795; Wed, 2 Feb 2000 12:46:03 -0500 (EST) Resent-Date: Wed, 2 Feb 2000 12:46:03 -0500 (EST) Resent-Message-Id: <200002021746.MAA12795@www19.w3.org> From: Jim Whitehead To: WebDAV WG Date: Wed, 2 Feb 2000 09:41:34 -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.2314.1300 Importance: Normal Subject: Binding protocol issues list Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4017 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit Judy Slein has produced a list of the issues raised during the last call on the Binding Protocol. This issues list is available off the WebDAV WG home page: http://www.ics.uci.edu/pub/ietf/webdav/, at URL: http://www.ics.uci.edu/pub/ietf/webdav/collection/bind-issues.html Thank you Judy! - Jim From w3c-dist-auth-request@w3.org Wed Feb 2 16:19:56 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21695 for ; Wed, 2 Feb 2000 16:19:56 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA20616; Wed, 2 Feb 2000 16:14:59 -0500 (EST) Resent-Date: Wed, 2 Feb 2000 16:14:59 -0500 (EST) Resent-Message-Id: <200002022114.QAA20616@www19.w3.org> Date: Wed, 2 Feb 2000 21:14:14 +0000 From: Joe Orton To: "Slein, Judith A" Cc: w3c-dist-auth@w3.org Message-ID: <20000202211414.F527@ankh.dunno.local> Mail-Followup-To: "Slein, Judith A" , w3c-dist-auth@w3.org References: <8E3CFBC709A8D21191A400805F15E0DBD2458C@crte147.wc.eso.mc.xerox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <8E3CFBC709A8D21191A400805F15E0DBD2458C@crte147.wc.eso.mc.xerox.com>; from JSlein@crt.xerox.com on Tue, Feb 01, 2000 at 11:07:02AM -0500 Subject: Re: Bodies of redirect reference resources Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4018 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list > I was just looking back at my notes from the November 1999 IETF meeting. > This change was made in response to comments there that we should make > redirect references analogous to collections with respect to an entity-body. I'm not sure I understand this: PUT is undefined/disallowed on a collection, and GET on a collection is defined to return "something or other"... not very analogous to the entity-body storing GET/PUT behaviour for RR resources? joe From w3c-dist-auth-request@w3.org Wed Feb 2 17:00:27 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22518 for ; Wed, 2 Feb 2000 17:00:26 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA21542; Wed, 2 Feb 2000 16:55:57 -0500 (EST) Resent-Date: Wed, 2 Feb 2000 16:55:57 -0500 (EST) Resent-Message-Id: <200002022155.QAA21542@www19.w3.org> Message-ID: <8E3CFBC709A8D21191A400805F15E0DBD24591@crte147.wc.eso.mc.xerox.com> From: "Slein, Judith A" To: Yaron Goland , w3c-dist-auth@w3.org Date: Wed, 2 Feb 2000 16:55:39 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: WebDAV Bindings - Issue Yaron.ApplePieToo Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4019 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list This is a resend to encourage the mailing list to comment on this proposed language. The authors are considering whether to replace Section 9 of the Bindings spec with one or the other of these passages: ---------- Proposal 1 Here's some text that doesn't mention static / dynamic. It doesn't make the simple, idealized statement that we wanted for static resources, but maybe it says enough to be useful: "This section describes the interaction of bindings with those HTTP methods not yet explicitly discussed. The semantics of the methods GET, HEAD, PUT, POST and OPTIONS are specified in [HTTP]. The semantics of PROPFIND, PROPPATCH, and MKCOL are specified in [WebDAV]. "For these methods, no new complexities are introduced by allowing explicit creation of multiple bindings to the same resource. However, the introduction of the BIND method will make it more common for multiple URIs to map to the same resource. As a result, the introduction of the BIND method may point up complexities that were already possible, but occurred only rarely in the past. "In particular, when there are multiple URI mappings to the same resource, it is possible for the resource's behavior in response to GET, HEAD, PROPFIND, etc., to be sensitive to the URI that was used to make the request. For example, the Request-URI may appear in the response entity body for GET on a particular resource, in which case the response entity body produced by that resource will differ depending upon which URI was used to make the request. "The only way for a client to determine whether two URIs map to the same resource is by retrieving and comparing the DAV:resourceid property defined in the following section." --------- Proposal 2 "This section describes the interaction of bindings with those HTTP methods not yet explicitly discussed. The semantics of the methods GET, HEAD, PUT, POST and OPTIONS are specified in [HTTP]. The semantics of PROPFIND, PROPPATCH, and MKCOL are specified in [WebDAV]. "For these methods, no new complexities are introduced by allowing explicit creation of multiple bindings to the same resource. However, the introduction of the BIND method will make it more common for multiple URIs to map to the same resource. When these methods are applied to the same resource using different Request-URIs, the rules for their behavior depend upon whether the resource is static or dynamic. "A static resource is one that always produces the same response to the same method with identiical parameters. "A dynamic resource is one that may produce different responses for different submissions of the same method with identical parameters. "In reality, a single resource may respond statically to some requests, but dynamically to others. However, for a pure static resource, these methods obey the folowing rule: "o A method submitted through one URI mapping, on success, MUST produce the same results as the same method, with the same headers and entity body, submitted through any other URI mapping to the same resource. "When applied to dynamic resources, it is not possible to state any such rule. For any method, a dynamic resource may be sensitive to the URI mapping used to access it. The resource may produce different results depending upon which URI mapping was used to submit the request." --Judy Judith A. Slein Xerox Corporation jslein@crt.xerox.com (716)422-5169 800 Phillips Road 105/50C Webster, NY 14580 From w3c-dist-auth-request@w3.org Wed Feb 2 17:01:19 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22587 for ; Wed, 2 Feb 2000 17:01:18 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA21609; Wed, 2 Feb 2000 16:56:37 -0500 (EST) Resent-Date: Wed, 2 Feb 2000 16:56:37 -0500 (EST) Resent-Message-Id: <200002022156.QAA21609@www19.w3.org> From: Jim Whitehead To: WebDAV WG Date: Wed, 2 Feb 2000 13:52:09 -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.2314.1300 Importance: Normal Subject: Bindings Protocol Teleconf Minutes Feb 2, 2000 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4020 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit Minutes from the February 2, 2000 Binding Protocol teleconference are available online at: http://www.ics.uci.edu/pub/ietf/webdav/collection/dt/Minutes000202.txt - Jim From w3c-dist-auth-request@w3.org Wed Feb 2 20:12:54 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24465 for ; Wed, 2 Feb 2000 20:12:51 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id UAA28289; Wed, 2 Feb 2000 20:08:33 -0500 (EST) Resent-Date: Wed, 2 Feb 2000 20:08:33 -0500 (EST) Resent-Message-Id: <200002030108.UAA28289@www19.w3.org> Message-ID: <7DE119D3D0E15543874F7561EECBDBED02619E3F@BEG.platinum.corp.microsoft.com> From: Yaron Goland To: "'Joe Orton'" , w3c-dist-auth@w3.org Date: Wed, 2 Feb 2000 17:07:58 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Subject: Why IE's Web Folders are accessed through File/Open Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4021 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list O.k., I admit it, I am the person responsible for the awful file/open check box UI in Web Folders in IE. It is all my fault. Throw rotten tomatoes my way. All of us at MS tried to come up with a better solution. The ways to improve Web Folders in IE fell into two types - 1) Enable people, only by typing in a URL to tell the system that they want a PROPFIND view 2) Put in a switch to allow people, once they are at a site, to flip between GET/PROPFIND We were, unfortunately, not able to achieve either of these goals for the reasons I will outline below. This is why we ended up with the file/open UI. It was the best thing we could come up with. There are however, two features that we did put in. The first makes it possible in IE 5.0 to markup a HTML anchor tag so that when clicked it will do a PROPFIND rather than a GET. The beauty of this feature is that if the HTML is displayed on a non-IE 5.0 system then the extra text will be ignored and the anchor will work as a normal GET anchor. Please see http://msdn.microsoft.com/workshop/author/behaviors/overview/webfolder.asp for details. The second is that when you have navigated to a Web Folder you can use the favorites menu to create a favorite to it. That way, in the future, you can get back to the site through favorites rather than file/open. Note that this favorite doesn't work across machines so if you send it to a friend it probably won't work. This feature is actually a side effect of how Web Folders is implemented. Our first goal, to enable people to just type in a URL and have that URL navigate to a web folder, failed because we couldn't find a reliable way to tell if a URL should be resolved as a PROPFIND or a GET. The first trick we tried was to say that if a URL ended in a "/" then we would try to do a PROPFIND. If the PROPFIND failed then we would do a GET. The problem is that http://foo.com/bar/, for example, is a legal name and something a user would very likely want to do a GET on. Can you imagine their confusion when they get some weird icon filled page rather than their normal homepage? We could hear the support phone lines ringing. The next suggestion was to use a "." at the end of a HTTP URL as an indicator that one should navigate to a PROPFIND. Everyone liked this one a bit better because even though a HTTP URL could technically end in a "." it is sort of traditional to treat "." as meaning "this directory". Note, this is not the standard. As defined in RFC 2396 the character "." only has special meaning in the context of a relative URI. Of course it didn't hurt that IIS doesn't allow resources to have the name ".". Unfortunately we had to abandon this idea as well because it turns out that Office strips "." at the end of HTTP URLs thinking that they are periods at the end of a sentence. This was necessary to prevent confusion when users typed a HTTP URL at the end of a sentence. There is, btw, a way to get around this parsing. If you enclose your HTTP URL in "<" ">" then Office will still recognize the HTTP URL and thus highlight it but won't strip the "." at the end. However this still presented the problem that a user could type a HTTP URL into IE such as http://foo.com/bar/. and then copy/paste it into an e-mail message and their friend at the other end would click on it and not get the same experience because Outlook would strip the ".". Again, we could hear the support phone lines ringing. We gave some thought to perhaps using an illegal HTTP URL character to indicate that one should do a PROPFIND instead of a GET but it seemed like a truly awful idea to depend on illegal behavior. This is exactly the sort of thing that destroys interoperability and annihilates processing paths. So this idea was rejected. The last idea to be considered, which I admit responsibility for, was to introduce a new type of URL, dav:. Any time we saw a dav: URL we would do a PROPFIND. Ignoring the obvious conflict this would introduce with WebDAV's use of the dav: URL (we could have used webdav:) everyone really hated the idea of having two different schemes for the same protocol. Nobody liked https, for example. While I wasn't enamored with this idea I felt it was practical. However people were very concerned about what would happen when someone sent a friend a webdav: URL and nothing happened when the friend (on a non-MS system or using older MS software) clicked on it. For example, what was liked about the first two proposals was that on down level systems one still got the GET behavior. This was considered a critical feature in order to enable a smooth transition between the WebDAV and non-WebDAV worlds. Also people really hated the idea of introducing yet another URL type. Users barely are able to deal with HTTP URLs. Asking them to figure out when to use HTTP and when to use DAV just seemed to be too much. Also the IE UI guys went absolutely insane at the mere suggestion that a DAV: URL could appear in the address bar. They too could hear the support phone lines ringing as people demanded to know what the hell a DAV URL was and where the HTTP URL had gone to. So this idea was also killed off. The real issue is that a URL points at something but tells you nothing about how to interact with it. It is a noun without a verb. The reason we were running into so much trouble was that we were trying to verbify the noun. What we really need is a two-part system. XML could do a good job here. One could use a piece of XML to say things like "Go to this URL and perform this Action". Of course having users type in XML was too much to ask. We could, of course, try to put in a helper UI (say a wizard) but even that was a bit much to ask. The general feeling was that we should be trying to have users type in less URLs rather than making entering URLs even more complex. I talked with our usability people about this problem and they told me that according to their lab tests the majority of users could not type in a URL at all. They couldn't use the address bar. They couldn't see an Ad with a URL then type that URL into their browser. All these users can do is click on URLs, not type them in. This has lead to situations where sysadmins, if they want to tell a user their file share, will just send an e-mail with a link to the file share. The user will then live out of that e-mail. Every time they want to get to their files they will find that e-mail, open it and click on the link. This is why it is so critical to have home pages with lots of links, up front and easily available. Users won't type in links. So once someone sends them a homepage in e-mail they will continue to go back to that homepage to find everything. So clearly trying to solve the problem by inventing URL tricks wasn't going to buy us much in the case of the majority of our users. I still wanted to at least do the DAV: URL, if only for power users and other early adopters, but I didn't have the time or resources left to deliver the feature. One idea that was considered was enhancing the right click menu on HTTP URLs to allow the user to select GET or PROPFIND behavior. The idea is that you could type in a HTTP URL, right click on it and then select how you wanted the HTTP URL resolved. However adding this to the right click menu was non-trivial. Still, it does set up the stage for the second set of proposals - a switch. The original argument was that we should add an option to IE's view menu to allow the user to switch to a PROPFIND view. The problem with this proposal is that 99.9% of the time for the lifespan of IE 5.0 the resource would not be a WebDAV resource. This meant that we would have a feature in the menu that didn't work most of the time. Anyone but me hearing the support phone lines ringing? (Yes, I know, I should have a check up for these ringing sounds =) So the idea of just putting a "directory" view choice on the view menu was ruled out. However we decided to be smart. What if we knew that the resource that was currently displayed was a WebDAV resource? That is, what if the user typed in http://www.webdav.org and we already knew that http://www.webdav.org was a WebDAV resource? Everyone agreed that if we knew that a resource was a webdav resource then we could make the menu item appear. We figured what we could do was to let the user type in the URL, press return/go and navigate to the resource. Then, in the background, after the file had completely loaded (so there would be no performance penalty) we would do a background OPTIONS request to see if we were dealing with a WebDAV resource. If we were then we would do a PROPFIND on resourcetype and see if it was a collection. If it was then we would make the menu item appear. The theory was o.k. but the implementation would be awful. First of all, this means that every time a user was just randomly browsing around we would issue at least one request (OPTIONS) and sometimes two (PROPFIND). Even assuming we figured out a caching scheme (anyone know how long to cache an OPTIONS output? How about how long to cache that a resource is a collection?) to reduce the load the implications were still frightening. I could see the headlines "IE 5.0 single handedly takes out the Internet, news at 11." However, believe it or not, there was an even worse problem, from our point of view. Pretend our normal user Missy is sitting in front of her computer. Her admin has repeated to her, three times, that she is supposed to type in http://company/files/missy into the address bar. Then she is supposed to go to view and select "Directory View". So, Missy, types in http://company/files/missy, presses return, got to the view menu and... well... nothing. There is no "Directory View" option. First the page has to finish displaying before we will try OPTIONS. Then the amount of time it takes for the OPTIONS message to get there and back is variable. Then, assuming http://company/files/missy is a WebDAV resource, we still have to make the PROPFIND request. This means that for some indeterminate and largely inconsistent period of time the "Directory View" menu option wouldn't appear. The user experience was just too awful to contemplate. We couldn't implement a randomly appearing menu item. Another suggestion was to try and make some use of the largely useless go button. The reason the go button was introduced was that users did not seem to understand the idea that one typed a URL into the address bar and then pressed return. It was the "then press return" part that got them. However other browsers had put in some sort of button that users could press to start the navigation. We got so much feedback from system administrators and others that their users were having this problem that we felt we had to put in the go button. Nobody liked it but oh well. So we figured at least we could use the stupid thing. We thought we could put in a drop down menu off that button that the user could use to select GET or PROPFIND behavior. However this suggestion suffered from the same problem that the previous suggestion suffered from, 99.9% of the time the PROPFIND selection wouldn't do anything useful. There was thought given to having a switch somewhere in advanced that would just add a "directory" switch to the view menu or add the drop down menu to the GO button but then the feature would only be useful to super power users. While we have found that it is often useful to enable super power users the IE WebDAV project at the time was incredibly resource constrained. I couldn't justify the effort for a power user feature. So, in the end, the best idea we could come up with was file/open. Of course the file/open switch suffers from the same sort of problems we identified previously, 99.9% of the time the damn thing wouldn't work right. A small improvement is that if the attempt to navigate to the resource as a FrontPage/WebDAV resource fails then we will put up an error and ask the user if they would like to see the page as a normal web page (GET). However, under normal circumstances, this wouldn't be considered acceptable. Having a feature that 99.9% of the time produces an error isn't an acceptable user experience. The reason we were allowed to use file/open is that absolutely nobody ever uses file/open. So the UI folks weren't worried about having this funky "Open as Web Folder" switch in file/open. In fact the UI folk wanted to remove file/open all together from IE but the MS UI regulations require it to be there. So they said we could throw in the switch there. In other words, we were allowed to produce a bad user experience because we were counting on the majority of users never, ever, finding the switch without being explicitly told it was there. Don't you wish I was making this all up? In the future I hope we are able to throw in a WebDAV switch as a power user feature. I normally would have driven this into IE 5.5 but I left IE a year or so ago and my new job took my attention away from WebDAV. Obviously the considerations that went into IE's design don't necessarily apply to all software products. Microsoft makes its money by selling software to the average user. The needs of the average user are very different from high end users. If you are making a high end user product then obviously your considerations will be very different. I often find it difficult to explain to IETFers why MS does what it does because people at the IETF are most definitely NOT our target audience. Normal users think very differently from technical users. Things that seem painfully obvious or easy to technical users present insurmountable barriers to normal users. Normal users do not want to understand how these systems work. They just want the damn product to work. That means that our first priority has to be to avoid making things complex. If a UI element isn't painfully obvious then it is cut or hidden away for power users. That's the theory, anyway. Yaron > -----Original Message----- > From: Joe Orton [mailto:joe@orton.demon.co.uk] > Sent: Tue, January 25, 2000 3:20 AM > To: w3c-dist-auth@w3.org > Subject: Re: Comments please! > > > > Hmm. But this doesn't solve my problem. Let's say that my > website is called > > 'http://www.foo.com'. If I do a > > get on this url, I'll get 'http://www.foo.com/index.htm' by > default. But > > 'http://www.foo.com' is also a directory at the to level. > So if a user types > > 'http://www.foo.com' I don't know if I should perform a Get > or a Propfind, > > both are valid. The user types the same thing for directory > browsing in > > 'http://www.foo.com' and for getting the default page. > > I think this mostly a UI problem. From the user's point of > view, have two "views" > on a collection resource; it's GET response, and the listing > of collection members > from a PROPFIND response. These correspond to the traditional > "web browser" mode of > operation, and the traditional "file browser/explorer" mode > of operation. > > Like you say, in Web Folders you have the "Open as Web > folder" checkbox on open > dialog, which selects which of these views should be used for > the given URI. > Another way to do this (maybe Web Folders does this too, I've > not been that side of > the fence for a while?), is to have some way of switching > between modes from within > the browser; a toolbar button, or a drop-down box, or whatever. > > So then, the user can browse about their web site, happily > viewing their pages, > then maybe they want to move some files about, so they hit > the "view collection > contents" button, and they can do that, then switch back > again when they've > finished. That would be a nice interface, IMO. > > joe > From w3c-dist-auth-request@w3.org Thu Feb 3 03:58:00 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12376 for ; Thu, 3 Feb 2000 03:57:59 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id DAA04490; Thu, 3 Feb 2000 03:47:05 -0500 (EST) Resent-Date: Thu, 3 Feb 2000 03:47:05 -0500 (EST) Resent-Message-Id: <200002030847.DAA04490@www19.w3.org> From: "Rickard Falk" To: Date: Thu, 3 Feb 2000 09:46:52 +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.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal Subject: 423 Locked Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4022 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit If a resource is locked with a exclusive lock, and another user tries to lock if. The response then is 423 Locked. But, is there any way for the client to know who owns the lock? I would like the response to look something like this : 421 Locked Date: ... Server: ... Connection: ... LockOwner : user LockDate : date LockType : exclusive LockedUntil : date // if specified when locked Comments? /Rickard From w3c-dist-auth-request@w3.org Thu Feb 3 04:08:56 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12482 for ; Thu, 3 Feb 2000 04:08:56 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id EAA05010; Thu, 3 Feb 2000 04:04:09 -0500 (EST) Resent-Date: Thu, 3 Feb 2000 04:04:09 -0500 (EST) Resent-Message-Id: <200002030904.EAA05010@www19.w3.org> Date: Thu, 03 Feb 2000 01:03:17 -0800 From: Kevin Wiggen In-reply-to: To: Rickard Falk , w3c-dist-auth@w3.org Message-id: MIME-version: 1.0 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Content-type: text/plain; charset="iso-8859-1" Content-transfer-encoding: 7bit Importance: Normal X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Priority: 3 (Normal) Subject: RE: 423 Locked Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4023 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit If you do a Propfind against the resource looking for the lockdiscovery property, the resource should return an Owner and Timeout to the client (if permissions allow). Unfortunately the Owner tag is left undefined, and I am sure each implementation has its own sets of values. Kevin -----Original Message----- From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Rickard Falk Sent: Thursday, February 03, 2000 12:47 AM To: w3c-dist-auth@w3.org Subject: 423 Locked If a resource is locked with a exclusive lock, and another user tries to lock if. The response then is 423 Locked. But, is there any way for the client to know who owns the lock? I would like the response to look something like this : 421 Locked Date: ... Server: ... Connection: ... LockOwner : user LockDate : date LockType : exclusive LockedUntil : date // if specified when locked Comments? /Rickard From w3c-dist-auth-request@w3.org Thu Feb 3 07:06:46 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13779 for ; Thu, 3 Feb 2000 07:06:45 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id HAA08240; Thu, 3 Feb 2000 07:01:37 -0500 (EST) Resent-Date: Thu, 3 Feb 2000 07:01:37 -0500 (EST) Resent-Message-Id: <200002031201.HAA08240@www19.w3.org> From: "Rickard Falk" To: Date: Thu, 3 Feb 2000 13:01:25 +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.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal In-Reply-To: Subject: RE: 423 Locked Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4024 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit Maybe the 423 Locked response should contain a XML body with the lockdiscovery property. Then the client doesn't need to do a second request to the server, and there will not be a time gap. /Rickard > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Kevin Wiggen > Sent: den 3 februari 2000 10:03 > To: Rickard Falk; w3c-dist-auth@w3.org > Subject: RE: 423 Locked > > > > If you do a Propfind against the resource looking for the lockdiscovery > property, the resource should return an Owner and Timeout to the > client (if > permissions allow). > > Unfortunately the Owner tag is left undefined, and I am sure each > implementation has its own sets of values. > > Kevin > > From w3c-dist-auth-request@w3.org Thu Feb 3 08:49:51 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17827 for ; Thu, 3 Feb 2000 08:49:50 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id IAA10090; Thu, 3 Feb 2000 08:44:53 -0500 (EST) Resent-Date: Thu, 3 Feb 2000 08:44:53 -0500 (EST) Resent-Message-Id: <200002031344.IAA10090@www19.w3.org> Date: Thu, 3 Feb 2000 08:44:41 -0500 Message-Id: <10002031344.AA02297@tantalum> From: "Geoffrey M. Clemm" To: w3c-dist-auth@w3.org In-Reply-To: Subject: Re: 423 Locked Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4025 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list From: "Rickard Falk" Maybe the 423 Locked response should contain a XML body with the lockdiscovery property. Then the client doesn't need to do a second request to the server, and there will not be a time gap. There are many would would agree that an XML body with detailed information about the cause of the error would be a good thing (Yaron, for sure). In this particular case, the overhead of an extra PROPFIND request and the time gap probably don't matter much. Cheers, Geoff > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Kevin Wiggen > Sent: den 3 februari 2000 10:03 > To: Rickard Falk; w3c-dist-auth@w3.org > Subject: RE: 423 Locked > > > > If you do a Propfind against the resource looking for the lockdiscovery > property, the resource should return an Owner and Timeout to the > client (if > permissions allow). > > Unfortunately the Owner tag is left undefined, and I am sure each > implementation has its own sets of values. > > Kevin > > From w3c-dist-auth-request@w3.org Thu Feb 3 09:41:44 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19226 for ; Thu, 3 Feb 2000 09:41:43 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id JAA12369; Thu, 3 Feb 2000 09:37:09 -0500 (EST) Resent-Date: Thu, 3 Feb 2000 09:37:09 -0500 (EST) Resent-Message-Id: <200002031437.JAA12369@www19.w3.org> From: jamsden@us.ibm.com X-Lotus-FromDomain: IBMUS To: w3c-dist-auth@w3.org Message-ID: <8525687A.005040F3.00@d54mta03.raleigh.ibm.com> Date: Thu, 3 Feb 2000 09:31:31 -0500 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Re: 423 Locked Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4026 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list There is a DAV property called DAV:lockdiscovery which contains a DAV:activelock element which contains, among other things, a DAV:owner field describing the owner of the lock. The WebDAV spec does not define the content of the DAV:owner element, it only suggests that it should describe the owner of the lock in some way that another user could contact the owner. Unfortunately, there is no element in DAV:activelock that specifies the actual princapal that took out the lock. I believe this is a bug that requires all clients to maintain their lock tokens in some other redundant repository. This issue has been open for over a year. I hope it gets addressed and resolved as part of the ongoing effort to clarify WebDAV locking semantics and protocol. "Rickard Falk" @w3.org on 02/03/2000 03:46:52 AM Sent by: w3c-dist-auth-request@w3.org To: cc: Subject: 423 Locked If a resource is locked with a exclusive lock, and another user tries to lock if. The response then is 423 Locked. But, is there any way for the client to know who owns the lock? I would like the response to look something like this : 421 Locked Date: ... Server: ... Connection: ... LockOwner : user LockDate : date LockType : exclusive LockedUntil : date // if specified when locked Comments? /Rickard From w3c-dist-auth-request@w3.org Thu Feb 3 11:08:03 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21444 for ; Thu, 3 Feb 2000 11:07:56 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id LAA16485; Thu, 3 Feb 2000 11:03:38 -0500 (EST) Resent-Date: Thu, 3 Feb 2000 11:03:38 -0500 (EST) Resent-Message-Id: <200002031603.LAA16485@www19.w3.org> Date: Thu, 3 Feb 2000 11:03:26 -0500 Message-Id: <10002031603.AA02383@tantalum> From: "Geoffrey M. Clemm" To: jamsden@us.ibm.com Cc: w3c-dist-auth@w3.org In-Reply-To: <8525687A.005040F3.00@d54mta03.raleigh.ibm.com> (jamsden@us.ibm.com) Subject: Re: 423 Locked Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4027 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list What Jim is asking for is a way for a client to find out "is my current principal the same as the principal that took out the lock" *without* asking its user. I do not believe that is what Richard was asking for, but rather wanted information to give to the user about who currently has that resource locked (i.e. the information in the DAV:owner field). Richard: Is this interpretation correct? Since a client should *always* ask its user before doing anything with a lock token from some other client, I maintain that the currently defined DAV:owner field is adequate for correct usage of lock tokens, and no DAV:principal field should be defined. Cheers, Geoff From: jamsden@us.ibm.com There is a DAV property called DAV:lockdiscovery which contains a DAV:activelock element which contains, among other things, a DAV:owner field describing the owner of the lock. The WebDAV spec does not define the content of the DAV:owner element, it only suggests that it should describe the owner of the lock in some way that another user could contact the owner. Unfortunately, there is no element in DAV:activelock that specifies the actual princapal that took out the lock. I believe this is a bug that requires all clients to maintain their lock tokens in some other redundant repository. This issue has been open for over a year. I hope it gets addressed and resolved as part of the ongoing effort to clarify WebDAV locking semantics and protocol. "Rickard Falk" @w3.org on 02/03/2000 03:46:52 AM If a resource is locked with a exclusive lock, and another user tries to lock if. The response then is 423 Locked. But, is there any way for the client to know who owns the lock? I would like the response to look something like this : 421 Locked Date: ... Server: ... Connection: ... LockOwner : user LockDate : date LockType : exclusive LockedUntil : date // if specified when locked Comments? /Rickard From w3c-dist-auth-request@w3.org Thu Feb 3 11:40:31 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22222 for ; Thu, 3 Feb 2000 11:40:30 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id LAA18867; Thu, 3 Feb 2000 11:36:06 -0500 (EST) Resent-Date: Thu, 3 Feb 2000 11:36:06 -0500 (EST) Resent-Message-Id: <200002031636.LAA18867@www19.w3.org> Message-ID: <25D0DF2980A7D311AB1C00508B91BD2A13BC28@BELMAIL1> From: Mike Dierken To: Yaron Goland , w3c-dist-auth@w3.org Date: Thu, 3 Feb 2000 08:23:40 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Why IE's Web Folders are accessed through File/Open Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4028 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Great e-mail. Shows what the real world is like. We ran into that Noun/Verb issue with URLs and what we decided to do (because we are a small company) for our Web apps was to standardize on a URL parameter for the 'verb' portion. Conceptually, we bubbled up some HTTP headers into the query term of a URL. So to specify the 'method' we use ?do:method=options and such. In addition, we also use do:accept and do:authorization to emulate the 'Accept' and 'Authorization' headers. This makes is a little easier to author HTML pages with more control of what happens on the server & makes it easier to pass around URLs with known results (even between clients, since it's all server side). Mike PS The handling of do:method=options actually combines the HTTP Method and the do:method - you end up with 'get_options' or 'post_options', but it could be done differently, that's a minor issue compared with how you actually formalize the request. > -----Original Message----- > From: Yaron Goland [mailto:yarong@Exchange.Microsoft.com] > Sent: Wednesday, February 02, 2000 5:08 PM > To: 'Joe Orton'; w3c-dist-auth@w3.org > Subject: Why IE's Web Folders are accessed through File/Open > > > O.k., I admit it, I am the person responsible for the awful > file/open check > box UI in Web Folders in IE. It is all my fault. Throw rotten > tomatoes my > way. > > All of us at MS tried to come up with a better solution. The > ways to improve > Web Folders in IE fell into two types - > 1) Enable people, only by typing in a URL to tell the system > that they want > a PROPFIND view > 2) Put in a switch to allow people, once they are at a site, > to flip between > GET/PROPFIND > > We were, unfortunately, not able to achieve either of these > goals for the > reasons I will outline below. This is why we ended up with > the file/open UI. > It was the best thing we could come up with. > From w3c-dist-auth-request@w3.org Thu Feb 3 12:37:14 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24385 for ; Thu, 3 Feb 2000 12:37:13 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA21422; Thu, 3 Feb 2000 12:32:53 -0500 (EST) Resent-Date: Thu, 3 Feb 2000 12:32:53 -0500 (EST) Resent-Message-Id: <200002031732.MAA21422@www19.w3.org> From: jamsden@us.ibm.com X-Lotus-FromDomain: IBMUS To: w3c-dist-auth@w3.org Message-ID: <8525687A.00605EA0.00@d54mta03.raleigh.ibm.com> Date: Thu, 3 Feb 2000 12:28:23 -0500 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Re: 423 Locked Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4029 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Like Geoff, I don't think there should be too much problem doing the PROPFIND after the failed lock. The only thing that can happen between the LOCK and the PROPFIND that would be of interest is UNLOCK, and then the client would see the lock was gone and there is nothing to do (always a possibility in a distributed, concurrent environment). We have to be careful about overloading methods to support client use cases. This will cause the protocol to bloat and become complex. It will also reduce interoperability and create situations where one client's use cases conflict with another. Some methods do return failure information that your client can use. falk@excosoft.se on 02/03/2000 11:29:48 AM To: Jim Amsden/Raleigh/IBM@IBMUS cc: Subject: Re: 423 Locked Hi! If you follow the 423 Locked thread, you see that I suggested that the lockdiscovery should be sent in the 423 response. I would like the 423 response to contain the locked by info, so that I don't have to do a new request to the server ( performance ), and not have a time gap. Do you have any comments about sending the lockdiscovery in the 423 response, I would appriciate getting them... ( or if you can post them on the webdav work group...) /Rickard > > > There is a DAV property called DAV:lockdiscovery which contains a > DAV:activelock element which contains, among other things, a DAV:owner > field describing the owner of the lock. The WebDAV spec does not define the > content of the DAV:owner element, it only suggests that it should describe > the owner of the lock in some way that another user could contact the > owner. Unfortunately, there is no element in DAV:activelock that specifies > the actual princapal that took out the lock. I believe this is a bug that > requires all clients to maintain their lock tokens in some other redundant > repository. This issue has been open for over a year. I hope it gets > addressed and resolved as part of the ongoing effort to clarify WebDAV > locking semantics and protocol. > > > > > > "Rickard Falk" @w3.org on 02/03/2000 03:46:52 AM > > Sent by: w3c-dist-auth-request@w3.org > > > To: > cc: > > Subject: 423 Locked > > > If a resource is locked with a exclusive lock, and another user tries to > lock if. The response then is 423 Locked. But, is there any way for the > client to know who owns the lock? > I would like the response to look something like this : > 421 Locked > Date: ... > Server: ... > Connection: ... > LockOwner : user > LockDate : date > LockType : exclusive > LockedUntil : date // if specified when locked > > Comments? > > /Rickard > > > > From w3c-dist-auth-request@w3.org Thu Feb 3 12:42:33 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24565 for ; Thu, 3 Feb 2000 12:42:32 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA21562; Thu, 3 Feb 2000 12:38:09 -0500 (EST) Resent-Date: Thu, 3 Feb 2000 12:38:09 -0500 (EST) Resent-Message-Id: <200002031738.MAA21562@www19.w3.org> From: jamsden@us.ibm.com X-Lotus-FromDomain: IBMUS To: w3c-dist-auth@w3.org Message-ID: <8525687A.0060BD3F.00@d54mta03.raleigh.ibm.com> Date: Thu, 3 Feb 2000 12:30:42 -0500 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Re: 423 Locked Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4030 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Geoff, I'm trying to solve a different problem than the one you reference below. I'm not worried about hijacking someone else's lock, what I want is just some way to get the lock tokens for the resources *I* have locked so I don't have to hang on to them in my client application. "Geoffrey M. Clemm" on 02/03/2000 11:03:26 AM To: Jim Amsden/Raleigh/IBM@IBMUS cc: w3c-dist-auth@w3.org Subject: Re: 423 Locked What Jim is asking for is a way for a client to find out "is my current principal the same as the principal that took out the lock" *without* asking its user. I do not believe that is what Richard was asking for, but rather wanted information to give to the user about who currently has that resource locked (i.e. the information in the DAV:owner field). Richard: Is this interpretation correct? Since a client should *always* ask its user before doing anything with a lock token from some other client, I maintain that the currently defined DAV:owner field is adequate for correct usage of lock tokens, and no DAV:principal field should be defined. Cheers, Geoff From: jamsden@us.ibm.com There is a DAV property called DAV:lockdiscovery which contains a DAV:activelock element which contains, among other things, a DAV:owner field describing the owner of the lock. The WebDAV spec does not define the content of the DAV:owner element, it only suggests that it should describe the owner of the lock in some way that another user could contact the owner. Unfortunately, there is no element in DAV:activelock that specifies the actual princapal that took out the lock. I believe this is a bug that requires all clients to maintain their lock tokens in some other redundant repository. This issue has been open for over a year. I hope it gets addressed and resolved as part of the ongoing effort to clarify WebDAV locking semantics and protocol. "Rickard Falk" @w3.org on 02/03/2000 03:46:52 AM If a resource is locked with a exclusive lock, and another user tries to lock if. The response then is 423 Locked. But, is there any way for the client to know who owns the lock? I would like the response to look something like this : 421 Locked Date: ... Server: ... Connection: ... LockOwner : user LockDate : date LockType : exclusive LockedUntil : date // if specified when locked Comments? /Rickard From w3c-dist-auth-request@w3.org Thu Feb 3 13:31:35 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26247 for ; Thu, 3 Feb 2000 13:31:35 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA23105; Thu, 3 Feb 2000 13:26:08 -0500 (EST) Resent-Date: Thu, 3 Feb 2000 13:26:08 -0500 (EST) Resent-Message-Id: <200002031826.NAA23105@www19.w3.org> Date: Thu, 3 Feb 2000 10:21:04 -0800 Message-ID: <350-Thu03Feb2000102104-0800-bill@carpenter.ORG> X-Mailer: 20.4 "Emerald" XEmacs Lucid (via feedmail 9-beta-9 I) wjc loop; VM 6.71 under 20.4 "Emerald" XEmacs Lucid MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: bill@carpenter.ORG (WJCarpenter) To: w3c-dist-auth@w3.org In-Reply-To: <8525687A.00605EA0.00@d54mta03.raleigh.ibm.com> References: <8525687A.00605EA0.00@d54mta03.raleigh.ibm.com> Subject: Re: 423 Locked Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4031 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit jamsden> We have to be careful about overloading methods to support jamsden> client use cases. This will cause the protocol to bloat and jamsden> become complex. It will also reduce interoperability and jamsden> create situations where one client's use cases conflict with jamsden> another. Some methods do return failure information that your jamsden> client can use. You also have to allow for the possibility that it's more expensive for a server to answer questions about the details of a LOCK than it is to merely answer yes-or-no about a resource being LOCKed. (E.g., a fixed field in some property table points to a LOCK record stored elsewhere.) -- bill@carpenter.ORG (WJCarpenter) PGP bill@bubblegum.net 0x91865119 38 95 1B 69 C9 C6 3D 25 73 46 32 04 69 D6 ED F3 From w3c-dist-auth-request@w3.org Thu Feb 3 13:48:11 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26566 for ; Thu, 3 Feb 2000 13:48:10 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA23811; Thu, 3 Feb 2000 13:43:11 -0500 (EST) Resent-Date: Thu, 3 Feb 2000 13:43:11 -0500 (EST) Resent-Message-Id: <200002031843.NAA23811@www19.w3.org> Date: Thu, 3 Feb 2000 10:43:39 -0800 (PST) From: Greg Stein To: w3c-dist-auth@w3.org In-Reply-To: <350-Thu03Feb2000102104-0800-bill@carpenter.ORG> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: 423 Locked Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4032 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list On Thu, 3 Feb 2000, WJCarpenter wrote: > jamsden> We have to be careful about overloading methods to support > jamsden> client use cases. This will cause the protocol to bloat and I thought we were designing a protocol that is used by the client. Why shouldn't we support it? IMO, returning an XML body in the 423 response is a good idea. It could have a DAV:lockdiscovery element. > jamsden> become complex. It will also reduce interoperability and The spec is how we fix interoperability issues. > jamsden> create situations where one client's use cases conflict with > jamsden> another. Some methods do return failure information that your > jamsden> client can use. > > You also have to allow for the possibility that it's more expensive > for a server to answer questions about the details of a LOCK than it > is to merely answer yes-or-no about a resource being LOCKed. (E.g., a > fixed field in some property table points to a LOCK record stored > elsewhere.) While this is true, we are talking about an error case. Personally, I don't mind taking a few more cycles in an error case. Especially if there is a possibility that the client will be needing that information anyhow. Cheers, -g -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Thu Feb 3 14:22:04 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27463 for ; Thu, 3 Feb 2000 14:22:00 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA24853; Thu, 3 Feb 2000 14:15:30 -0500 (EST) Resent-Date: Thu, 3 Feb 2000 14:15:30 -0500 (EST) Resent-Message-Id: <200002031915.OAA24853@www19.w3.org> Date: Thu, 03 Feb 2000 11:12:13 -0800 From: Kevin Wiggen In-reply-to: <8525687A.00605EA0.00@d54mta03.raleigh.ibm.com> To: jamsden@us.ibm.com, w3c-dist-auth@w3.org Message-id: MIME-version: 1.0 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Content-type: text/plain; charset="iso-8859-1" Content-transfer-encoding: 7bit Importance: Normal X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Priority: 3 (Normal) Subject: RE: 423 Locked Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4033 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit When someone does a MOVE or a COPY or a PROPPATCH etc. We have the ability to tell them why the operation failed (in XML in the body). With 423 we do not. I don't think that sending the extra information (based on security considerations) is wrong. If I do a MOVE on a resource to a destination which already exists, I think it would be useful information to say that the source was locked vrs. the destination was locked. Since this information would be useful, why not also send the info Rickard is looking for? I don't think that we should simply return the lockdiscovery... In the future we are going to need to provide some better syntax for reporting errors. My suggestion is that we return the lockdiscovery stuff, but wrap it in some new set of tags which can also give the href and will be used in other places. Kevin -----Original Message----- From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On Behalf Of jamsden@us.ibm.com Sent: Thursday, February 03, 2000 9:28 AM To: w3c-dist-auth@w3.org Subject: Re: 423 Locked Like Geoff, I don't think there should be too much problem doing the PROPFIND after the failed lock. The only thing that can happen between the LOCK and the PROPFIND that would be of interest is UNLOCK, and then the client would see the lock was gone and there is nothing to do (always a possibility in a distributed, concurrent environment). We have to be careful about overloading methods to support client use cases. This will cause the protocol to bloat and become complex. It will also reduce interoperability and create situations where one client's use cases conflict with another. Some methods do return failure information that your client can use. falk@excosoft.se on 02/03/2000 11:29:48 AM To: Jim Amsden/Raleigh/IBM@IBMUS cc: Subject: Re: 423 Locked Hi! If you follow the 423 Locked thread, you see that I suggested that the lockdiscovery should be sent in the 423 response. I would like the 423 response to contain the locked by info, so that I don't have to do a new request to the server ( performance ), and not have a time gap. Do you have any comments about sending the lockdiscovery in the 423 response, I would appriciate getting them... ( or if you can post them on the webdav work group...) /Rickard > > > There is a DAV property called DAV:lockdiscovery which contains a > DAV:activelock element which contains, among other things, a DAV:owner > field describing the owner of the lock. The WebDAV spec does not define the > content of the DAV:owner element, it only suggests that it should describe > the owner of the lock in some way that another user could contact the > owner. Unfortunately, there is no element in DAV:activelock that specifies > the actual princapal that took out the lock. I believe this is a bug that > requires all clients to maintain their lock tokens in some other redundant > repository. This issue has been open for over a year. I hope it gets > addressed and resolved as part of the ongoing effort to clarify WebDAV > locking semantics and protocol. > > > > > > "Rickard Falk" @w3.org on 02/03/2000 03:46:52 AM > > Sent by: w3c-dist-auth-request@w3.org > > > To: > cc: > > Subject: 423 Locked > > > If a resource is locked with a exclusive lock, and another user tries to > lock if. The response then is 423 Locked. But, is there any way for the > client to know who owns the lock? > I would like the response to look something like this : > 421 Locked > Date: ... > Server: ... > Connection: ... > LockOwner : user > LockDate : date > LockType : exclusive > LockedUntil : date // if specified when locked > > Comments? > > /Rickard > > > > From w3c-dist-auth-request@w3.org Thu Feb 3 16:47:01 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00224 for ; Thu, 3 Feb 2000 16:46:57 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA00627; Thu, 3 Feb 2000 16:42:24 -0500 (EST) Resent-Date: Thu, 3 Feb 2000 16:42:24 -0500 (EST) Resent-Message-Id: <200002032142.QAA00627@www19.w3.org> From: Jim Whitehead To: WebDAV WG Date: Thu, 3 Feb 2000 13:37:47 -0800 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.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Subject: FW: Hrefs to files in WebDavs ? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4034 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 8bit Accidentally caught by the spam filter. - Jim -----Original Message----- From: björn bang [mailto:bjorn.bang@absalon.net] Sent: Thursday, February 03, 2000 1:00 AM To: w3c-dist-auth@w3.org Subject: [Moderator Action] Hrefs to files in WebDavs ? I have a question about linking to WebDav's, I know how to create a href to a WebDav folder but how do I do it for a file in a WebDav folder, so it would open as a file (with save available) and not as GET ? anyone? / bang From w3c-dist-auth-request@w3.org Thu Feb 3 16:47:27 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00248 for ; Thu, 3 Feb 2000 16:47:23 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA00669; Thu, 3 Feb 2000 16:42:47 -0500 (EST) Resent-Date: Thu, 3 Feb 2000 16:42:47 -0500 (EST) Resent-Message-Id: <200002032142.QAA00669@www19.w3.org> From: Jim Whitehead To: WebDAV WG Date: Thu, 3 Feb 2000 13:38:12 -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.2314.1300 Importance: Normal Subject: Re: Why IE's Web Folders are accessed through File/Open Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4035 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit Accidentally caught by the spam filter. - Jim -----Original Message----- From: Edgar Schwarz [mailto:Edgar.Schwarz@marconicomms.com] Sent: Thursday, February 03, 2000 6:24 AM To: w3c-dist-auth@w3.org Subject: [Moderator Action] Re: Why IE's Web Folders are accessed through File/Open Yaron Goland wrote: > The last idea to be considered, which I admit responsibility for, > was to introduce a new type of URL, dav:. Any time we saw a dav: URL we > would do a PROPFIND. That's what I decided to do for my Oberon client. > While I wasn't enamored with this idea I felt it was practical. Agreed :-) > Also the IE UI guys went absolutely insane at the mere suggestion that > a DAV: URL could appear in the address bar. They too could hear the support > phone lines ringing as people demanded to know what the hell a DAV URL was > and where the HTTP URL had gone to. So this idea was also killed off. It`s a pity. I think at least for Oberon users there shouldn`t be such a problem. There are already names like mailto:..., ftp://..., http://..., so why shouldn`t there be a dav://... . And why should this be something a MS user wouldn`t understand. He already knows a: b:, c:, ... So you could sell dav: just as onother distributed disk :-) > The reason we were allowed to use file/open is that absolutely > nobody ever uses file/open. So the UI folks weren't worried about having > this funky "Open as Web Folder" switch in file/open. In fact the UI folk > wanted to remove file/open all together from IE but the MS UI regulations > require it to be there. So they said we could throw in the switch there. In > other words, we were allowed to produce a bad user experience because we > were counting on the majority of users never, ever, finding the switch > without being explicitly told it was there. Don't you wish I was making this > all up? YES ! Cheers, Edgar -- Edgar.Schwarz@marconicomms.com ON/EUE1, 07191/13-3382 Niklaus Wirth: Privat kann jeder soviel C programmieren oder Videos ansehen wie er mag. Albert Einstein: Mach es so einfach wie moeglich, aber nicht einfacher. From w3c-dist-auth-request@w3.org Thu Feb 3 17:15:45 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01114 for ; Thu, 3 Feb 2000 17:15:43 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA01491; Thu, 3 Feb 2000 17:06:35 -0500 (EST) Resent-Date: Thu, 3 Feb 2000 17:06:35 -0500 (EST) Resent-Message-Id: <200002032206.RAA01491@www19.w3.org> Message-ID: <8E3CFBC709A8D21191A400805F15E0DBD24594@crte147.wc.eso.mc.xerox.com> From: "Slein, Judith A" To: "'Joe Orton'" , "Slein, Judith A" Cc: w3c-dist-auth@w3.org Date: Thu, 3 Feb 2000 17:06:13 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Bodies of redirect reference resources Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4036 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Oops. sorry. I was confusing a couple of different issues. So forget the remarks about parallels to collections. The comment at IETF 46 was just that someone might find a use for an entity-body on redirect references, so we should allow it. That would mean allowing PUT and GET to work on redirect references. --Judy > -----Original Message----- > From: Joe Orton [mailto:joe@orton.demon.co.uk] > Sent: Wednesday, February 02, 2000 4:14 PM > To: Slein, Judith A > Cc: w3c-dist-auth@w3.org > Subject: Re: Bodies of redirect reference resources > > > > I was just looking back at my notes from the November 1999 > IETF meeting. > > This change was made in response to comments there that we > should make > > redirect references analogous to collections with respect > to an entity-body. > > I'm not sure I understand this: PUT is undefined/disallowed on a > collection, and GET on a collection is defined to return "something or > other"... not very analogous to the entity-body storing > GET/PUT behaviour > for RR resources? > > joe > From w3c-dist-auth-request@w3.org Thu Feb 3 17:26:08 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01228 for ; Thu, 3 Feb 2000 17:26:05 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA01891; Thu, 3 Feb 2000 17:20:43 -0500 (EST) Resent-Date: Thu, 3 Feb 2000 17:20:43 -0500 (EST) Resent-Message-Id: <200002032220.RAA01891@www19.w3.org> Date: Thu, 3 Feb 2000 17:20:37 -0500 Message-Id: <10002032220.AA02585@tantalum> From: "Geoffrey M. Clemm" To: w3c-dist-auth@w3.org In-Reply-To: <8525687A.0060BD3F.00@d54mta03.raleigh.ibm.com> (jamsden@us.ibm.com) Subject: Re: 423 Locked Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4037 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list From: jamsden@us.ibm.com I'm trying to solve a different problem than the one you reference below. I'm not worried about hijacking someone else's lock, what I want is just some way to get the lock tokens for the resources *I* have locked so I don't have to hang on to them in my client application. I assume by "I" and "someone else", you mean two different clients (which may or may not be working on behalf of the same principal). Since the client that took out the lock would have to remember what the URL of the resource was, it would seem rather bizarre to not store the lock-token in the same data structure as well. That's what in process memory is for (:-). Cheers, Geoff "Geoffrey M. Clemm" on 02/03/2000 11:03:26 AM What Jim is asking for is a way for a client to find out "is my current principal the same as the principal that took out the lock" *without* asking its user. I do not believe that is what Richard was asking for, but rather wanted information to give to the user about who currently has that resource locked (i.e. the information in the DAV:owner field). Richard: Is this interpretation correct? Since a client should *always* ask its user before doing anything with a lock token from some other client, I maintain that the currently defined DAV:owner field is adequate for correct usage of lock tokens, and no DAV:principal field should be defined. From: jamsden@us.ibm.com There is a DAV property called DAV:lockdiscovery which contains a DAV:activelock element which contains, among other things, a DAV:owner field describing the owner of the lock. The WebDAV spec does not define the content of the DAV:owner element, it only suggests that it should describe the owner of the lock in some way that another user could contact the owner. Unfortunately, there is no element in DAV:activelock that specifies the actual princapal that took out the lock. I believe this is a bug that requires all clients to maintain their lock tokens in some other redundant repository. This issue has been open for over a year. I hope it gets addressed and resolved as part of the ongoing effort to clarify WebDAV locking semantics and protocol. "Rickard Falk" @w3.org on 02/03/2000 03:46:52 AM If a resource is locked with a exclusive lock, and another user tries to lock if. The response then is 423 Locked. But, is there any way for the client to know who owns the lock? I would like the response to look something like this : 421 Locked Date: ... Server: ... Connection: ... LockOwner : user LockDate : date LockType : exclusive LockedUntil : date // if specified when locked Comments? /Rickard From w3c-dist-auth-request@w3.org Fri Feb 4 19:58:14 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14158 for ; Fri, 4 Feb 2000 19:58:13 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id TAA05231; Fri, 4 Feb 2000 19:53:18 -0500 (EST) Resent-Date: Fri, 4 Feb 2000 19:53:18 -0500 (EST) Resent-Message-Id: <200002050053.TAA05231@www19.w3.org> From: Jim Whitehead To: WebDAV WG Date: Fri, 4 Feb 2000 16:48:37 -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) In-Reply-To: <4.2.2.20000122152034.01f8aba0@mail.cyberteams.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Subject: RE: Should I use displayname? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4038 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit It seems to me the key issue here is whether the displayname property is a unique description for the resource (invariant of URL used to access it), or depends on its location in the namespace (and hence could depend on the URL used to access it). I like the idea of having the displayname property be a quality of the resource, essentially a short, URL-invariant description of the resource. If a resource was accessible via multiple URLs, the displayname would remain the same. The displayname also might very well not bear much correlation to the URL, and hence it probably makes sense to have its default value be blank, rather than the last path segment of the URL used to create it (or the last path segment of any URL used to access it). Also, since I don't appear to have done this already, I've added this issue to the issues list. - Jim From w3c-dist-auth-request@w3.org Sat Feb 5 04:16:49 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02746 for ; Sat, 5 Feb 2000 04:16:49 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id EAA10776; Sat, 5 Feb 2000 04:12:27 -0500 (EST) Resent-Date: Sat, 5 Feb 2000 04:12:27 -0500 (EST) Resent-Message-Id: <200002050912.EAA10776@www19.w3.org> Message-ID: <000a01bf6fb9$1dc07bd0$73585687@bastet> From: "Charlie Cook" To: "WebDAV" Date: Sat, 5 Feb 2000 09:12:23 -0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01BF6FB9.1D078C10" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2014.211 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 Subject: DAV Property Namespace in Web Store Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4039 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_0007_01BF6FB9.1D078C10 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I've noticed that in the January MSDN Library from Microsoft there is a = list of DAV: properties that the Web Store is going to support. There = are 45 properties in this list as opposed to the 11 properties described = in RFC 2518. Some of the extra properties are described in "Additional = WebDAV Collection Properties" (Alex Hopmann and Lisa Lippert, Dec 1998) = but I can't find any reference to the others. Are these extra properties Microsoft-extensions or have I missed some = other document describing or proposing them? Thanks, Charlie=20 ------=_NextPart_000_0007_01BF6FB9.1D078C10 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I've noticed that in the January MSDN = Library from=20 Microsoft there is a list of DAV: properties that the Web Store is going = to=20 support. There are 45 properties in this list as opposed to the 11 = properties=20 described in RFC 2518. Some of the extra properties are described in = "Additional=20 WebDAV Collection Properties" (Alex Hopmann and Lisa Lippert, Dec = 1998) but=20 I can't find any reference to the others.
 
Are these extra properties = Microsoft-extensions or=20 have I missed some other document describing or proposing=20 them?
 
Thanks, = Charlie 
------=_NextPart_000_0007_01BF6FB9.1D078C10-- From w3c-dist-auth-request@w3.org Mon Feb 7 08:58:16 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09006 for ; Mon, 7 Feb 2000 08:58:16 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id IAA18268; Mon, 7 Feb 2000 08:50:59 -0500 (EST) Resent-Date: Mon, 7 Feb 2000 08:50:59 -0500 (EST) Resent-Message-Id: <200002071350.IAA18268@www19.w3.org> To: WebDAV WG cc: reuterj@ira.uka.de, jjh@ira.uka.de Date: Mon, 07 Feb 2000 14:50:31 +0100 From: Juergen Reuter Message-ID: <"iraun1.ira.0013001:000207.135048"@ira.uka.de> Subject: Review: Redirect Reference Resources -- Part one Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4040 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Following the working group's last call for comments, below is the first part of a review of the Redirect Reference Resources Protocol. It covers the abstract, tabe of contents and chapters 1 to 6 of the protocol. ******** > Abstract > ... > The related specification, RFC xxxx, defines bindings, and the BIND > method for creating them. The problem of circularity in cross-refencing other specifications has already been discussed for the bindings protocol and, as far as I understand, holds true for this protocol as well. > Creating a new binding to a resource > indirectly creates one or more new URIs mapped to that resource, which > can then be used to access it. Servers are required to insure the > integrity of any bindings that they allow to be created. IMHO, issues that refer to the bindings protocol should not appear in this protocol and not at all in the abstract, unless they are needed for clarification of the definition of redirect reference resources in contrast to bindings. To avoid circular cross-references, this can only have informational character to the reader, but no specificational character. If, nevertheless, the contrast to bindings is to be revealed, it should be made obviously using language like "while bindings are useful for ..., redirect references are nice when ...", or "unlike bindings, which ..., redirect references do ...". Anyway, the above section is too specific to appear in an abstract. What I am missing are some introductional notes on redirect references themselves; that they have already been specified long ago in HTTP/1.0 (or even before?) and are today frequently used throughout present HTTP servers' configuration capabilities (this is probably what the specification calls "ordinary HTTP 1.1 redirect"); but that until now, there is no standardized way for a client to remotely create, modify and delete redirect references on a server; that this protocol claims redirect references to be viewed as WebDAV resources of a new resource type; and that this protocol provides new DAV:properties and a new method to create, modify and delete redirect reference resources in a proper and standardized manner. > Table of Contents > > 1 Notational Conventions........................................3 > 2 Introduction..................................................3 As Roy pointed out for the bindings protocol, the section "Notational Conventions" should not appear before the introduction. This should also hold true for this specification. > 16.4 Private Locations May Be Revealed............................23 Personally, I would not expect a complete sentence as header line. > Slein et al. Page 2 For the bindings protocol Roy pointed out that a working draft in that status should not be formatted, even if the internet official protocol standards track tells something different. This should also hold true for this specification. > 2 Introduction The first three sections of this chapter are identical to those of the bindings protocol; hence the general discussion made for the corresponding sections of the bindings protocol should also hold true for this specification. > A redirect > reference resource is a resource in one collection whose purpose is to > forward requests to another resource (its target), usually in a > different collection. I move "usually" be replaced by "possibly". > The companion specification, RFC xxxx, This may result in yet another circular cross-reference. > defines the BIND method, a > different mechanism for allowing clients to create alternative access > paths to existing WebDAV-compliant resources. The BIND method lets > clients associate a new URI with an existing WebDAV resource. This URI > can then be used to submit requests to the resource. Since URIs of > WebDAV-compliant resources are hierarchical, and correspond to a > hierarchy of collections in resource space, the BIND method also has the > effect of adding the resource to a collection. As new URIs are > associated with the resource, it appears in additional collections. Could the above section be dropped? To reveal the differences between bindings and redirect reference resources, the next but one section ("By contrast, ...") should suffice. > 3 Terminology > Reference Resource > ... > bindings (defined in [B]) Once again a reference to bindings. > Direct Reference Resource > Direct Reference Resources are out of scope for this > specification, but are defined here for contrast with redirect > reference resources. Does it really make sense to define terms that are out of scope? Direct Reference Resources as defined here are only a single example for something that is not a redirect reference resource, but one probably could define an arbitrary number of other things that are as well "in contrast"; it just depends on what particular attribute the contrast refers to. Anyway, this definition probably should require that a direct reference resource be a reference resource. > 4 Overview of Redirect Reference Resources > ... > It is also what insures that redirect reference resources > will be simple to implement and that cross-server references will be > possible. It may *help* that redirect reference resources will be simple to implement, but it can not ensure it, unless you implicitly make assumptions about the implementation, which should not be made in this specification. > If the client is aware that it is operating on a redirect reference > resource, it can resolve the reference by retrieving the reference > resource's DAV:reftarget property (defined in Section 12.1 below), whose > value contains the URI of the target resource. It can then submit > requests to the target resource. Why not using the HTTP Location header field to resolve the reference? This can be (and usually is) done even by clients that are unaware of the above. The true reason for introducing a DAV:reftarget property seems to be the possibility to *modify* the URI of the target resource rather than resolving the reference. > A redirect reference resource is a new type of resource. To distinguish > redirect reference resources from non-reference resources, a new value > of the DAV:resourcetype property (defined in [WebDAV]), DAV:redirectref, > is defined in Section 13.1 below. Just wondering: is there a standardized registration procedure for new DAV:resourcetype property values, e.g. something like MIME registration procedures as defined in RFC 2048? If not, that might substantially impair interoperability. > Since a redirect reference resource is a resource, it can have its own > properties and body, and methods can be applied to the reference > resource as well as to its target resource. The Apply-To-Redirect-Ref > request header (defined in Section 11.2 below) is provided so that > referencing-aware clients can control whether an operation is applied to > the redirect reference resource or to its target resource. When I read this, I first thought you were going to specify something that behaves like a direct reference resource, which however was declared to be out of scope for this specification. Having a look at section 6.2, it then (hopefully) became clear to me what you really wanted to say in this section. Hence I move to modify the wording, e.g. as follows: "While the basically intended behaviour of a redirect reference resource is to redirect a client to a different location, a different behaviour of the server is expected when creating, modifying or deleting the redirect reference resource itself. To let the server distinguish between these two fashions of behaviour, the Apply-To-Redirect-Ref request header (defined in Section 11.2 below) is provided so that a referencing-aware client can tell the server that it does not want to be redirected, but that the requested operation is to be applied to the redirect reference resource itself." > 5 Creating a Redirect Reference Resource > > The MKRESOURCE method is used to create new redirect reference > resources. I propose that "the MKRESOURCE method" should better read "the new MKRESOURCE method", as the method seems to be newly introduced in this specification. > It creates a new binding between the new redirect reference resource > and the last path segment of the Request-URI. The new binding is > added to its parent collection, identified by the Request-URI minus > its trailing slash (if present) and final segment. So, this protocol does not just informally refer to the bindings protocol, but really depends on it? Does this imply a specific implementation of redirect reference resources using bindings? Or is the meaning of the word "binding" not the same as defined in the bindings protocol? > 5.1 MKRESOURCE > > The MKRESOURCE method requests the creation of a resource and > initialization of its properties. It allows resources other than > standard data containers and collections to be created and their > properties initialized in one atomic operation. N.b.: the more general concept of MKRESOURCE has the potential of replacing the more specific concept of MKCOL, if it allowed a DAV:collection value for the DAV:resourcetype property. > The body of the new resource is empty. What is the body of a resource? For standard data containers, the intended meaning seems to be clear, but what is the meaning for other resource types? In this case, this probably should read "The entity body of a response returned from a GET request on the new resource MUST be empty.", or the term "body of a resource" should be defined somewhere else. (N.b.: WebDAV also uses the term "body of a resource" in sections 8.10.2 and 17.5 without prior definition). Anyway, for clients that do not support automatic redirection, it is sensible to provide some text/html response body to be returned from a GET request that can be shown to the user. Hence, I move to take away the restriction that the body must be empty. > The properties of the new resource are as specified by the > DAV:propertyupdate request body, using PROPPATCH semantics. I had to read this sentence again and again to understand the meaning. I move to choose a different wording, e.g. as follows: "The MKRESOURCE request MAY contain a DAV:propertyupdate request body to initialize resource properties. Herein, the semantics is the same as when sending a MKRESOURCE request without request body, followed by a PROPPATCH with the DAV:propertyupdate request body." This leads to a new question: is MKRESOURCE atomic (from all WebDAV client's perspective)? Or can another client access the new resource's properties before they fully have been initialized? If an error is encountered while initializing the properties, that means that some properties may have been initialized, while others still are undefined; atomicity would at least in that case be broken. However, if MKRESOURCE could atomically create and (read & write) lock a resource, this would prevent other clients from accessing the newly created resource until the creator decides to remove the lock. Hence, I would like to put up for discussion the following question: Should a MKRESOURCE request may contain a DAV:lockinfo XML element and those request headers defined for the LOCK method in order to request atomic creation and locking of a new resource? > If the response status code is not 201, then a new resource is not > created ... "is not created" should probably read "was not created", making it consistent with the status codes description a few lines below (or is deferred creation allowed for an implementation of MKRESOURCE?). > Response Marshalling: > > Responses from a MKRESOURCE request SHOULD NOT be cached, as MKRESOURCE > has non-idempotent semantics. I move that if MKRESOURCE has non-idempotent semantics, then responses MUST NOT be cached unless the client and the server agree on some cache protocol outside of the scope for this specification. > 6 Operations on Redirect Reference Resources > > Although non-referencing-aware clients cannot create reference > resources, I move that "non-referencing-aware clients" be replaced with "clients not aware of this protocol". > A reference-aware WebDAV client can act on this response in one of two > ways. It can, like a non-referencing client, resubmit the request to > the URI in the Location header in order to operate on the target > resource. Alternatively, it can resubmit the request to the URI of the > redirect reference resource with the Apply-To-Redirect-Ref header in > order to operate on the reference resource itself. A client can act on this response not only in one of these two ways, but in any way it chooses. I suppose you just want to present two examples of typical behaviour that a client may choose. > If the Apply-To-Redirect-Ref header is present, the request MUST be > applied to the reference resource itself, Here is the same wording problem as in chapter 4, where the wording sounds as if direct references were addressed. > A reference-aware client may know before submitting its request that the > Request-URI identifies a redirect reference resource. In this case, if > the client wants to apply the method to the reference resource, it can > save the round trip caused by the 302 response by using an Apply-To- > Redirect-Ref header in its initial request to the URI. Strictly spoken, this is redundant information and hence should be dropped. But it may be worth to be mentioned in an example. > When > Apply-To-Redirect-Ref is used with GET or HEAD, the Redirect-Ref entity > header MUST be returned, along with all HTTP headers that make sense for > reference resources (for example, Cache-Control, Age, ETag, Expires, and > Last-Modified). As all HTTP headers that make sense for reference resource MUST be returned, I would expect a precise definition of which headers do make sense rather than just listing some examples. Or "MUST" should be replaced with "SHOULD" for these HTTP headers; then just giving some examples seems ok. > A redirect reference resource MAY have a body, though none is defined > for it in this specification. The PUT method can be used, with Apply- > To-Redirect-Ref, to create or replace the body of a redirect reference > resource. Once again, this sounds as if you are assuming that a resource having a body means that the body is stored in a standard data container associated with the redirect reference resource. But, in fact, the specification does not state that a GET will return the same body that was PUT onto the server. Hence I move the behaviour be concretized, using terms such as "request body", "entity body" and "response body". Perhaps it may appropriate to state: "A PUT with Apply-To-Redirect-Ref MAY contain a request body. The semantics of the request body is out of scope for this specification; in particular, this specification does not require the same body to be returned in the response of a subsequent GET with Apply-To-Redirect-Ref header." > Since MKCOL and MKRESOURCE fail when applied to existing resources, if > the client attempts to resubmit the request to the target resource, the > request MUST fail (unless the reference resource is a dangling > reference). Similarly, if the client attempts to resubmit the request > to the reference resource with an Apply-To-Redirect-Ref header, the > request MUST fail. Once again, I move this paragraph be moved into an example section. > Since ORDERPATCH applies only to collections, an ORDERPATCH request with > an Apply-To-Redirect-Ref header on a redirect reference resource MUST > fail. What is ORDERPATCH? Where is it specified? > 6.1 Example: GET on a Redirect Reference Resource > ... > The Redirect-Ref header informs a reference-aware client > ... I move that "reference-aware client" be replaced with "client aware of this protocol". > 6.2 Example: PUT on a Redirect Reference Resource with Apply-To- > Redirect-Ref > ... See the above discussion on the "resource body" issue. ... to be continued ... Juergen Reuter From w3c-dist-auth-request@w3.org Mon Feb 7 12:46:15 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16761 for ; Mon, 7 Feb 2000 12:46:14 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA25775; Mon, 7 Feb 2000 12:39:27 -0500 (EST) Resent-Date: Mon, 7 Feb 2000 12:39:27 -0500 (EST) Resent-Message-Id: <200002071739.MAA25775@www19.w3.org> Message-ID: <389F02E1.4BB3358B@adobe.com> Date: Mon, 07 Feb 2000 18:37:37 +0100 From: Hartmut Warncke Reply-To: hwarncke@Adobe.COM Organization: Adobe Systems X-Mailer: Mozilla 4.7 [en]C-CCK-MCD SGI (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: WebDAV WG Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: IIS 5 and collection locking Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4041 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit Does anybody know why the current WebDAV implementation of Microsoft IIS 5 (RC) does not support collection locking? Are there any plans to change this in the future? Hartmut From w3c-dist-auth-request@w3.org Mon Feb 7 13:27:08 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18182 for ; Mon, 7 Feb 2000 13:27:02 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA27166; Mon, 7 Feb 2000 13:21:04 -0500 (EST) Resent-Date: Mon, 7 Feb 2000 13:21:04 -0500 (EST) Resent-Message-Id: <200002071821.NAA27166@www19.w3.org> Message-ID: <389F0CA1.5759BAB1@adobe.com> Date: Mon, 07 Feb 2000 19:19:13 +0100 From: Hartmut Warncke Reply-To: hwarncke@Adobe.COM Organization: Adobe Systems X-Mailer: Mozilla 4.7 [en]C-CCK-MCD SGI (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: WebDAV WG Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: mod_dav and the If-Header Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4042 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit I have three problems with mod_dav 0.9.14 and hope that someone can help me: It is assumed that /c is a collection which is locked with depth 0 (Locktoken L). 1.) I want to delete /c/f. My interpretation of RFC 2518 is that I have to send Locktoken L within the If-Header of the DELETE command but mod_dav deletes /c/f no matter if I send the Locktoken L or not. 2.) mod_dav does not allow to create a new collection /c/c1 no matter if I send the Locktoken L within the If-Header of the MKCOL command or not. Server response is: "423 Locked". 3.) mod_dav does not allow to copy a collection into /c no matter if I send the Locktoken L within the If-Header of the COPY command or not. Server response is "423 Locked". Hartmut From w3c-dist-auth-request@w3.org Mon Feb 7 20:44:59 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25253 for ; Mon, 7 Feb 2000 20:44:58 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id UAA08528; Mon, 7 Feb 2000 20:40:02 -0500 (EST) Resent-Date: Mon, 7 Feb 2000 20:40:02 -0500 (EST) Resent-Message-Id: <200002080140.UAA08528@www19.w3.org> Date: Mon, 7 Feb 2000 17:40:41 -0800 (PST) From: Greg Stein To: Hartmut Warncke cc: WebDAV WG , dav-dev@lyra.org In-Reply-To: <389F0CA1.5759BAB1@adobe.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: mod_dav and the If-Header Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4043 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Hi Hartmut, I'm also copying the dav-dev@lyra.org mailing list with this. That mailing list is specifically for mod_dav users/developers. On Mon, 7 Feb 2000, Hartmut Warncke wrote: > I have three problems with mod_dav 0.9.14 and hope that someone can help > me: > > It is assumed that /c is a collection which is locked with depth 0 > (Locktoken L). > > 1.) > I want to delete /c/f. My interpretation of RFC 2518 is that I have to > send Locktoken L > within the If-Header of the DELETE command but mod_dav deletes /c/f no > matter > if I send the Locktoken L or not. This is a bug in mod_dav. It doesn't check the parent resource for locks before processing the delete. > 2.) > mod_dav does not allow to create a new collection /c/c1 no matter if > I send the Locktoken L within the If-Header of the MKCOL command or not. > > Server response is: "423 Locked". You need to use a Tagged-list production to say that L applies to /c. If you simply use a No-tag-list, then you are asserting the lock applies to /c/c1 (and /c when the parent is checked). I just tried your scenario (successfully) with the following If: header: If: () > 3.) > mod_dav does not allow to copy a collection into /c no matter if I send > the Locktoken L within the If-Header of the COPY command or not. > Server response is "423 Locked". You are probably seeing the same problem as in (2) (not using a tagged list). Cheers, -g -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Tue Feb 8 06:24:46 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13354 for ; Tue, 8 Feb 2000 06:24:45 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id GAA16763; Tue, 8 Feb 2000 06:14:48 -0500 (EST) Resent-Date: Tue, 8 Feb 2000 06:14:48 -0500 (EST) Resent-Message-Id: <200002081114.GAA16763@www19.w3.org> From: "Rickard Falk" To: Cc: "Kevin Wiggen" Date: Tue, 8 Feb 2000 12:14:29 +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.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal Subject: Lock Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4044 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit I have another 'client side' related question. When I'm issuing a Lock command, can I include the 'If-Unmodified-Since' in the header ( http standard parameter...)? In our client a user can browse through allot of files, without having them locked. Then when he wants to edit the file, he then presses a lock button. But when he presses this button, the client must make sure that the file that he has read, is the latest one. Today I'm doing a Lock, then a Head command to se if the 'Last-Modified' parameter is changed since the Get. It would be much easier if I just could add the 'If-Unmodified-Since' in the Lock request. /Rickard From w3c-dist-auth-request@w3.org Tue Feb 8 06:37:56 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13791 for ; Tue, 8 Feb 2000 06:37:56 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id GAA17044; Tue, 8 Feb 2000 06:33:38 -0500 (EST) Resent-Date: Tue, 8 Feb 2000 06:33:38 -0500 (EST) Resent-Message-Id: <200002081133.GAA17044@www19.w3.org> Date: Tue, 8 Feb 2000 03:34:19 -0800 (PST) From: Greg Stein To: Rickard Falk cc: w3c-dist-auth@w3.org In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: Lock Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4045 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list On Tue, 8 Feb 2000, Rickard Falk wrote: > I have another 'client side' related question. > When I'm issuing a Lock command, can I include the 'If-Unmodified-Since' in > the header ( http standard parameter...)? > In our client a user can browse through allot of files, without having them > locked. Then when he wants to edit the file, he then presses a lock button. > But when he presses this button, the client must make sure that the file > that he has read, is the latest one. Today I'm doing a Lock, then a Head > command to se if the 'Last-Modified' parameter is changed since the Get. It > would be much easier if I just could add the 'If-Unmodified-Since' in the > Lock request. You should be able to use If-Unmodified-Since (mod_dav will check for it). Note that you could also use ETag values to check for changes. I think the ETag is probably the Right Way to look for possible changes on the server. Cheers, -g -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Tue Feb 8 15:21:05 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10102 for ; Tue, 8 Feb 2000 15:21:04 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA29696; Tue, 8 Feb 2000 15:15:52 -0500 (EST) Resent-Date: Tue, 8 Feb 2000 15:15:52 -0500 (EST) Resent-Message-Id: <200002082015.PAA29696@www19.w3.org> Date: Tue, 8 Feb 2000 15:15:36 -0500 Message-Id: <10002082015.AA04053@tantalum> From: "Geoffrey M. Clemm" To: w3c-dist-auth@w3.org In-Reply-To: (message from Greg Stein on Tue, 8 Feb 2000 03:34:19 -0800 (PST)) Subject: Re: Lock Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4046 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list I would like to voice *very* strong support for Greg's suggestion. In the presence of versioning, date comparisons such as "Last-Modified" or "If-Unmodified-Since" do not provide you with reliable information about the accuracy of what you have in your cache. In particular, if an older revision is made the default revision of a versioned resource, it will have an older date, but your cache should be updated with that older value. So ETag values should be the only ones you use to verify that you are seeing the current value of a resource. Cheers, Geoff Date: Tue, 8 Feb 2000 03:34:19 -0800 (PST) From: Greg Stein On Tue, 8 Feb 2000, Rickard Falk wrote: > I have another 'client side' related question. > When I'm issuing a Lock command, can I include the 'If-Unmodified-Since' in > the header ( http standard parameter...)? > In our client a user can browse through allot of files, without having them > locked. Then when he wants to edit the file, he then presses a lock button. > But when he presses this button, the client must make sure that the file > that he has read, is the latest one. Today I'm doing a Lock, then a Head > command to se if the 'Last-Modified' parameter is changed since the Get. It > would be much easier if I just could add the 'If-Unmodified-Since' in the > Lock request. You should be able to use If-Unmodified-Since (mod_dav will check for it). Note that you could also use ETag values to check for changes. I think the ETag is probably the Right Way to look for possible changes on the server. Cheers, -g -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Tue Feb 8 15:53:20 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10889 for ; Tue, 8 Feb 2000 15:53:19 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA00548; Tue, 8 Feb 2000 15:48:22 -0500 (EST) Resent-Date: Tue, 8 Feb 2000 15:48:22 -0500 (EST) Resent-Message-Id: <200002082048.PAA00548@www19.w3.org> From: rickard.falk@excosoft.se Message-Id: <200002082042.VAA04955@mailgate.excosoft.se> To: w3c-dist-auth@w3.org Date: Tue, 8 Feb 2000 21:41:45 GMT X-Mailer: Endymion MailMan Standard Edition v3.0.20 Subject: Re: Lock Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4047 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Ok... But the real issue is if I can make sure that the Lock command tells me, if I'm trying to lock something that has been updated. There is nothing in the webdav spec. that specifies this behaviour, right? Can I even rely on that if I send the E-tag, that the server is supporting this behavour on a Lock command? ( this maybe applies to some other commands to... ) If the resource is changed, what reply can I expect from the server? /Rickard > > I would like to voice *very* strong support for Greg's suggestion. In > the presence of versioning, date comparisons such as "Last-Modified" > or "If-Unmodified-Since" do not provide you with reliable information > about the accuracy of what you have in your cache. In particular, if > an older revision is made the default revision of a versioned > resource, it will have an older date, but your cache should be updated > with that older value. > > So ETag values should be the only ones you use to verify that you are > seeing the current value of a resource. > > Cheers, > Geoff > > Date: Tue, 8 Feb 2000 03:34:19 -0800 (PST) > From: Greg Stein > > On Tue, 8 Feb 2000, Rickard Falk wrote: > > I have another 'client side' related question. > > When I'm issuing a Lock command, can I include the 'If-Unmodified-Since' in > > the header ( http standard parameter...)? > > In our client a user can browse through allot of files, without having them > > locked. Then when he wants to edit the file, he then presses a lock button. > > But when he presses this button, the client must make sure that the file > > that he has read, is the latest one. Today I'm doing a Lock, then a Head > > command to se if the 'Last-Modified' parameter is changed since the Get. It > > would be much easier if I just could add the 'If-Unmodified-Since' in the > > Lock request. > > You should be able to use If-Unmodified-Since (mod_dav will check for it). > > Note that you could also use ETag values to check for changes. I think the > ETag is probably the Right Way to look for possible changes on the server. > > Cheers, > -g > > -- > Greg Stein, http://www.lyra.org/ > > From w3c-dist-auth-request@w3.org Tue Feb 8 20:55:35 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14647 for ; Tue, 8 Feb 2000 20:55:33 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id UAA06030; Tue, 8 Feb 2000 20:50:04 -0500 (EST) Resent-Date: Tue, 8 Feb 2000 20:50:04 -0500 (EST) Resent-Message-Id: <200002090150.UAA06030@www19.w3.org> Message-ID: <7DE119D3D0E15543874F7561EECBDBED0261A145@BEG.platinum.corp.microsoft.com> From: Yaron Goland To: "'hwarncke@Adobe.COM'" , WebDAV WG Date: Tue, 8 Feb 2000 17:47:24 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Subject: RE: IIS 5 and collection locking Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4048 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list It doesn't support collection locking because we need multi-protocol access which means that we can only expose features that are supported by the underlying system. In this case all the protocols (SMB/FTP/WebDAV/NFS/etc.) go through NTFS. NTFS can't lock a directory. Hence our WebDAV implementation can not lock a collection. There are no plans to fix this that I am aware of. > -----Original Message----- > From: Hartmut Warncke [mailto:hwarncke@Adobe.COM] > Sent: Mon, February 07, 2000 9:38 AM > To: WebDAV WG > Subject: IIS 5 and collection locking > > > > Does anybody know why the current WebDAV implementation of Microsoft > IIS 5 (RC) > does not support collection locking? Are there any plans to > change this > in the future? > > Hartmut > From w3c-dist-auth-request@w3.org Tue Feb 8 21:36:41 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15147 for ; Tue, 8 Feb 2000 21:36:41 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id VAA07157; Tue, 8 Feb 2000 21:28:53 -0500 (EST) Resent-Date: Tue, 8 Feb 2000 21:28:53 -0500 (EST) Resent-Message-Id: <200002090228.VAA07157@www19.w3.org> From: Jim Whitehead To: WebDAV WG Date: Tue, 8 Feb 2000 18:24:08 -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) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Subject: Re: Lock Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4049 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit Accidentally caught by the spam filter. - Jim -----Original Message----- From: Barry Schaeffer [mailto:barry@xsystemsinc.com] Sent: Tuesday, February 08, 2000 1:07 PM To: w3c-dist-auth@w3.org Subject: [Moderator Action] Re: Lock This is perhaps somewhat afield from the current thread of discussion and design but having monitored the colloquy over the past several weeks, I am impelled to hazard a comment. I have, over the past number of years, had the opportunity to see the sometimes wide difference between what very intelligent standards developers can reason out, and what often overworked, underfunded production organizations can understand and use. At times, the difference has been so great that the standard never achieved working status because no-one in the field felt responsible to spend the time or money to build a production environment upon it. DSSSL is a good example; extremely elegant but after nearly 15 years, never moving into the mainstream. Even XML has spawned SML, a reaction against perceived over-complexity. Moreover, the software community nearly always indulges in a certain level of summarization in what they elect to support (indeed, often the firms that go the farthest toward full compliance have the most troulble selling their wares with the inevitiable negative result.) While I am in no way qualified to question the efficacy of anything passing in this thread, I am getting the feeling that the nuance of design embodied in the current efforts may have the effect of making the target users feel inadequate to understand or leverage the standard and the software vendors unwilling to fully step up to the bar of support. Let me, then, merely suggest that in each of these threads, a certain capping of the capability (and complexity) might be appropriate. If the user world needs more than is initially made available, they will ask and the standards community will, I'm sure, respond effectively. But going too far initially is usually a good way to become a footnote. Best regards, Barry Schaeffer X.Systems, Inc. ----- Original Message ----- From: To: Sent: Tuesday, February 08, 2000 4:41 PM Subject: Re: Lock > Ok... But the real issue is if I can make sure that the Lock command tells me, > if I'm trying to lock something that has been updated. There is nothing in the > webdav spec. that specifies this behaviour, right? Can I even rely on that if I > send the E-tag, that the server is supporting this behavour on a Lock command? > ( this maybe applies to some other commands to... ) > If the resource is changed, what reply can I expect from the server? > > /Rickard > > > > > I would like to voice *very* strong support for Greg's suggestion. In > > the presence of versioning, date comparisons such as "Last-Modified" > > or "If-Unmodified-Since" do not provide you with reliable information > > about the accuracy of what you have in your cache. In particular, if > > an older revision is made the default revision of a versioned > > resource, it will have an older date, but your cache should be updated > > with that older value. > > > > So ETag values should be the only ones you use to verify that you are > > seeing the current value of a resource. > > > > Cheers, > > Geoff > > > > Date: Tue, 8 Feb 2000 03:34:19 -0800 (PST) > > From: Greg Stein > > > > On Tue, 8 Feb 2000, Rickard Falk wrote: > > > I have another 'client side' related question. > > > When I'm issuing a Lock command, can I include the 'If-Unmodified-Since' > in > > > the header ( http standard parameter...)? > > > In our client a user can browse through allot of files, without having > them > > > locked. Then when he wants to edit the file, he then presses a lock > button. > > > But when he presses this button, the client must make sure that the file > > > that he has read, is the latest one. Today I'm doing a Lock, then a Head > > > command to se if the 'Last-Modified' parameter is changed since the Get. > It > > > would be much easier if I just could add the 'If-Unmodified-Since' in the > > > Lock request. > > > > You should be able to use If-Unmodified-Since (mod_dav will check for it). > > > > Note that you could also use ETag values to check for changes. I think the > > ETag is probably the Right Way to look for possible changes on the server. > > > > Cheers, > > -g > > > > -- > > Greg Stein, http://www.lyra.org/ > > > > > > From w3c-dist-auth-request@w3.org Tue Feb 8 22:14:35 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16270 for ; Tue, 8 Feb 2000 22:14:34 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id WAA07644; Tue, 8 Feb 2000 22:00:06 -0500 (EST) Resent-Date: Tue, 8 Feb 2000 22:00:06 -0500 (EST) Resent-Message-Id: <200002090300.WAA07644@www19.w3.org> Date: Tue, 8 Feb 2000 19:00:00 -0800 (PST) From: Greg Stein To: rickard.falk@excosoft.se cc: w3c-dist-auth@w3.org In-Reply-To: <200002082042.VAA04955@mailgate.excosoft.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: Lock Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4050 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Let's assume that during your initial get, the server returns an ETag header such as: ETag: "abc" When you lock the resource, you can send back something like: If-Match: "abc" If the document has changed, then the ETag should have changed and the server will return 412 (Precondition Failed). Alternatively, you can use WebDAV's If: header like so: If: (["abc"]) You should also receive a 412 (Precondition Failed) in case the ETag no longer matches. And to be explicit: you *can* send the If: or If-*: headers with your LOCK method. By definition, a WebDAV server MUST support the If: header. I can't really determine whether an HTTP server MUST/MAY/SHOULD support the If-Match: header... the language is awfully complex the HTTP spec :-) Cheers, -g ps. fyi: for the mod_dav case, Apache handles If-Match: and providing the ETag: header. mod_dav handles the If: header. On Tue, 8 Feb 2000 rickard.falk@excosoft.se wrote: > Ok... But the real issue is if I can make sure that the Lock command tells me, > if I'm trying to lock something that has been updated. There is nothing in the > webdav spec. that specifies this behaviour, right? Can I even rely on that if I > send the E-tag, that the server is supporting this behavour on a Lock command? > ( this maybe applies to some other commands to... ) > If the resource is changed, what reply can I expect from the server? > > /Rickard > > > > > I would like to voice *very* strong support for Greg's suggestion. In > > the presence of versioning, date comparisons such as "Last-Modified" > > or "If-Unmodified-Since" do not provide you with reliable information > > about the accuracy of what you have in your cache. In particular, if > > an older revision is made the default revision of a versioned > > resource, it will have an older date, but your cache should be updated > > with that older value. > > > > So ETag values should be the only ones you use to verify that you are > > seeing the current value of a resource. > > > > Cheers, > > Geoff > > > > Date: Tue, 8 Feb 2000 03:34:19 -0800 (PST) > > From: Greg Stein > > > > On Tue, 8 Feb 2000, Rickard Falk wrote: > > > I have another 'client side' related question. > > > When I'm issuing a Lock command, can I include the 'If-Unmodified-Since' > in > > > the header ( http standard parameter...)? > > > In our client a user can browse through allot of files, without having > them > > > locked. Then when he wants to edit the file, he then presses a lock > button. > > > But when he presses this button, the client must make sure that the file > > > that he has read, is the latest one. Today I'm doing a Lock, then a Head > > > command to se if the 'Last-Modified' parameter is changed since the Get. > It > > > would be much easier if I just could add the 'If-Unmodified-Since' in the > > > Lock request. > > > > You should be able to use If-Unmodified-Since (mod_dav will check for it). > > > > Note that you could also use ETag values to check for changes. I think the > > ETag is probably the Right Way to look for possible changes on the server. > > > > Cheers, > > -g > > > > -- > > Greg Stein, http://www.lyra.org/ > > > > > > -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Tue Feb 8 22:16:05 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16295 for ; Tue, 8 Feb 2000 22:16:05 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id WAA07750; Tue, 8 Feb 2000 22:03:10 -0500 (EST) Resent-Date: Tue, 8 Feb 2000 22:03:10 -0500 (EST) Resent-Message-Id: <200002090303.WAA07750@www19.w3.org> From: Jim Whitehead To: WebDAV WG Date: Tue, 8 Feb 2000 18:58:29 -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) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Subject: FYI: I-D cutoff, March 10 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4051 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit Even though there are currently no plans for holding a WebDAV working group meeting in Adelaide, we're still affected by the IETF-wide Internet-Draft submission cutoff date of March 10. No Internet Drafts will be able to be submitted from March 10 (after 5PM US Eastern) - March 26. Please plan accordingly. - Jim From w3c-dist-auth-request@w3.org Wed Feb 9 17:11:06 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25399 for ; Wed, 9 Feb 2000 17:11:06 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA10605; Wed, 9 Feb 2000 17:02:26 -0500 (EST) Resent-Date: Wed, 9 Feb 2000 17:02:26 -0500 (EST) Resent-Message-Id: <200002092202.RAA10605@www19.w3.org> From: Jim Whitehead To: WebDAV WG Date: Wed, 9 Feb 2000 13:57:38 -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) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Subject: Bindings protocol teleconf minutes 9 Feb 00 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4052 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit The minutes from the February 9, 2000 Bindings Protocol teleconference are available online at: http://www.ics.uci.edu/pub/ietf/webdav/collection/dt/Minutes000209.txt - Jim From w3c-dist-auth-request@w3.org Wed Feb 9 17:39:13 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26074 for ; Wed, 9 Feb 2000 17:39:13 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA11717; Wed, 9 Feb 2000 17:34:06 -0500 (EST) Resent-Date: Wed, 9 Feb 2000 17:34:06 -0500 (EST) Resent-Message-Id: <200002092234.RAA11717@www19.w3.org> From: Jim Whitehead To: fielding@ebuilt.com, w3c-dist-auth@w3.org MMDF-Warning: Parse error in original version of preceding line at gremlin-relay.ics.uci.edu Date: Wed, 9 Feb 2000 14:29:08 -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) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Subject: Qualities of URLs and resources Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4053 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit Roy Fielding writes, in his post originally titled, "draft-ietf-webdav-binding-protocol-02" : > > URI Mapping > > A relation between an absolute URI and a resource. For an > > absolute URI U and the resource it identifies R, the URI mapping > > can be thought of as (U => R). Since a resource can represent > > items that are not network retrievable, as well as those that are, > > it is possible for a resource to have zero, one, or many URI > > mappings. Mapping a resource to an "http" scheme URL makes it > > possible to submit HTTP protocol requests to the resource using > > the URL. > > Actually, it is more like ({U,t} -R-> {V1, V2, ...}), where t is the > current time, R is the resource, -R-> is a mapping function that has > been implemented according to the semantics of resource R), and the range > is a set of values representing that resource at time t. OK, so this notation makes it much more clear that a resource is a mapping function. However, if we just call the mapping function "R", this allows us to express that multiple URI can be associated with the same mapping function. That is, the binding spec. is based on the mapping from URI to R being many to one. From your post, I think you believe it is one to one. If so, this is at the heart of our disagreement. So, using your notation, I would re-write the full mapping as: {URI1, URI2, ... URIn} -UMap-> resource -RMap-> {V1, V2, ... Vm} Where UMap is the URI to resource mapping function, and RMap is the resource to value mapping function. I omit time since it's really tangential to our discussion, assuming that the entire set of mappings occurs at a given time t. In this view, the term "resource" as used in RFC 2396 is both the output of the UMap function, and the RMap mapping function, but *not* the set of values. As near as I can tell, this view is entirely consistent with the definition of resource given in RFC 2396: Resource A resource can be anything that has identity. Familiar examples include an electronic document, an image, a service (e.g., "today's weather report for Los Angeles"), and a collection of other resources. Not all resources are network "retrievable"; e.g., human beings, corporations, and bound books in a library can also be considered resources. The resource is the conceptual mapping to an entity or set of entities, not necessarily the entity which corresponds to that mapping at any particular instance in time. Thus, a resource can remain constant even when its content---the entities to which it currently corresponds---changes over time, provided that the conceptual mapping is not changed in the process. There is nothing in RFC 2396 that either states or requires the URI to resource mapping be one to one. A resource can still be a mapping, even if it has multiple URIs to it. - Jim From w3c-dist-auth-request@w3.org Wed Feb 9 23:52:35 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03605 for ; Wed, 9 Feb 2000 23:52:35 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id XAA20704; Wed, 9 Feb 2000 23:47:41 -0500 (EST) Resent-Date: Wed, 9 Feb 2000 23:47:41 -0500 (EST) Resent-Message-Id: <200002100447.XAA20704@www19.w3.org> From: "Larry Masinter" To: "Jim Whitehead" Cc: , Date: Wed, 9 Feb 2000 20:46:30 -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) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 In-Reply-To: Subject: RE: Qualities of URLs and resources Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4054 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit Roy: > Actually, it is more like ({U,t} -R-> {V1, V2, ...}), where t is the > current time, R is the resource, -R-> is a mapping function that has > been implemented according to the semantics of resource R), and the range > is a set of values representing that resource at time t. Jim: > So, using your notation, I would re-write the full mapping as: > {URI1, URI2, ... URIn} -UMap-> resource -RMap-> {V1, V2, ... Vm} > Where UMap is the URI to resource mapping function, and RMap is the resource > to value mapping function. I omit time since it's really tangential to our > discussion, assuming that the entire set of mappings occurs at a given time > t. Neither of these notations captures content negotiation, and it isn't OK to remove 't'. The whole *point* is to understand what are the things that are stable over time and which things can change, and how. If you just look 'at an instant' then there's no meaningful way of distinguishing URLs from resources, and collapsing -UMap->. I'm guessing you want to make UMap vary more slowly and only with explicit operations (BIND and UNBIND) while RMap encompases all of the content negotiation & time varying behavior of resources without having any explicit operation modify the mapping. From w3c-dist-auth-request@w3.org Thu Feb 10 09:08:58 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25386 for ; Thu, 10 Feb 2000 09:08:58 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id JAA01171; Thu, 10 Feb 2000 09:04:19 -0500 (EST) Resent-Date: Thu, 10 Feb 2000 09:04:19 -0500 (EST) Resent-Message-Id: <200002101404.JAA01171@www19.w3.org> Date: Thu, 10 Feb 2000 08:53:49 -0500 Message-Id: <10002101353.AA04843@tantalum> From: "Geoffrey M. Clemm" To: w3c-dist-auth@w3.org In-Reply-To: Subject: Re: Qualities of URLs and resources Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4055 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list It's not that time or content negotiation aren't important, but just that including these aspects of the RMap function was not relevant to the point being made. Perhaps modifying the notation will help clarify. Let's use the notation: R:{U,T}->V instead of: {U,t} -R-> {V1, V2, ...} You can expand this to include content negotiation by adding another argument to the R function, i.e. R:{U,T,C}->V. (U is the set of URI's, T is the set of points in time, C is the set of content headers, and V is the set of values, where each value is an entity body and a set of properties). Jim's point is that a "resource" is a function RMap:{T,C}->V. There are more arguments to the RMap function, i.e. the request body and all the other headers, but that doesn't affect the discussion. Let's let RES be the set of all such functions (i.e. each member of RES is some function that maps time and a content header into a value). There is another function, which Jim calls UMap, which maps URI's into resources, i.e. UMap:U->RES. In other (possibly more obscure :-) words, UMap is the result of currying the URI's out of the R function, a resource is a member of the range of UMap. The BIND method gives you control over the UMap function (as do MOVE and DELETE). The semantics of the DAV:resourceid property is that it is not affected by either time or content headers (or any other header). I.e.: for-all RMap in RES if RMap supports the BIND method then there-exists a string, s, such that for-all t,c in T,c the DAV:resoureid property of RMap(t,c) is equal to s. Cheers, Geoff Roy: Actually, it is more like ({U,t} -R-> {V1, V2, ...}), where t is the current time, R is the resource, -R-> is a mapping function that has been implemented according to the semantics of resource R), and the range is a set of values representing that resource at time t. Jim: So, using your notation, I would re-write the full mapping as: {URI1, URI2, ... URIn} -UMap-> resource -RMap-> {V1, V2, ... Vm} Where UMap is the URI to resource mapping function, and RMap is the resource to value mapping function. I omit time since it's really tangential to our discussion, assuming that the entire set of mappings occurs at a given time t. From: "Larry Masinter" Neither of these notations captures content negotiation, and it isn't OK to remove 't'. The whole *point* is to understand what are the things that are stable over time and which things can change, and how. If you just look 'at an instant' then there's no meaningful way of distinguishing URLs from resources, and collapsing -UMap->. I'm guessing you want to make UMap vary more slowly and only with explicit operations (BIND and UNBIND) while RMap encompases all of the content negotiation & time varying behavior of resources without having any explicit operation modify the mapping. From w3c-dist-auth-request@w3.org Thu Feb 10 21:18:45 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14364 for ; Thu, 10 Feb 2000 21:18:40 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id VAA18391; Thu, 10 Feb 2000 21:14:10 -0500 (EST) Resent-Date: Thu, 10 Feb 2000 21:14:10 -0500 (EST) Resent-Message-Id: <200002110214.VAA18391@www19.w3.org> From: Jim Whitehead To: Larry Masinter Cc: w3c-dist-auth@w3.org MMDF-Warning: Parse error in original version of preceding line at gremlin-relay.ics.uci.edu Date: Thu, 10 Feb 2000 18:09:18 -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) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Subject: RE: Qualities of URLs and resources Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4056 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit Larry Masinter writes: > Neither of these notations captures content negotiation, and it isn't > OK to remove 't'. The whole *point* is to understand what are > the things that are stable over time and which things can change, and how. Well, it was my intent that the set of values (V1, V2, ... Vn) represent variants of the resource at a particular instant in time, and hence I thought I was modeling content negotiated resources. But, as Geoff Clemm points out, both Roy and I did omit the Accept headers as an input to the RMap function. > If you just look 'at an instant' then there's no meaningful way > of distinguishing URLs from resources, and collapsing -UMap->. I'm not sure what you mean here, since I believe it is meaningful to discuss, conceptually, the difference between URI mappings and Resource mappings at a particular instant. Certainly it would take more than an instant for a client to *operationally* determine a resource has multiple URI mappings. That said, I'm more than happy to chuck time back in there. It does have the benefit that it permits a formal description of the operation of bind on URIs. I'll formall define bind's effect on URIs as: URIbindset = bind(targetURI, collectionURI, segement, t) The bind function takes as input a URI of the resource being bound-to, the URI of the collection resource where the new binding will reside, a URI segment giving the new name of the binding in the collection, and the current time. The bind function produces as output, the set of URIs that can now be used to access the resource that was identified by targetURI at time t. Now, the change caused by bind to the URI mapping function for a resource R can be described as: UMap(t+ epsilon) = UMap(t) + bind(targetURI, collectionURI, segment, t) Where epsilon is the time required to execute the bind method, and UMap is the URI mapping function for the resource identified by the target URI. (Hmm, don't like the fact that the resource is now implicit here ... perhaps I really want to use the inverse function UMap-1(UMap(targetURI, t)), that is the set of URIs that identify the resource that is mapped to the targetURI. This would look like: UMap-1(UMap(targetURI, t), t+epsilon) = UMap-1(UMap(targetURI,t)) + bind(targetURI, collectionURI, segment, t) Which is ugly, but perhaps more precise. > I'm guessing you want to make UMap vary more slowly and only with > explicit operations (BIND and UNBIND) while RMap encompases all of > the content negotiation & time varying behavior of resources without > having any explicit operation modify the mapping. I agree with this, although I'll pick the nit that UMap doesn't necessarily have to vary more slowly than RMap, especially if RMap represents a static resource. - Jim From w3c-dist-auth-request@w3.org Fri Feb 11 00:41:37 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18961 for ; Fri, 11 Feb 2000 00:41:24 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id AAA20725; Fri, 11 Feb 2000 00:36:21 -0500 (EST) Resent-Date: Fri, 11 Feb 2000 00:36:21 -0500 (EST) Resent-Message-Id: <200002110536.AAA20725@www19.w3.org> To: Jim Whitehead cc: fielding@ebuilt.com, w3c-dist-auth@w3.org In-reply-to: Your message of "Wed, 09 Feb 2000 14:29:08 PST." Date: Thu, 10 Feb 2000 21:36:03 -0800 From: "Roy T. Fielding" Message-ID: <200002102136.aa15064@gremlin-relay.ics.uci.edu> Subject: Re: Qualities of URLs and resources Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4057 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list >> Actually, it is more like ({U,t} -R-> {V1, V2, ...}), where t is the >> current time, R is the resource, -R-> is a mapping function that has >> been implemented according to the semantics of resource R), and the range >> is a set of values representing that resource at time t. > >OK, so this notation makes it much more clear that a resource is a mapping >function. However, if we just call the mapping function "R", this allows us >to express that multiple URI can be associated with the same mapping >function. That is, the binding spec. is based on the mapping from URI to R >being many to one. From your post, I think you believe it is one to one. >If so, this is at the heart of our disagreement. No. I've said many times that a resource can have many identifiers. In other words, you can have two different URI that *mean* the same thing when used to access a server. But, you can also have two URI that result in the same mechanism being used upon access to the server, and yet those two URI point to two different resources because they don't mean the same thing. What the bindings spec gets wrong is that at no time whatsoever does the server or the client know the meaning of the URI, and therefore cannot know whether a new binding represents a new identifier for the resource or a new identifier for a *new* resource that just happens to share the same implementation mechanism at that time. That's because the resource is the concept, not the representation of that concept and not the URI-to-representation mapping mechanism on the server. There are no resources on the server; just mechanisms that supply answers across an abstract interface defined by resources. The reason the protocol talks about these things as resources is because the protocol is not allowed to define the mechanisms on either side of the abstract interface. It may seem odd, but this is the essence of what makes the Web work across so many different implementations. The reason I said that the bindings spec should just *treat* the interface as if the URI:R is one to one is because that way the issues of maintaining the semantic mapping are left to the author, while the interface, which is always manipulating resources, has the effect of manipulating URI mappings. In other words, if you just remove *everything* in the bindings spec that defines an implementation, including all of the attempts at defining bindings as being something other than resources, then what you will end up with is a very simple protocol for manipulating URI mappings on remote servers. ....Roy From w3c-dist-auth-request@w3.org Fri Feb 11 01:41:14 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21852 for ; Fri, 11 Feb 2000 01:41:14 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id BAA21540; Fri, 11 Feb 2000 01:36:52 -0500 (EST) Resent-Date: Fri, 11 Feb 2000 01:36:52 -0500 (EST) Resent-Message-Id: <200002110636.BAA21540@www19.w3.org> Message-ID: <7DE119D3D0E15543874F7561EECBDBED0261A15E@BEG.platinum.corp.microsoft.com> From: Yaron Goland To: "'w3c-dist-auth@w3.org'" Date: Thu, 10 Feb 2000 22:33:45 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF745A.3851A37A" Subject: Yaron.Redirect.Servers Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4059 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF745A.3851A37A Content-Type: text/plain; charset="iso-8859-1" The redirect spec repeatedly refers to servers, e.g. in the last sentence of the third paragraph and the last sentence of the second to last paragraph of the introduction. In general the term server is misleading because it focuses the user's attention on the box. For example, a reader of the redirect spec would most likely come away thinking that if two resources are on the same server then one doesn't need to link them but can use some other feature, maybe bind, since being on the same box somehow confers special relationships. As anyone who has used files across volumes knows, being on the same servers doesn't mean much of anything. In addition the reader is likely to believe that bind and similar features won't work at all across two different servers when advanced systems may be able to do this. The idea of a server has its place for certain HTTP transport issues but should never be mentioned in an application context. The actual physical box that a resource resides on is largely irrelevant in terms of what features are available between two resources. As such I move that the term "server" be universally replaced with phrase "unrelated systems". ------_=_NextPart_001_01BF745A.3851A37A Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Yaron.Redirect.Servers

The redirect spec repeatedly = refers to servers, e.g. in the last sentence of the third paragraph and = the last sentence of the second to last paragraph of the introduction. = In general the term server is misleading because it focuses the user's = attention on the box. For example, a reader of the redirect spec would = most likely come away thinking that if two resources are on the same = server then one doesn't need to link them but can use some other = feature, maybe bind, since being on the same box somehow confers = special relationships. As anyone who has used files across volumes = knows, being on the same servers doesn't mean much of anything. In = addition the reader is likely to believe that bind and similar features = won't work at all across two different servers when advanced systems = may be able to do this. The idea of a server has its place for certain = HTTP transport issues but should never be mentioned in an application = context. The actual physical box that a resource resides on is largely = irrelevant in terms of what features are available between two = resources. As such I move that the term "server" be = universally replaced with phrase "unrelated = systems".

------_=_NextPart_001_01BF745A.3851A37A-- From w3c-dist-auth-request@w3.org Fri Feb 11 01:41:18 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21871 for ; Fri, 11 Feb 2000 01:41:18 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id BAA21608; Fri, 11 Feb 2000 01:37:02 -0500 (EST) Resent-Date: Fri, 11 Feb 2000 01:37:02 -0500 (EST) Resent-Message-Id: <200002110637.BAA21608@www19.w3.org> Message-ID: <7DE119D3D0E15543874F7561EECBDBED0261A159@BEG.platinum.corp.microsoft.com> From: Yaron Goland To: w3c-dist-auth@w3.org Date: Thu, 10 Feb 2000 22:29:57 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF745A.435D486E" Subject: Yaron.Redirect.NoBind Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4060 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF745A.435D486E Content-Type: text/plain; charset="iso-8859-1" Paragraphs 1 & 3 of the abstract and the 5th paragraph of the introduction of the redirect spec mention the bind spec. As the redirect spec's functionality is neither directly nor indirectly related to the bind spec's functionality I can find no compelling reason to mention one in the other. This is especially the case in mentioning the specific RFC # of the bind spec thus preventing the bind spec from progressing on the standards track until the redirect spec is standardized. Therefore I move that at minimum the RFC # be removed and preferably all mention of the bind spec be removed. ------_=_NextPart_001_01BF745A.435D486E Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Yaron.Redirect.NoBind

Paragraphs 1 & 3 of the = abstract and the 5th paragraph of the introduction of the redirect spec = mention the bind spec. As the redirect spec's functionality is neither = directly nor indirectly related to the bind spec's functionality I can = find no compelling reason to mention one in the other. This is = especially the case in mentioning the specific RFC # of the bind spec = thus preventing the bind spec from progressing on the standards track = until the redirect spec is standardized. Therefore I move that at = minimum the RFC # be removed and preferably all mention of the bind = spec be removed.

------_=_NextPart_001_01BF745A.435D486E-- From w3c-dist-auth-request@w3.org Fri Feb 11 01:41:24 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21882 for ; Fri, 11 Feb 2000 01:41:24 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id BAA21512; Fri, 11 Feb 2000 01:36:47 -0500 (EST) Resent-Date: Fri, 11 Feb 2000 01:36:47 -0500 (EST) Resent-Message-Id: <200002110636.BAA21512@www19.w3.org> Message-ID: <7DE119D3D0E15543874F7561EECBDBED0261A15C@BEG.platinum.corp.microsoft.com> From: Yaron Goland To: "'w3c-dist-auth@w3.org'" Date: Thu, 10 Feb 2000 22:32:12 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF745A.3856682E" Subject: Yaron.Redirect.Forwarding Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4058 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF745A.3856682E Content-Type: text/plain; charset="iso-8859-1" The term "forward requests" is used multiple times in the redirect draft, for example, in the 4th paragraph of the introduction. I believe this phrase is likely to cause confusion amongst implementers as it leads one to imagine that the redirect reference resource is performing the forwarding. While the rest of the draft is clear that this is not the case I believe it is unfortunate to confuse implementers with this language. I believe that the word "redirect" is more in keeping with generally accepted HTTP language than "forward"ing. Therefore I move that the word "forward" be replaced with the phrase "redirect" throughout the draft. ------_=_NextPart_001_01BF745A.3856682E Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Yaron.Redirect.Forwarding

The term "forward = requests" is used multiple times in the redirect draft, for = example, in the 4th paragraph of the introduction. I believe this = phrase is likely to cause confusion amongst implementers as it leads = one to imagine that the redirect reference resource is performing the = forwarding. While the rest of the draft is clear that this is not the = case I believe it is unfortunate to confuse implementers with this = language. I believe that the word "redirect" is more in = keeping with generally accepted HTTP language than = "forward"ing.  Therefore I move that the word = "forward" be replaced with the phrase "redirect" = throughout the draft.

------_=_NextPart_001_01BF745A.3856682E-- From w3c-dist-auth-request@w3.org Fri Feb 11 01:41:34 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21906 for ; Fri, 11 Feb 2000 01:41:33 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id BAA21664; Fri, 11 Feb 2000 01:37:18 -0500 (EST) Resent-Date: Fri, 11 Feb 2000 01:37:18 -0500 (EST) Resent-Message-Id: <200002110637.BAA21664@www19.w3.org> Message-ID: <7DE119D3D0E15543874F7561EECBDBED0261A15B@BEG.platinum.corp.microsoft.com> From: Yaron Goland To: "'w3c-dist-auth@w3.org'" Date: Thu, 10 Feb 2000 22:31:34 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF745A.44A64CF2" Subject: Yaron.Redirect.Integrity Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4062 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF745A.44A64CF2 Content-Type: text/plain; charset="iso-8859-1" The 7th paragraph of the introduction of the redirect spec contains the sentence "Servers are not required to enforce the integrity of redirect references". This sentence is problematical from two view points. First, it uses the undefined term integrity. Second, it references the term server (see Yaron.Redirect.Servers). As such I move that the text be changed to read "Redirect reference resources blindly record the location of their target. So if the target should move or be deleted the target of the redirect reference resource will be left dangling." ------_=_NextPart_001_01BF745A.44A64CF2 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Yaron.Redirect.Integrity

The 7th paragraph of the = introduction of the redirect spec contains the sentence "Servers = are not required to enforce the integrity of redirect references". = This sentence is problematical from two view points. First, it uses the = undefined term integrity. Second, it references the term server (see = Yaron.Redirect.Servers). As such I move that the text be changed to = read "Redirect reference resources blindly record the location of = their target. So if the target should move or be deleted the target of = the redirect reference resource will be left dangling."

------_=_NextPart_001_01BF745A.44A64CF2-- From w3c-dist-auth-request@w3.org Fri Feb 11 01:41:40 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21921 for ; Fri, 11 Feb 2000 01:41:40 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id BAA21635; Fri, 11 Feb 2000 01:37:10 -0500 (EST) Resent-Date: Fri, 11 Feb 2000 01:37:10 -0500 (EST) Resent-Message-Id: <200002110637.BAA21635@www19.w3.org> Message-ID: <7DE119D3D0E15543874F7561EECBDBED0261A15A@BEG.platinum.corp.microsoft.com> From: Yaron Goland To: w3c-dist-auth@w3.org Date: Thu, 10 Feb 2000 22:30:45 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF745A.455DE204" Subject: Yaron.Redirect.ReallyNoBind Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4061 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF745A.455DE204 Content-Type: text/plain; charset="iso-8859-1" The 6th and 8th paragraphs of the introduction of the redirect spec go into a discussion of the difference between bind and redirect resources. These sections will only serve to confuse the reader as one need understand nothing about bind in order to successfully implement redirect. As such I move that the sections discussing bind as compared to redirect resources be removed. ------_=_NextPart_001_01BF745A.455DE204 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Yaron.Redirect.ReallyNoBind

The 6th and 8th paragraphs = of the introduction of the redirect spec go into a discussion of the = difference between bind and redirect resources. These sections will = only serve to confuse the reader as one need understand nothing about = bind in order to successfully implement redirect. As such I move that = the sections discussing bind as compared to redirect resources be = removed.

------_=_NextPart_001_01BF745A.455DE204-- From w3c-dist-auth-request@w3.org Fri Feb 11 01:41:59 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21945 for ; Fri, 11 Feb 2000 01:41:59 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id BAA21693; Fri, 11 Feb 2000 01:37:28 -0500 (EST) Resent-Date: Fri, 11 Feb 2000 01:37:28 -0500 (EST) Resent-Message-Id: <200002110637.BAA21693@www19.w3.org> Message-ID: <7DE119D3D0E15543874F7561EECBDBED0261A15D@BEG.platinum.corp.microsoft.com> From: Yaron Goland To: "'w3c-dist-auth@w3.org'" Date: Thu, 10 Feb 2000 22:33:05 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF745A.409DF2B8" Subject: Yaron.Redirect.NotHierarchical Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4063 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF745A.409DF2B8 Content-Type: text/plain; charset="iso-8859-1" The first sentence of the second paragraph of the introduction of the redirect spec asserts that the URIs of WebDAV compliant resources match to collections. The WebDAV standard makes no such requirement. I therefore move that this sentence be stricken. ------_=_NextPart_001_01BF745A.409DF2B8 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Yaron.Redirect.NotHierarchical

The first sentence of the = second paragraph of the introduction of the redirect spec asserts that = the URIs of WebDAV compliant resources match to collections. The WebDAV = standard makes no such requirement. I therefore move that this sentence = be stricken.

------_=_NextPart_001_01BF745A.409DF2B8-- From w3c-dist-auth-request@w3.org Fri Feb 11 02:45:11 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01886 for ; Fri, 11 Feb 2000 02:45:11 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id CAA22656; Fri, 11 Feb 2000 02:40:44 -0500 (EST) Resent-Date: Fri, 11 Feb 2000 02:40:44 -0500 (EST) Resent-Message-Id: <200002110740.CAA22656@www19.w3.org> Message-ID: <7DE119D3D0E15543874F7561EECBDBED02619E4B@BEG.platinum.corp.microsoft.com> From: Yaron Goland To: "'w3c-dist-auth@w3.org'" Date: Thu, 10 Feb 2000 23:40:16 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF7463.2A296626" Subject: Yaron.Redirect.NoReferenceorDirectResource Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4064 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF7463.2A296626 Content-Type: text/plain; charset="iso-8859-1" The terminology section of the redirect draft defines a "Reference Resource". However the term is never meaningfully used. It asserts some sort of object hierarchy but never really does a good job of explaining why this hierarchy is necessary or how it helps someone implementing the redirect draft. In fact the term is only used in defining the redirect reference resource and the direct reference resource. However I can't find a good reason that an implementer needs to know about direct reference resources. Direct reference resources are mentioned exactly twice in the entire draft and don't seem to add anything useful to the draft. I think that attempting to define some sort of object model for resource types that are not standardized is just a way to cause confusion. As such I move that the definitions of both Reference Resource and Direct Reference Resource as well as all references to these two terms be removed from the draft. As removing these definitions will confuse users as to the meaning of a Redirect Reference Resource, since they won't know what a reference resource is, I move that the term be changed in the draft to read Redirect Resource. The actual definition of the Redirect Resource also needs to take into account Yaron.Redirect.Forwarding as well as the slightly strange usage of the phrase "HTTP 1.1 302" which should just read "302" since this draft is based on HTTP/1.1. Therefore I move that the definition of Redirect Reference Resource be changed to read: Redirect Resource A resource created to redirect all requests made to it, using 302 (Found), to a defined target resource. ------_=_NextPart_001_01BF7463.2A296626 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Yaron.Redirect.NoReferenceorDirectResource

The terminology section of = the redirect draft defines a "Reference Resource". However = the term is never meaningfully used. It asserts some sort of object = hierarchy but never really does a good job of explaining why this = hierarchy is necessary or how it helps someone implementing the = redirect draft. In fact the term is only used in defining the redirect = reference resource and the direct reference resource. However I can't = find a good reason that an implementer needs to know about direct = reference resources. Direct reference resources are mentioned exactly = twice in the entire draft and don't seem to add anything useful to the = draft. I think that attempting to define some sort of object model for = resource types that are not standardized is just a way to cause = confusion. As such I move that the definitions of both Reference = Resource and Direct Reference Resource as well as all references to = these two terms be removed from the draft.

As removing these = definitions will confuse users as to the meaning of a Redirect = Reference Resource, since they won't know what a reference resource is, = I move that the term be changed in the draft to read Redirect Resource. = The actual definition of the Redirect Resource also needs to take into = account Yaron.Redirect.Forwarding as well as the slightly strange usage = of the phrase "HTTP 1.1 302" which should just read = "302" since this draft is based on HTTP/1.1.

Therefore I move that the = definition of Redirect Reference Resource be changed to read:

Redirect Resource
A resource created to = redirect all requests made to it, using 302 (Found), to a defined = target resource.

------_=_NextPart_001_01BF7463.2A296626-- From w3c-dist-auth-request@w3.org Fri Feb 11 02:46:34 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01898 for ; Fri, 11 Feb 2000 02:46:31 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id CAA22695; Fri, 11 Feb 2000 02:42:19 -0500 (EST) Resent-Date: Fri, 11 Feb 2000 02:42:19 -0500 (EST) Resent-Message-Id: <200002110742.CAA22695@www19.w3.org> Message-ID: <7DE119D3D0E15543874F7561EECBDBED0261A160@BEG.platinum.corp.microsoft.com> From: Yaron Goland To: "'w3c-dist-auth@w3.org'" Date: Thu, 10 Feb 2000 23:41:56 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF7463.65B37FB0" Subject: Yaron.Redirect.4th2nd Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4065 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF7463.65B37FB0 Content-Type: text/plain; charset="iso-8859-1" The first sentence of the second paragraph of section 4 reads: "A redirect reference resource never automatically forwards requests to its target resource." I believe that the word "automatically" is misleading in that it implies that if one sends the right header or body the redirect resource might actually forward the request for you. In addition this sentence runs afoul of Yaron.Redirect.Forwarding. As such I move that this sentence be changed to read "A redirect resource blindly issues 302 (Found) redirect responses point at its target resource." The second sentence of the same paragraph reads: "It is this characteristic that distinguishes redirect reference resource from direct reference resources and from bindings." The removal of this sentence, consistent with Yaron.Redirect.NoReferenceorDirectResource, would remove the only reference to direct reference resources outside of the terminology section. Therefore I move that this entire sentence be removed from the draft. The last two sentences of the same paragraph read: "It is also what insures that redirect reference resources will be simple to implement and that cross-server references will be possible. If the redirect reference resource were required to forward requests automatically, the server would need proxy capabilities in order to support cross-server references." I found the language confusing and it violated Yaron.Redirect.Servers. Therefore I move that the language be altered to read: "Redirect resources bring the same benefits as links in HTML documents. They can be created and maintained without the involvement or even knowledge of their target resource. This reduces the cost of linking between resources." ------_=_NextPart_001_01BF7463.65B37FB0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Yaron.Redirect.4th2nd

The first sentence of the = second paragraph of section 4 reads: "A redirect reference = resource never automatically forwards requests to its target = resource."

I believe that the word = "automatically" is misleading in that it implies that if one = sends the right header or body the redirect resource might actually = forward the request for you. In addition this sentence runs afoul of = Yaron.Redirect.Forwarding. As such I move that this sentence be changed = to read "A redirect resource blindly issues 302 (Found) redirect = responses point at its target resource."

The second sentence of the = same paragraph reads: "It is this characteristic that = distinguishes redirect reference resource from direct reference = resources and from bindings."

The removal of this = sentence, consistent with Yaron.Redirect.NoReferenceorDirectResource, = would remove the only reference to direct reference resources outside = of the terminology section. Therefore I move that this entire sentence = be removed from the draft.

The last two sentences of = the same paragraph read: "It is also what insures that redirect = reference resources will be simple to implement and that cross-server = references will be possible.  If the redirect reference resource = were required to forward requests automatically, the server would need = proxy capabilities in order to support cross-server = references."

I found the language = confusing and it violated Yaron.Redirect.Servers. Therefore I move that = the language be altered to read: "Redirect resources bring the = same benefits as links in HTML documents. They can be created and = maintained without the involvement or even knowledge of their target = resource. This reduces the cost of linking between = resources."

------_=_NextPart_001_01BF7463.65B37FB0-- From w3c-dist-auth-request@w3.org Fri Feb 11 02:48:15 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01911 for ; Fri, 11 Feb 2000 02:48:15 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id CAA22734; Fri, 11 Feb 2000 02:43:54 -0500 (EST) Resent-Date: Fri, 11 Feb 2000 02:43:54 -0500 (EST) Resent-Message-Id: <200002110743.CAA22734@www19.w3.org> Message-ID: <7DE119D3D0E15543874F7561EECBDBED0261A161@BEG.platinum.corp.microsoft.com> From: Yaron Goland To: "'w3c-dist-auth@w3.org'" Date: Thu, 10 Feb 2000 23:43:35 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF7463.9E50F6D6" Subject: Yaron.Redirect.NoWebDAV#1 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4066 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF7463.9E50F6D6 Content-Type: text/plain; charset="iso-8859-1" The redirect spec requires the use of WebDAV in order to create and query redirect resources as it makes use of the WebDAV property mechanism. However I am having trouble finding a compelling reason to require WebDAV just to implement redirect resources. A redirect resource is, in my opinion, just an enhancement to HTTP/1.1. HTTP/1.1 introduced the concept of a 302 response but did not concurrently introduce the administrative tools necessary in order to specify when a 302 response should be returned. The redirect draft helps to address this deficiency but unless there is a compelling reason to do so, it should address this deficiency in the simplest manner possible, preferably only using the tools provided by HTTP/1.1. The argument has been made that the tools introduced in the redirect draft constitute the first step in a series of additional extensions that will be made in the future. For example, the Delta-V group has certain ideas about how to use MKRESOURCE. While HTTP has a rich tradition of enabling future extensions it has always wisely chosen in the short term to limit itself to immediate needs only while ensuring that future expansion is possible. Hence the test for the redirect draft's success should be only how well it addresses the immediate needs of redirect resources and not how well it addresses the shifting needs of various future proposals. The current functionality of the redirect resource is very simple, specify a resource that, by default, will return a 302 (found) response to a specified target resource. There does not appear to be any compelling reason why the creation of a redirect resource should require anything beyond a single header on the creation request to specify the URI of the target resource. The use of a body to create a redirect resource is clearly unnecessary. This is not to say that it may not prove to be necessary in the future. However WebDAV, in particular, has set a precedent for how to deal with this sort of situation that I believe would well serve the redirect spec. In the COPY/MOVE methods we use a single destination header, rather than a body, to specify where the results of the method are to appear. One can imagine a number of reasons why one would want to have a more powerful way to specify the destination of the method. For example, one might want to specify multiple destination URIs in order to use a single round trip to cause multiple COPY/MOVE's. HTTP's header format is not well suited for this sort of extension and WebDAV's definition of the destination header wisely does not allow for it. Rather WebDAV specifies that a body MAY be included in a COPY/MOVE method but is to be ignored if not understood. This provide for a very powerful extension mechanism. For example, imagine one wanted to issue the COPY/MOVE to multiple destinations but one wasn't sure if the source supported this feature. Rather than wasting a round trip finding out if the source supports the feature one could put a single destination in the destination header and then use the body to specify the rest of the destinations. If the resource supports the extension then all destinations will be COPY/MOVE'd to. If the resource doesn't support the extension then at least one copy will be issued and the client will realize that the rest didn't occur (because the resource ignored the body) through the 207 response. If, on the other hand, one only wanted the COPY/MOVE to proceed if the resource understood the multiple destination extension then the COPY/MOVE could be issued without a destination header, just with a body. Resources that didn't support the extension would fail the request due to the absence of the destination header thus ensuring that only resources that understood the extension will actually execute the method. One could rightfully argue that this is an unnecessary complication. Why not start with a body that allows extension in the first place? The counter argument is that one should always start with as minimal functionality as possibly and only expand, grudgingly, as required. A header is much easier to process than a body and so clearly is the simplest mechanism available. This line of reasoning is especially compelling in the context of redirect resources. Given the obvious utility of redirect resources to all HTTP systems, not just WebDAV, it is incumbent upon the redirect spec to cleave as closely as possible to the base HTTP system and require as few extensions from it as possible. Therefore I believe that the current proposal, which requires the introduction of a full XML processing system just to handle a simple redirect resource is unsupportable. As such I move that whatever design is chosen for creating a redirect resource it MUST NOT include the use of a request body. ------_=_NextPart_001_01BF7463.9E50F6D6 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Yaron.Redirect.NoWebDAV#1

The redirect spec requires = the use of WebDAV in order to create and query redirect resources as it = makes use of the WebDAV property mechanism. However I am having trouble = finding a compelling reason to require WebDAV just to implement = redirect resources. A redirect resource is, in my opinion, just an = enhancement to HTTP/1.1.

HTTP/1.1 introduced the = concept of a 302 response but did not concurrently introduce the = administrative tools necessary in order to specify when a 302 response = should be returned.

The redirect draft helps to = address this deficiency but unless there is a compelling reason to do = so, it should address this deficiency in the simplest manner possible, = preferably only using the tools provided by HTTP/1.1.

The argument has been made = that the tools introduced in the redirect draft constitute the first = step in a series of additional extensions that will be made in the = future. For example, the Delta-V group has certain ideas about how to = use MKRESOURCE. While HTTP has a rich tradition of enabling future = extensions it has always wisely chosen in the short term to limit = itself to immediate needs only while ensuring that future expansion is = possible.

Hence the test for the = redirect draft's success should be only how well it addresses the = immediate needs of redirect resources and not how well it addresses the = shifting needs of various future proposals.

The current functionality of = the redirect resource is very simple, specify a resource that, by = default, will return a 302 (found) response to a specified target = resource.

There does not appear to be = any compelling reason why the creation of a redirect resource should = require anything beyond a single header on the creation request to = specify the URI of the target resource. The use of a body to create a = redirect resource is clearly unnecessary. This is not to say that it = may not prove to be necessary in the future. However WebDAV, in = particular, has set a precedent for how to deal with this sort of = situation that I believe would well serve the redirect spec.

In the COPY/MOVE methods we = use a single destination header, rather than a body, to specify where = the results of the method are to appear. One can imagine a number of = reasons why one would want to have a more powerful way to specify the = destination of the method. For example, one might want to specify = multiple destination URIs in order to use a single round trip to cause = multiple COPY/MOVE's. HTTP's header format is not well suited for this = sort of extension and WebDAV's definition of the destination header = wisely does not allow for it. Rather WebDAV specifies that a body MAY = be included in a COPY/MOVE method but is to be ignored if not = understood. This provide for a very powerful extension mechanism. For = example, imagine one wanted to issue the COPY/MOVE to multiple = destinations but one wasn't sure if the source supported this feature. = Rather than wasting a round trip finding out if the source supports the = feature one could put a single destination in the destination header = and then use the body to specify the rest of the destinations. If the = resource supports the extension then all destinations will be = COPY/MOVE'd to. If the resource doesn't support the extension then at = least one copy will be issued and the client will realize that the rest = didn't occur (because the resource ignored the body) through the 207 = response. If, on the other hand, one only wanted the COPY/MOVE to = proceed if the resource understood the multiple destination extension = then the COPY/MOVE could be issued without a destination header, just = with a body. Resources that didn't support the extension would fail the = request due to the absence of the destination header thus ensuring that = only resources that understood the extension will actually execute the = method.

One could rightfully argue = that this is an unnecessary complication. Why not start with a body = that allows extension in the first place? The counter argument is that = one should always start with as minimal functionality as possibly and = only expand, grudgingly, as required. A header is much easier to = process than a body and so clearly is the simplest mechanism = available.

This line of reasoning is = especially compelling in the context of redirect resources. Given the = obvious utility of redirect resources to all HTTP systems, not just = WebDAV, it is incumbent upon the redirect spec to cleave as closely as = possible to the base HTTP system and require as few extensions from it = as possible.

Therefore I believe that the = current proposal, which requires the introduction of a full XML = processing system just to handle a simple redirect resource is = unsupportable. As such I move that whatever design is chosen for = creating a redirect resource it MUST NOT include the use of a request = body.

------_=_NextPart_001_01BF7463.9E50F6D6-- From w3c-dist-auth-request@w3.org Fri Feb 11 02:49:25 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01923 for ; Fri, 11 Feb 2000 02:49:24 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id CAA22773; Fri, 11 Feb 2000 02:44:54 -0500 (EST) Resent-Date: Fri, 11 Feb 2000 02:44:54 -0500 (EST) Resent-Message-Id: <200002110744.CAA22773@www19.w3.org> Message-ID: <7DE119D3D0E15543874F7561EECBDBED0261A162@BEG.platinum.corp.microsoft.com> From: Yaron Goland To: "'w3c-dist-auth@w3.org'" Date: Thu, 10 Feb 2000 23:44:34 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF7463.C219018A" Subject: Yaron.Redirect.NoWebDAV#2 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4067 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF7463.C219018A Content-Type: text/plain; charset="iso-8859-1" The second related design issue facing the group is what method to use in creating a redirect resource. It is a peculiarity of the human mind that it constantly strives for unification. The manifestation of this odd habit in the world of protocols is the constant desire to use only one method for everything. In this case, the MKRESOURCE method. I believe that the introduction of this method is directly contrary to the interests of the majority of the WebDAV community. The basis for this assertion is that the MKRESOURCE method, by its very design, forces an unnecessary unification of functionality that inhibits the ability to extend functionality on an ad-hoc basis. One of the great powers of HTTP is that its modular design allowed for wide spread experimentation with new methods, headers, etc. on existing platforms without having to change the code of the underlying server. This is why we see such widespread support for mechanisms such as ISAPI/NSAPI/Module extensions that allow new methods to be added to existing servers. The MKRESOURCE method is completely contrary to this trend. In fact, it hinders experiment. The MKRESOURCE method hinders experiment because a user of a server who wishes to add support for the creation of a new resource type can't simply throw in another Apache module and allow it to provide the code for the new resource type. They have to find the code used for MKRESOURCE and change it to support the new resource type. This means that whomever owns the code for that module has complete control over what new types of resources can be added to the server. This seems an unnecessary restriction. As such I move that whatever method name is chosen for creating a redirect resource it MUST be unique to the creation of redirect resources. ------_=_NextPart_001_01BF7463.C219018A Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Yaron.Redirect.NoWebDAV#2

The second related design = issue facing the group is what method to use in creating a redirect = resource. It is a peculiarity of the human mind that it constantly = strives for unification. The manifestation of this odd habit in the = world of protocols is the constant desire to use only one method for = everything. In this case, the MKRESOURCE method. I believe that the = introduction of this method is directly contrary to the interests of = the majority of the WebDAV community. The basis for this assertion is = that the MKRESOURCE method, by its very design, forces an unnecessary = unification of functionality that inhibits the ability to extend = functionality on an ad-hoc basis. One of the great powers of HTTP is = that its modular design allowed for wide spread experimentation with = new methods, headers, etc. on existing platforms without having to = change the code of the underlying server. This is why we see such = widespread support for mechanisms such as ISAPI/NSAPI/Module extensions = that allow new methods to be added to existing servers.

The MKRESOURCE method is = completely contrary to this trend. In fact, it hinders = experiment.
The MKRESOURCE method = hinders experiment because a user of a server who wishes to add support = for the creation of a new resource type can't simply throw in another = Apache module and allow it to provide the code for the new resource = type. They have to find the code used for MKRESOURCE and change it to = support the new resource type. This means that whomever owns the code = for that module has complete control over what new types of resources = can be added to the server. This seems an unnecessary = restriction.

As such I move that whatever = method name is chosen for creating a redirect resource it MUST be = unique to the creation of redirect resources.

------_=_NextPart_001_01BF7463.C219018A-- From w3c-dist-auth-request@w3.org Fri Feb 11 02:50:34 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01940 for ; Fri, 11 Feb 2000 02:50:34 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id CAA22863; Fri, 11 Feb 2000 02:46:16 -0500 (EST) Resent-Date: Fri, 11 Feb 2000 02:46:16 -0500 (EST) Resent-Message-Id: <200002110746.CAA22863@www19.w3.org> Message-ID: <7DE119D3D0E15543874F7561EECBDBED0261A163@BEG.platinum.corp.microsoft.com> From: Yaron Goland To: "'w3c-dist-auth@w3.org'" Date: Thu, 10 Feb 2000 23:45:53 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF7463.F24B2AE0" Subject: Yaron.Redirect.NoWebDAV#3 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4068 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF7463.F24B2AE0 Content-Type: text/plain; charset="iso-8859-1" The third related design issue facing the group is how to retrieve the target of a redirect resource. The current proposal specifies the use of WebDAV property. As argued in Yaron.Redirect.NoWebDAV#1 this is an unnecessary complication. It is much simpler to allow people to issue a method, such as HEAD, to the resource and allow the resource to respond to that method with a 302. This provides a fully efficient but very simple mechanism for discovering a redirect resource's target. Alternatively, one could issue the method used to create the redirect resource in the first place without a target header and allow the redirect resource to respond with its target resource's URI. There are any number of mechanisms available and none require the use and complexity of a WebDAV property. Therefore I move that there MUST NOT be a requirement in the redirect draft for the support of a WebDAV property in order to discover the target location. It is possible, of course, to argue that one should have a WebDAV property to discover the target resource, even if it is not mandatory. The utility of such a property includes the ability to use PROPFIND to collect various bits of data about a resource in a single request as well as the ability to search on the data. However, under closer scrutiny, neither of these arguments holds up. The use of pipelining means that one can use several separate status request messages to a resource without incurring any latency costs. Furthermore, while there is relatively little benefit to overloading properties, there is a very definite cost. As discussed in the WebDAV book of why and for reasoning that is essentially identical to that given in Yaron.Redirect.NoWebDAV#2, the requirement to provide resource state information through properties presents a clear threat to the extensibility of the WebDAV protocol suite. It centralizes control over new functionality into a single point and so inhibits the ability to experiment and extend HTTP resources. The search confusion has been around for a while, which is surprising given that even the DASL group has long disowned the issue. The essence of the problem is the mistaken belief the DASL is only able to query WebDAV properties. In fact, DASL is able to query any value associated with a resource that has a unique name, i.e. a URI name. There is no requirement that this value be settable or retrievable through the WebDAV property mechanism. Therefore I move that the bind spec MUST NOT specify much less require the use of WebDAV properties for any purpose related to the creation/state query/maintenance of redirect resources. ------_=_NextPart_001_01BF7463.F24B2AE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Yaron.Redirect.NoWebDAV#3

The third related design = issue facing the group is how to retrieve the target of a redirect = resource. The current proposal specifies the use of WebDAV property. As = argued in Yaron.Redirect.NoWebDAV#1 this is an unnecessary = complication. It is much simpler to allow people to issue a method, = such as HEAD, to the resource and allow the resource to respond to that = method with a 302. This provides a fully efficient but very simple = mechanism for discovering a redirect resource's target. Alternatively, = one could issue the method used to create the redirect resource in the = first place without a target header and allow the redirect resource to = respond with its target resource's URI. There are any number of = mechanisms available and none require the use and complexity of a = WebDAV property. Therefore I move that there MUST NOT be a requirement = in the redirect draft for the support of a WebDAV property in order to = discover the target location.

It is possible, of course, = to argue that one should have a WebDAV property to discover the target = resource, even if it is not mandatory. The utility of such a property = includes the ability to use PROPFIND to collect various bits of data = about a resource in a single request as well as the ability to search = on the data. However, under closer scrutiny, neither of these arguments = holds up.

The use of pipelining means = that one can use several separate status request messages to a resource = without incurring any latency costs. Furthermore, while there is = relatively little benefit to overloading properties, there is a very = definite cost. As discussed in the WebDAV book of why and for reasoning = that is essentially identical to that given in = Yaron.Redirect.NoWebDAV#2, the requirement to provide resource state = information through properties presents a clear threat to the = extensibility of the WebDAV protocol suite. It centralizes control over = new functionality into a single point and so inhibits the ability to = experiment and extend HTTP resources.

The search confusion has = been around for a while, which is surprising given that even the DASL = group has long disowned the issue. The essence of the problem is the = mistaken belief the DASL is only able to query WebDAV properties. In = fact, DASL is able to query any value associated with a resource that = has a unique name, i.e. a URI name. There is no requirement that this = value be settable or retrievable through the WebDAV property = mechanism.

Therefore I move that the = bind spec MUST NOT specify much less require the use of WebDAV = properties for any purpose related to the creation/state = query/maintenance of redirect resources.

------_=_NextPart_001_01BF7463.F24B2AE0-- From w3c-dist-auth-request@w3.org Fri Feb 11 02:51:14 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01952 for ; Fri, 11 Feb 2000 02:51:13 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id CAA22935; Fri, 11 Feb 2000 02:46:58 -0500 (EST) Resent-Date: Fri, 11 Feb 2000 02:46:58 -0500 (EST) Resent-Message-Id: <200002110746.CAA22935@www19.w3.org> Message-ID: <7DE119D3D0E15543874F7561EECBDBED0261A164@BEG.platinum.corp.microsoft.com> From: Yaron Goland To: "'w3c-dist-auth@w3.org'" Date: Thu, 10 Feb 2000 23:46:30 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF7464.09CF3C92" Subject: Yaron.Redirect.Sec4LastPar Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4069 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF7464.09CF3C92 Content-Type: text/plain; charset="iso-8859-1" The last paragraph of section 4 currently reads: Since a redirect reference resource is a resource, it can have its own properties and body, and methods can be applied to the reference resource as well as to its target resource. The Apply-To-Redirect-Ref request header (defined in Section 11.2 below) is provided so that referencing-aware clients can control whether an operation is applied to the redirect reference resource or to its target resource. The Apply- To-Redirect-Ref header can be used with most requests to redirect reference resources. This header is particularly useful with PROPFIND, to retrieve the reference resource's own properties. Given the numerous changes I request in my comments the previous description is no longer accurate. I also felt that it didn't provide a sufficiently broad overview of the total functionality provided by redirect resources. Below I provide several paragraphs that I suggest replace the previous one: Redirect resources are resources and thus have their own state. However the default response of a redirect resource to all methods is a 302 (Found). A mechanism is needed that instructs the redirect resource to handle a method directly rather than blindly responding to it with a 302 (Found). The Apply-To-Redirect-Ref request header (defined in Section 11.2 below) provides such a mechanism. For example, if a user issues a PUT request without the Apply-To-Redirect-Ref request header then the redirect resource will respond with a 302 (Found). However, if the redirect resource supports PUT and if the requestor is properly authorized then a PUT issued to a redirect resource with a Apply-To-Redirect-Ref header will result in the body of the PUT request being stored for future response to a GET request, assuming the GET has a Apply-To-Redirect-Ref header. Please note that it is perfectly legal for the response to a request to a redirect reference resource with the Apply-To-Redirect-Ref header to result in a 302 (Found). In this case the 302 (Found) will not be a blind response but rather will be the correct result of the method. Also note that such a response would not include a redirect-ref header. ------_=_NextPart_001_01BF7464.09CF3C92 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Yaron.Redirect.Sec4LastPar

The last paragraph of = section 4 currently reads:

Since a redirect reference = resource is a resource, it can have its own
properties and body, and = methods can be applied to the reference
resource as well as to its = target resource.  The Apply-To-Redirect-Ref
request header (defined in = Section 11.2 below) is provided so that
referencing-aware clients = can control whether an operation is applied to
the redirect reference = resource or to its target resource.  The Apply-
To-Redirect-Ref header can = be used with most requests to redirect
reference resources.  = This header is particularly useful with PROPFIND,
to retrieve the reference = resource's own properties.

Given the numerous changes I = request in my comments the previous description is no longer accurate. = I also felt that it didn't provide a sufficiently broad overview of the = total functionality provided by redirect resources. Below I provide = several paragraphs that I suggest replace the previous one:

Redirect resources are = resources and thus have their own state. However the default response = of a redirect resource to all methods is a 302 (Found). A mechanism is = needed that instructs the redirect resource to handle a method directly = rather than blindly responding to it with a 302 (Found). The = Apply-To-Redirect-Ref request header (defined in Section 11.2 below) = provides such a mechanism.

For example, if a user = issues a PUT request without the Apply-To-Redirect-Ref request header = then the redirect resource will respond with a 302 (Found). However, if = the redirect resource supports PUT and if the requestor is properly = authorized then a PUT issued to a redirect resource with a = Apply-To-Redirect-Ref header will result in the body of the PUT request = being stored for future response to a GET request, assuming the GET has = a Apply-To-Redirect-Ref header.

Please note that it is = perfectly legal for the response to a request to a redirect reference = resource with the Apply-To-Redirect-Ref header to result in a 302 = (Found). In this case the 302 (Found) will not be a blind response but = rather will be the correct result of the method. Also note that such a = response would not include a redirect-ref header.

------_=_NextPart_001_01BF7464.09CF3C92-- From w3c-dist-auth-request@w3.org Fri Feb 11 02:51:46 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01963 for ; Fri, 11 Feb 2000 02:51:46 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id CAA23003; Fri, 11 Feb 2000 02:47:30 -0500 (EST) Resent-Date: Fri, 11 Feb 2000 02:47:30 -0500 (EST) Resent-Message-Id: <200002110747.CAA23003@www19.w3.org> Message-ID: <7DE119D3D0E15543874F7561EECBDBED0261A165@BEG.platinum.corp.microsoft.com> From: Yaron Goland To: "'w3c-dist-auth@w3.org'" Date: Thu, 10 Feb 2000 23:47:07 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF7464.1E834818" Subject: Yaron.Redirect.S5P2S23 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4070 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF7464.1E834818 Content-Type: text/plain; charset="iso-8859-1" The last two sentences of the last paragraph of section 5 reads: It creates a new binding between the new redirect reference resource and the last path segment of the Request-URI. The new binding is added to its parent collection, identified by the Request-URI minus its trailing slash (if present) and final segment. As discussed in Yaron.Redirect.NoWebDAV#1, we should make it possible to implement redirect resources and understand the redirect resource draft without having to resort to any draft but RFC 2616. The use above of the term binding requires a familiarity not only with RFC 2616, but RFC 2518 as well as the bind draft. Since the language given above just repeats the standard behavior for any new resource created inside of a WebDAV compliant namespace and as it is likely to confuse a reader only familiar with RFC 2616, I move that this paragraph be stricken from the spec. ------_=_NextPart_001_01BF7464.1E834818 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Yaron.Redirect.S5P2S23

The last two sentences of = the last paragraph of section 5 reads:

It creates a new binding = between the new redirect reference resource and
the last path segment of = the Request-URI.  The new binding is added to
its parent collection, = identified by the Request-URI minus its trailing
slash (if present) and = final segment.

As discussed in = Yaron.Redirect.NoWebDAV#1, we should make it possible to implement = redirect resources and understand the redirect resource draft without = having to resort to any draft but RFC 2616. The use above of the term = binding requires a familiarity not only with RFC 2616, but RFC 2518 as = well as the bind draft. Since the language given above just repeats the = standard behavior for any new resource created inside of a WebDAV = compliant namespace and as it is likely to confuse a reader only = familiar with RFC 2616, I move that this paragraph be stricken from the = spec.

------_=_NextPart_001_01BF7464.1E834818-- From w3c-dist-auth-request@w3.org Fri Feb 11 02:52:32 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01975 for ; Fri, 11 Feb 2000 02:52:32 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id CAA23042; Fri, 11 Feb 2000 02:48:05 -0500 (EST) Resent-Date: Fri, 11 Feb 2000 02:48:05 -0500 (EST) Resent-Message-Id: <200002110748.CAA23042@www19.w3.org> Message-ID: <7DE119D3D0E15543874F7561EECBDBED0261A166@BEG.platinum.corp.microsoft.com> From: Yaron Goland To: "'w3c-dist-auth@w3.org'" Date: Thu, 10 Feb 2000 23:47:41 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF7464.33623DF2" Subject: Yaron.Redirect.Errors Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4071 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF7464.33623DF2 Content-Type: text/plain; charset="iso-8859-1" Given the proposal in Yaron.Redirect.NoWebDAV#1 to remove the body of the method used to create redirect resources I move that the 207 error response in section 5.1 be removed. As there does not appear to be any compelling reason to bar the use of redirect resources outside of WebDAV I move that the language for describing the 409 response in section 5.1 be changed from: 409 (Conflict): A resource cannot be created at the Request-URI because the parent collection for the resource does not exist, or because there is already a resource at that request-URL. to 409 (Conflict): A resource cannot be created at the Request-URI because there is already a resource at that request-URL. Note that the original language for 409 did not prevent the usage of redirect resources in non-WebDAV namespaces but it could lead the reader to believe that such a restriction existed. ------_=_NextPart_001_01BF7464.33623DF2 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Yaron.Redirect.Errors

Given the proposal in = Yaron.Redirect.NoWebDAV#1 to remove the body of the method used to = create redirect resources I move that the 207 error response in section = 5.1 be removed.

As there does not appear to = be any compelling reason to bar the use of redirect resources outside = of WebDAV I move that the language for describing the 409 response in = section 5.1 be changed from:

409 (Conflict): A resource = cannot be created at the Request-URI because
the parent collection for = the resource does not exist, or because there
is already a resource at = that request-URL.

to

409 (Conflict): A resource = cannot be created at the Request-URI because there
is already a resource at = that request-URL.

Note that the original = language for 409 did not prevent the usage of redirect resources in = non-WebDAV namespaces but it could lead the reader to believe that such = a restriction existed.

------_=_NextPart_001_01BF7464.33623DF2-- From w3c-dist-auth-request@w3.org Fri Feb 11 02:52:59 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01986 for ; Fri, 11 Feb 2000 02:52:59 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id CAA23085; Fri, 11 Feb 2000 02:48:38 -0500 (EST) Resent-Date: Fri, 11 Feb 2000 02:48:38 -0500 (EST) Resent-Message-Id: <200002110748.CAA23085@www19.w3.org> Message-ID: <7DE119D3D0E15543874F7561EECBDBED0261A167@BEG.platinum.corp.microsoft.com> From: Yaron Goland To: "'w3c-dist-auth@w3.org'" Date: Thu, 10 Feb 2000 23:48:13 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF7464.45417E98" Subject: Yaron.Redirect.S6 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4072 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF7464.45417E98 Content-Type: text/plain; charset="iso-8859-1" I found section 6 to be extremely verbose, which given my record on the matter is saying something. As such I move that the entire section be replaced with the following two paragraphs: A redirect resource, upon receiving a request without an Apply-To-Redirect-Ref header, MUST respond with a 302 (Found) response. The 302 (Found) response MUST include a location header identifying the target and a Redirect-Ref header. If a redirect resource receives a request with an Apply-To-Redirect-Ref header then the redirect reference resource MUST apply the method to itself rather than blindly returning a 302 (Found) response. ------_=_NextPart_001_01BF7464.45417E98 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Yaron.Redirect.S6

I found section 6 to be = extremely verbose, which given my record on the matter is saying = something. As such I move that the entire section be replaced with the = following two paragraphs:

A redirect resource, upon = receiving a request without an Apply-To-Redirect-Ref header, MUST = respond with a 302 (Found) response. The 302 (Found) response MUST = include a location header identifying the target and a Redirect-Ref = header.

If a redirect resource = receives a request with an Apply-To-Redirect-Ref header then the = redirect reference resource MUST apply the method to itself rather than = blindly returning a 302 (Found) response.

------_=_NextPart_001_01BF7464.45417E98-- From w3c-dist-auth-request@w3.org Fri Feb 11 02:53:51 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01999 for ; Fri, 11 Feb 2000 02:53:51 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id CAA23209; Fri, 11 Feb 2000 02:49:26 -0500 (EST) Resent-Date: Fri, 11 Feb 2000 02:49:26 -0500 (EST) Resent-Message-Id: <200002110749.CAA23209@www19.w3.org> Message-ID: <7DE119D3D0E15543874F7561EECBDBED0261A168@BEG.platinum.corp.microsoft.com> From: Yaron Goland To: "'w3c-dist-auth@w3.org'" Date: Thu, 10 Feb 2000 23:49:01 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF7464.6326BB1C" Subject: Yaron.Redirect.PUT Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4073 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF7464.6326BB1C Content-Type: text/plain; charset="iso-8859-1" The last sentence of the last paragraph of section 6.2 reads: "The result in this case is that the reference resource is replaced by a non-reference resource having the content submitted with the request." If a Apply-To-Redirect-Ref PUT results in the reference resource being replaced then the reference spec will have robbed its users of any mechanism to specify the response to a Apply-To-Redirect-Ref GET. I can't find any reason for requiring this behavior given that a Apply-To-Redirect-Ref DELETE followed by a PUT can achieve the same result and still leave users the ability to specify the results of a Apply-To-Redirect-Ref GET. As such I move that this sentence be deleted. BTW, the reason I suggest deleting the sentence rather than replacing it with language specifying what happens when a PUT is applied is that there is no requirement that a PUT set the GET result. For example, the user may do a PUT with text/html and the server may choose to return it as text/plain. So it is very difficult to precisely specify what the result of a PUT is. What it is not, however, is a way to delete a resource. Otherwise it would make a mockery of unique resource IDs. Imagine I create a document and want to track it. What the document is created it is issued a resource ID that I record. That way, even if the document is moved, I can find it through its resource ID. If PUT worked as specified above then every time someone PUT to the resource the old resource would be deleted and a new one would be created with a new resource ID, so much for being able to track the document. As such it is clear that a PUT should not cause an implied DELETE. ------_=_NextPart_001_01BF7464.6326BB1C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Yaron.Redirect.PUT

The last sentence of the = last paragraph of section 6.2 reads: "The result in this case is = that the reference resource is replaced by a non-reference resource = having the content submitted with the request."

If a Apply-To-Redirect-Ref = PUT results in the reference resource being replaced then the reference = spec will have robbed its users of any mechanism to specify the = response to a Apply-To-Redirect-Ref GET. I can't find any reason for = requiring this behavior given that a Apply-To-Redirect-Ref DELETE = followed by a PUT can achieve the same result and still leave users the = ability to specify the results of a Apply-To-Redirect-Ref GET. As such = I move that this sentence be deleted.

BTW, the reason I suggest = deleting the sentence rather than replacing it with language specifying = what happens when a PUT is applied is that there is no requirement that = a PUT set the GET result. For example, the user may do a PUT with = text/html and the server may choose to return it as text/plain. So it = is very difficult to precisely specify what the result of a PUT is. = What it is not, however, is a way to delete a resource. Otherwise it = would make a mockery of unique resource IDs. Imagine I create a = document and want to track it. What the document is created it is = issued a resource ID that I record. That way, even if the document is = moved, I can find it through its resource ID. If PUT worked as = specified above then every time someone PUT to the resource the old = resource would be deleted and a new one would be created with a new = resource ID, so much for being able to track the document. As such it = is clear that a PUT should not cause an implied DELETE.

------_=_NextPart_001_01BF7464.6326BB1C-- From w3c-dist-auth-request@w3.org Fri Feb 11 02:54:25 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02011 for ; Fri, 11 Feb 2000 02:54:24 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id CAA23254; Fri, 11 Feb 2000 02:50:06 -0500 (EST) Resent-Date: Fri, 11 Feb 2000 02:50:06 -0500 (EST) Resent-Message-Id: <200002110750.CAA23254@www19.w3.org> Message-ID: <7DE119D3D0E15543874F7561EECBDBED0261A169@BEG.platinum.corp.microsoft.com> From: Yaron Goland To: "'w3c-dist-auth@w3.org'" Date: Thu, 10 Feb 2000 23:49:44 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF7464.7AED8EA6" Subject: Yaron.Redirect.BlindRedirect Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4074 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF7464.7AED8EA6 Content-Type: text/plain; charset="iso-8859-1" The second sentence of the last paragraph of section 6.3 reads: "The Redirect-Ref header informs a reference-aware client that this is not an ordinary HTTP 1.1 redirect, but is a redirect reference resource. " If the purpose of the Redirect-Ref header was solely to inform the client that they were dealing with a redirect resource then the header would be returned on all responses from a redirect resource, even those with a Apply-To-Redirect-Ref header. However the purpose of the Redirect-Ref header is to let redirect aware clients determine that they are dealing with a blindly generated 302. As such I move that the sentence be changed to state: "The Redirect-Ref header informs a redirect aware client that they have received a blind 302 response from a redirect resource." Similarly the main paragraph of section 11.1 currently reads: "The Redirect-Ref header is used in all 302 responses from redirect resources. Its presence informs reference-aware clients that the response is not a plain HTTP/1.1 redirect, but is a response from a redirect reference resource." I move that it be re-written to read: "The Redirect-Ref header is used to mark blind 302 responses from redirect resources." ------_=_NextPart_001_01BF7464.7AED8EA6 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Yaron.Redirect.BlindRedirect

The second sentence of the = last paragraph of section 6.3 reads: "The Redirect-Ref header = informs a reference-aware client that this is not an ordinary HTTP 1.1 = redirect, but is a redirect reference resource. "

If the purpose of the = Redirect-Ref header was solely to inform the client that they were = dealing with a redirect resource then the header would be returned on = all responses from a redirect resource, even those with a = Apply-To-Redirect-Ref header.

However the purpose of the = Redirect-Ref header is to let redirect aware clients determine that = they are dealing with a blindly generated 302. As such I move that the = sentence be changed to state: "The Redirect-Ref header informs a = redirect aware client that they have received a blind 302 response from = a redirect resource."

Similarly the main paragraph = of section 11.1 currently reads: "The Redirect-Ref header is used = in all 302 responses from redirect resources. Its presence informs = reference-aware clients that the response is not a plain HTTP/1.1 = redirect, but is a response from a redirect reference = resource."

I move that it be re-written = to read: "The Redirect-Ref header is used to mark blind 302 = responses from redirect resources."

------_=_NextPart_001_01BF7464.7AED8EA6-- From w3c-dist-auth-request@w3.org Fri Feb 11 02:55:09 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02028 for ; Fri, 11 Feb 2000 02:55:08 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id CAA23326; Fri, 11 Feb 2000 02:50:47 -0500 (EST) Resent-Date: Fri, 11 Feb 2000 02:50:47 -0500 (EST) Resent-Message-Id: <200002110750.CAA23326@www19.w3.org> Message-ID: <7DE119D3D0E15543874F7561EECBDBED0261A16A@BEG.platinum.corp.microsoft.com> From: Yaron Goland To: "'w3c-dist-auth@w3.org'" Date: Thu, 10 Feb 2000 23:50:21 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF7464.92C77500" Subject: Yaron.Redirect.S7P1 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4075 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF7464.92C77500 Content-Type: text/plain; charset="iso-8859-1" The first sentence of the first paragraph of section 7 reads: "A URI of a redirect reference resource can be an internal member URI of a collection just as the URI of a non-reference resource can. " Given the previous comments it would seem that this sentence needs to be rewritten to specify that all the resources involved must be WebDAV compliant. It is not enough that the parent of a redirect resource is a WebDAV compliant collection. The redirect resource itself needs to be WebDAV compliant. However, specifying all this would only reproduce the namespace requirements stated in RFC 2518, requirements that apply to all WebDAV compliant resources regardless of their type. Hence a reasonable reader is likely to draw the conclusion, based on this sentence, that RFC 2518 is wrong and that there do potentially exist WebDAV compliant resources that are the children of WebDAV compliant collections that may not be internal members of that collection. After all, were this not so, it would not be necessary to explicitly state that redirect resources can be the child of a WebDAV collection. As this sentence seems to clarify something that does not require clarifying and as it does it in a manner likely to produce confusion. I move that it be deleted. The last sentence of the first paragraph of section 7 reads: " The methods that can accept a Depth header are PROPFIND, COPY, MOVE, DELETE, and LOCK." As a general rule of thumb it is a bad idea to give lists in standards for features that can and will change. A reader seeing this sentence would come to the conclusion that the Depth header can only be used with the listed methods. This is, of course, false. The Depth header may be used with any number of methods that have yet to be defined. While I suppose we could qualify this sentence to say that this is the list of methods that use Depth known at the time the standard was written I can find no utility for such a statement. As such I propose that this sentence be removed from the spec. ------_=_NextPart_001_01BF7464.92C77500 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Yaron.Redirect.S7P1

The first sentence of the = first paragraph of section 7 reads: "A URI of a redirect reference = resource can be an internal member URI of a collection just as the URI = of a non-reference resource can. "

Given the previous comments = it would seem that this sentence needs to be rewritten to specify that = all the resources involved must be WebDAV compliant. It is not enough = that the parent of a redirect resource is a WebDAV compliant = collection. The redirect resource itself needs to be WebDAV = compliant.

However, specifying all this = would only reproduce the namespace requirements stated in RFC 2518, = requirements that apply to all WebDAV compliant resources regardless of = their type. Hence a reasonable reader is likely to draw the conclusion, = based on this sentence, that RFC 2518 is wrong and that there do = potentially exist WebDAV compliant resources that are the children of = WebDAV compliant collections that may not be internal members of that = collection. After all, were this not so, it would not be necessary to = explicitly state that redirect resources can be the child of a WebDAV = collection.

As this sentence seems to = clarify something that does not require clarifying and as it does it in = a manner likely to produce confusion. I move that it be = deleted.

The last sentence of the = first paragraph of section 7 reads: " The methods that can accept = a Depth header are PROPFIND, COPY, MOVE, DELETE, and = LOCK."

As a general rule of thumb = it is a bad idea to give lists in standards for features that can and = will change. A reader seeing this sentence would come to the conclusion = that the Depth header can only be used with the listed methods. This = is, of course, false. The Depth header may be used with any number of = methods that have yet to be defined. While I suppose we could qualify = this sentence to say that this is the list of methods that use Depth = known at the time the standard was written I can find no utility for = such a statement. As such I propose that this sentence be removed from = the spec.

------_=_NextPart_001_01BF7464.92C77500-- From w3c-dist-auth-request@w3.org Fri Feb 11 02:56:16 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02058 for ; Fri, 11 Feb 2000 02:56:16 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id CAA23453; Fri, 11 Feb 2000 02:51:52 -0500 (EST) Resent-Date: Fri, 11 Feb 2000 02:51:52 -0500 (EST) Resent-Message-Id: <200002110751.CAA23453@www19.w3.org> Message-ID: <7DE119D3D0E15543874F7561EECBDBED0261A16B@BEG.platinum.corp.microsoft.com> From: Yaron Goland To: "'w3c-dist-auth@w3.org'" Date: Thu, 10 Feb 2000 23:51:26 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF7464.B99B20AA" Subject: Yaron.Redirect.NoPropsIn207 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4076 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF7464.B99B20AA Content-Type: text/plain; charset="iso-8859-1" The third sentence of the third paragraph of section 7 currently reads: "Since a Location header and Redirect-Ref header cannot be returned for each redirect reference encountered, the same information is provided using properties in the response elements for those resources." As discussed in Yaron.Redirect.NoWebDAV#3 we should not be using WebDAV properties in the redirect draft. Therefore I move that this sentence be changed to read: "Following the conventions of the 207 (Multi-Status) format the equivalent of the redirect-ref and location header are included inside the response body." The fourth sentence of the third paragraph of section 7 currently reads: "The DAV:location pseudo-property and the DAV:resourcetype property MUST be included with the 302 status code." First, the use of a pseudo-property violates the integrity of the prop XML element of a multi-status response. One can today write a general tool that can process any multi-status response and draw property information from it. Such a tool need not even understand the particular context in which the multi-status was generated. The use of a "pseudo-property" violates this integrity be listing a value in a prop element, thereby stating it is a property, when it is in fact not. Second, it is almost always a bad idea to imply information rather than stating it. By requiring that the resourcetype property be included you are expecting that the client will understand that because the response is a 302 and because a Apply-To-Redirect-Ref header was not included and because the resource type is redirect resource therefore this is a blind 302 response. This is a lot of inferring to do. In addition the resourcetype of a resource could potentially be quite large. As such it is generally better to create a dedicated piece of information which states, exclusively and uniquely that the 302 is a blind 302 and leave it at that. As such I move that both the DAV:location "pseudo-property" and the resourcetype property be banned for the uses stated in the above mentioned sentence. I move that location information be returned in a location XML element included in the response XML element. I move that the Redirect-Ref header information be included in a refresource XML element also included in the response XML element. Based on the previous proposals I also move that the previously quoted sentence be changed to read: "The location and refresource XML elements MUST be included with the 302 status code returned in a response XML element in a 207 (Multi-Status) response." The fifth sentence of the third paragraph of section 7 currently reads: "This necessitates an extension to the syntax of the DAV:response element that was defined in [WebDAV]. The extension is defined in Section 14 below." This sentence either states something obvious or unnecessary, I can't figure out which. Regardless, it isn't needed. As such I move that it be deleted. The third paragraph of section 7 is not necessary if my previous proposals in this point are adopted therefore I move that it be deleted. The fourth paragraph of section 7 provides suggestions for future changes to the WebDAV standard. I really dislike language like this as it has no place in a standard. If changes are needed to the base WebDAV specification then put out a posting to the mailing list so they can be added to the issue list for consideration when WebDAV goes to Draft. But please leave them out of the standard. Standards are really not the proper forum for editorializing. As such I move that this paragraph be deleted. Section 7.1 of the specification basically just restates RFC 2518. Rather than clarifying the issue it just confuses the reader by forcing them to ask themselves what was so subtle in understanding the WebDAV spec that this paragraph was necessary. BTW, one should contrast section 7.1 with section 7.2. 7.2 points out a real subtly in the design of WebDAV and redirect resources that needs to be called out to implementers. I do not believe that 7.1 meets the quality bar set by 7.2. Therefore I move that section 7.1 be deleted from the specification. ------_=_NextPart_001_01BF7464.B99B20AA Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Yaron.Redirect.NoPropsIn207

The third sentence of the = third paragraph of section 7 currently reads: "Since a Location = header and Redirect-Ref header cannot be returned for each redirect = reference encountered, the same information is provided using = properties in the response elements for those = resources."

As discussed in = Yaron.Redirect.NoWebDAV#3 we should not be using WebDAV properties in = the redirect draft. Therefore I move that this sentence be changed to = read: "Following the conventions of the 207 (Multi-Status) format = the equivalent of the redirect-ref and location header are included = inside the response body."

The fourth sentence of the = third paragraph of section 7 currently reads: "The DAV:location = pseudo-property and the DAV:resourcetype property MUST be included with = the 302 status code."

First, the use of a = pseudo-property violates the integrity of the prop XML element of a = multi-status response. One can today write a general tool that can = process any multi-status response and draw property information from = it. Such a tool need not even understand the particular context in = which the multi-status was generated. The use of a = "pseudo-property" violates this integrity be listing a value = in a prop element, thereby stating it is a property, when it is in fact = not.

Second, it is almost always = a bad idea to imply information rather than stating it. By requiring = that the resourcetype property be included you are expecting that the = client will understand that because the response is a 302 and because a = Apply-To-Redirect-Ref header was not included and because the resource = type is redirect resource therefore this is a blind 302 response. This = is a lot of inferring to do. In addition the resourcetype of a resource = could potentially be quite large. As such it is generally better to = create a dedicated piece of information which states, exclusively and = uniquely that the 302 is a blind 302 and leave it at that.

As such I move that both the = DAV:location "pseudo-property" and the resourcetype property = be banned for the uses stated in the above mentioned = sentence.

I move that location = information be returned in a location XML element included in the = response XML element.
I move that the = Redirect-Ref header information be included in a refresource XML = element also included in the response XML element.

Based on the previous = proposals I also move that the previously quoted sentence be changed to = read: "The location and refresource XML elements MUST be included = with the 302 status code returned in a response XML element in a 207 = (Multi-Status) response."

The fifth sentence of the = third paragraph of section 7 currently reads: "This necessitates = an extension to the syntax of the DAV:response element that was defined = in [WebDAV].  The extension is defined in Section 14 = below."

This sentence either states = something obvious or unnecessary, I can't figure out which. Regardless, = it isn't needed. As such I move that it be deleted.

The third paragraph of = section 7 is not necessary if my previous proposals in this point are = adopted therefore I move that it be deleted.

The fourth paragraph of = section 7 provides suggestions for future changes to the WebDAV = standard. I really dislike language like this as it has no place in a = standard. If changes are needed to the base WebDAV specification then = put out a posting to the mailing list so they can be added to the issue = list for consideration when WebDAV goes to Draft. But please leave them = out of the standard. Standards are really not the proper forum for = editorializing. As such I move that this paragraph be = deleted.

Section 7.1 of the = specification basically just restates RFC 2518. Rather than clarifying = the issue it just confuses the reader by forcing them to ask themselves = what was so subtle in understanding the WebDAV spec that this paragraph = was necessary. BTW, one should contrast section 7.1 with section 7.2. = 7.2 points out a real subtly in the design of WebDAV and redirect = resources that needs to be called out to implementers. I do not believe = that 7.1 meets the quality bar set by 7.2. Therefore I move that = section 7.1 be deleted from the specification.

------_=_NextPart_001_01BF7464.B99B20AA-- From w3c-dist-auth-request@w3.org Fri Feb 11 02:57:42 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02079 for ; Fri, 11 Feb 2000 02:57:42 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id CAA23561; Fri, 11 Feb 2000 02:52:56 -0500 (EST) Resent-Date: Fri, 11 Feb 2000 02:52:56 -0500 (EST) Resent-Message-Id: <200002110752.CAA23561@www19.w3.org> Message-ID: <7DE119D3D0E15543874F7561EECBDBED0261A16C@BEG.platinum.corp.microsoft.com> From: Yaron Goland To: "'w3c-dist-auth@w3.org'" Date: Thu, 10 Feb 2000 23:52:33 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF7464.E0B8B53A" Subject: Yaron.Redirect.NoRelative Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4077 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF7464.E0B8B53A Content-Type: text/plain; charset="iso-8859-1" Section 9 of the redirect spec allows for the use of relative URIs in the reftarget production. Relative URIs are an extremely dangerous feature that have caused havoc amongst system implementers. Even so, in many circumstances they offer such a high value that the problems they cause are worth dealing with. I do not believe that this is one of those circumstances. The primary (and in my opinion only) utility for relative URIs is to allow humans to type in relative URIs so that they can create links and documents without having to specify their final location. For example, a web site designer can use Notepad to type in the links for their web page using relative URLs. That way the web site designer can test out the site in their test location and not have to go through and change all the links when they move it to their final destination. This exact functionality could, of course, be implemented automatically. For example, Microsoft FrontPage is able to check Office and HTML documents and identify their links. If an Office or HTML document is moved then FrontPage will automatically check all the links, see if the move breaks any of them and if so it will automatically fix them. Hence the utility of relative URIs is mainly that it saves some humans in some cases some work. That is, it was easier to implement relative URIs then to enable all servers to read all file formats and be able to fix links. There is a second benefit to relative URIs that apply uniquely to protocols - they save bytes. If one is returning a large number of links that are all relative to some base one can save bytes by returning the URIs in a relative form. The downside to relative URIs is figuring out what the base is. HTTP provides at least two different mechanisms including the request-URI and the content-base header. Various data formats then provide their own solutions. Both HTML and XML have proposals/implementations for what the base should be. The rules for figuring out the base are complex and rarely implemented consistently. As the PM for WinInet dealing with the subtleties of relative URIs was one of the banes of my experience. What is especially bad is the conflict. If a request has a content-base header and a base specification in the HTML in the request which one is to be used? There are rules for figuring this out but they are rarely properly implemented. The end result of the confusion is that it is best to avoid relative URIs whenever possible. In the case of WebDAV the human benefits for the use of relative URIs are obviously irrelevant. Therefore the only argument for the use of relative URIs is that they save bytes. However given that we are using XML the bandwidth taken by the URIs is the absolutely least of our problems. As such when choosing between a simple, easy to process rule "the URI is always absolute" and a rule that introduces additional complexity for little benefit "the URI is relative", we should clearly come down on the side of simplicity. Therefore I move that relative URIs be removed from protocol elements in the redirect spec and that section 9 be deleted in its entirety. ------_=_NextPart_001_01BF7464.E0B8B53A Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Yaron.Redirect.NoRelative

Section 9 of the redirect = spec allows for the use of relative URIs in the reftarget production. = Relative URIs are an extremely dangerous feature that have caused havoc = amongst system implementers. Even so, in many circumstances they offer = such a high value that the problems they cause are worth dealing with. = I do not believe that this is one of those circumstances.

The primary (and in my = opinion only) utility for relative URIs is to allow humans to type in = relative URIs so that they can create links and documents without = having to specify their final location. For example, a web site = designer can use Notepad to type in the links for their web page using = relative URLs. That way the web site designer can test out the site in = their test location and not have to go through and change all the links = when they move it to their final destination.

This exact functionality = could, of course, be implemented automatically. For example, Microsoft = FrontPage is able to check Office and HTML documents and identify their = links. If an Office or HTML document is moved then FrontPage will = automatically check all the links, see if the move breaks any of them = and if so it will automatically fix them.

Hence the utility of = relative URIs is mainly that it saves some humans in some cases some = work. That is, it was easier to implement relative URIs then to enable = all servers to read all file formats and be able to fix = links.

There is a second benefit to = relative URIs that apply uniquely to protocols - they save bytes. If = one is returning a large number of links that are all relative to some = base one can save bytes by returning the URIs in a relative = form.

The downside to relative = URIs is figuring out what the base is. HTTP provides at least two = different mechanisms including the request-URI and the content-base = header. Various data formats then provide their own solutions. Both = HTML and XML have proposals/implementations for what the base should = be. The rules for figuring out the base are complex and rarely = implemented consistently. As the PM for WinInet dealing with the = subtleties of relative URIs was one of the banes of my = experience.

What is especially bad is = the conflict. If a request has a content-base header and a base = specification in the HTML in the request which one is to be used? There = are rules for figuring this out but they are rarely properly = implemented.

The end result of the = confusion is that it is best to avoid relative URIs whenever = possible.

In the case of WebDAV the = human benefits for the use of relative URIs are obviously irrelevant. = Therefore the only argument for the use of relative URIs is that they = save bytes. However given that we are using XML the bandwidth taken by = the URIs is the absolutely least of our problems. As such when choosing = between a simple, easy to process rule "the URI is always = absolute" and a rule that introduces additional complexity for = little benefit "the URI is relative", we should clearly come = down on the side of simplicity.

Therefore I move that = relative URIs be removed from protocol elements in the redirect spec = and that section 9 be deleted in its entirety.

------_=_NextPart_001_01BF7464.E0B8B53A-- From w3c-dist-auth-request@w3.org Fri Feb 11 02:58:31 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02091 for ; Fri, 11 Feb 2000 02:58:31 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id CAA23714; Fri, 11 Feb 2000 02:54:11 -0500 (EST) Resent-Date: Fri, 11 Feb 2000 02:54:11 -0500 (EST) Resent-Message-Id: <200002110754.CAA23714@www19.w3.org> Message-ID: <7DE119D3D0E15543874F7561EECBDBED0261A16D@BEG.platinum.corp.microsoft.com> From: Yaron Goland To: "'w3c-dist-auth@w3.org'" Date: Thu, 10 Feb 2000 23:53:46 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF7465.0D06479C" Subject: Yaron.Redirect.S10 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4078 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF7465.0D06479C Content-Type: text/plain; charset="iso-8859-1" Section 10 of the redirect spec requires that given a HTTP URL http://foo/bar/blah as the request-URI of a method if http://foo/ or http://foo/bar/ are redirect resources then the request must be redirected to the locations specified by those redirect resources with the remaining part of the request-URI appended to the redirection location. This means that when a HTTP URL is submitted the server must examine each segment of the URL and determine if any of those segments point to a redirect resource. This means that every time a URL is submitted a minimum of N lookups must occur where N equals the number of segments of the URL. This has a devastating effect on efficiency. In the current HTTP system one can implement a HTTP URL to resource mapping mechanism in two steps. Step 1 - Look up the name and get back the internal pointer to the resource. Step 2 - Use internal point to submit method to resource. Section 10 changes this, for all HTTP URL namespaces that have redirect support, to be: For (segment 1 to segment N) { If (typeof(segment) == redirect) { Issue 300 } } Segment(Method) The section 10 requirement would be the first time we ever required that the processing of a URL to resource mapping was dependent on the state of any resource other than the target. This seems like a really bad precedent to set as it significantly increases the complexity and cost of handling HTTP. In addition this requirement makes it very difficult and extremely inefficient to distribute one's namespace. If one wants to put http://foo/ on one server, http://foo/bar on another server and http://foo/bar/blah on a third server then any requests to http://foo/bar/blah MUST be sent to the two others servers in order to figure out if any of them is a redirect resources. This is an enormous burden to put on implementers wishing to distribute their namespace. (Note that in a WebDAV consistent namespace there would be a similar requirement but it would only apply to the immediate parent and so at most one other system, not N other systems as the redirect draft requires.) This all having been said, the motive behind introducing the section 10 behavior is clear and reasonable. The desire is to enable redirect resources to create the same experience for the end user as a bind resource. However here we run into an issue that is peculiar to HTTP. HTTP's resource namespace is not consistent. Even the WebDAV namespace, if non-WebDAV resources are included, is not required to be consistent. Namespace consistency brings with it too high a cost in terms of coordination and complexity to be mandatory. Therefore, at minimum, we require a type of redirect resource that does not have the section 10 behavior. This resource would expose the behavior we see today in various HTTP servers that allow their users to create 300 resources. Therefore I move that a type of redirect resource be specified in the redirect spec that does not have section 10 behavior. That having been said I am sympathetic to the desire to have the section 10 rules. They certainly replicate the behavior seen today in many systems. As such I will not object to the inclusion of a redirect resource with section 10 behavior in the redirect spec. However I do move that the authors must address the issue of what happens when the redirection location isn't a HTTP URL. How do we handle a request for http://foo/bar/blah when http://foo/bar is a redirect resource to ftp://itsy/bitsy? Paragraph 3 of section 10 reads: Note: If the DAV:reftarget property ends with a "/" and the remainder of the Request-URI is non-empty (and therefore must begin with a "/"), the final "/" in the DAV:reftarget property is dropped before the remainder of the Request-URI is appended. This behavior is in contradiction to both RFC 2518 and RFC 2616. Resources that end with a "/" are currently considered different resources from those that do not end with a "/". This is exactly the same issue brought up in Yaron.NoSlash (http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/0069.html) and I would love to see option 2 as listed there adopted. Failing that the authors must adopt option 1 and change the draft. Either way, I move that the authors must address this issue based on the requirements placed in Yaron.NoSlash. ------_=_NextPart_001_01BF7465.0D06479C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Yaron.Redirect.S10

Section 10 of the redirect = spec requires that given a HTTP URL http://foo/bar/blah as the request-URI of a = method if http://foo/ or = http://foo/bar/ are = redirect resources then the request must be redirected to the locations = specified by those redirect resources with the remaining part of the = request-URI appended to the redirection location. This means that when = a HTTP URL is submitted the server must examine each segment of the URL = and determine if any of those segments point to a redirect resource. = This means that every time a URL is submitted a minimum of N lookups = must occur where N equals the number of segments of the URL. This has a = devastating effect on efficiency. In the current HTTP system one can = implement a HTTP URL to resource mapping mechanism in two = steps.

Step 1 - Look up the name = and get back the internal pointer to the resource.
Step 2 - Use internal point = to submit method to resource.

Section 10 changes this, for = all HTTP URL namespaces that have redirect support, to be:

For (segment 1 to segment N) = {
   If = (typeof(segment) =3D=3D redirect) {
      Issue 300
   }
}
Segment(Method)

The section 10 requirement = would be the first time we ever required that the processing of a URL = to resource mapping was dependent on the state of any resource other = than the target. This seems like a really bad precedent to set as it = significantly increases the complexity and cost of handling = HTTP.

In addition this requirement = makes it very difficult and extremely inefficient to distribute one's = namespace. If one wants to put http://foo/ on one server, http://foo/bar on another = server and http://foo/bar/blah on a third server then any = requests to http://foo/bar/blah MUST be sent to the two = others servers in order to figure out if any of them is a redirect = resources. This is an enormous burden to put on implementers wishing to = distribute their namespace. (Note that in a WebDAV consistent namespace = there would be a similar requirement but it would only apply to the = immediate parent and so at most one other system, not N other systems = as the redirect draft requires.)

This all having been said, = the motive behind introducing the section 10 behavior is clear and = reasonable. The desire is to enable redirect resources to create the = same experience for the end user as a bind resource. However here we = run into an issue that is peculiar to HTTP. HTTP's resource namespace = is not consistent. Even the WebDAV namespace, if non-WebDAV resources = are included, is not required to be consistent. Namespace consistency = brings with it too high a cost in terms of coordination and complexity = to be mandatory.

Therefore, at minimum, we = require a type of redirect resource that does not have the section 10 = behavior. This resource would expose the behavior we see today in = various HTTP servers that allow their users to create 300 resources. = Therefore I move that a type of redirect resource be specified in the = redirect spec that does not have section 10 behavior.

That having been said I am = sympathetic to the desire to have the section 10 rules. They certainly = replicate the behavior seen today in many systems. As such I will not = object to the inclusion of a redirect resource with section 10 behavior = in the redirect spec. However I do move that the authors must address = the issue of what happens when the redirection location isn't a HTTP = URL. How do we handle a request for http://foo/bar/blah when http://foo/bar is a = redirect resource to ftp://itsy/bitsy?

Paragraph 3 of section 10 = reads:

Note: If the DAV:reftarget = property ends with a "/" and the remainder of
the Request-URI is = non-empty (and therefore must begin with a "/"), the
final "/" in the = DAV:reftarget property is dropped before the remainder
of the Request-URI is = appended.

This behavior is in = contradiction to both RFC 2518 and RFC 2616. Resources that end with a = "/" are currently considered different resources from those = that do not end with a "/". This is exactly the same issue = brought up in Yaron.NoSlash (http://lists.w3.org/Archives/Public/w3c-dist-auth/2000= JanMar/0069.html) and I would love to see option 2 as listed there = adopted. Failing that the authors must adopt option 1 and change the = draft. Either way, I move that the authors must address this issue = based on the requirements placed in Yaron.NoSlash.

------_=_NextPart_001_01BF7465.0D06479C-- From w3c-dist-auth-request@w3.org Fri Feb 11 02:59:00 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02102 for ; Fri, 11 Feb 2000 02:58:59 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id CAA23784; Fri, 11 Feb 2000 02:54:40 -0500 (EST) Resent-Date: Fri, 11 Feb 2000 02:54:40 -0500 (EST) Resent-Message-Id: <200002110754.CAA23784@www19.w3.org> Message-ID: <7DE119D3D0E15543874F7561EECBDBED0261A16E@BEG.platinum.corp.microsoft.com> From: Yaron Goland To: "'w3c-dist-auth@w3.org'" Date: Thu, 10 Feb 2000 23:54:20 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF7465.1EDE6134" Subject: Yaron.Redirect.BeKindToIANA Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4079 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF7465.1EDE6134 Content-Type: text/plain; charset="iso-8859-1" It would be a good thing (TM) if the IANA section contains a list of the methods, headers, XML elements, MIME types, URI protocols, etc. created by the spec. The goal is that the IANA folks shouldn't have to read anything but the IANA section in order to record what they need to record. ------_=_NextPart_001_01BF7465.1EDE6134 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Yaron.Redirect.BeKindToIANA

It would be a good thing = (TM) if the IANA section contains a list of the methods, headers, XML = elements, MIME types, URI protocols, etc. created by the spec. The goal = is that the IANA folks shouldn't have to read anything but the IANA = section in order to record what they need to record.

------_=_NextPart_001_01BF7465.1EDE6134-- From w3c-dist-auth-request@w3.org Fri Feb 11 02:59:34 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02116 for ; Fri, 11 Feb 2000 02:59:33 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id CAA23864; Fri, 11 Feb 2000 02:55:17 -0500 (EST) Resent-Date: Fri, 11 Feb 2000 02:55:17 -0500 (EST) Resent-Message-Id: <200002110755.CAA23864@www19.w3.org> Message-ID: <7DE119D3D0E15543874F7561EECBDBED0261A16F@BEG.platinum.corp.microsoft.com> From: Yaron Goland To: "'w3c-dist-auth@w3.org'" Date: Thu, 10 Feb 2000 23:54:51 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF7465.33BAF4B4" Subject: Yaron.Redirect.NotJustHTTP Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4080 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF7465.33BAF4B4 Content-Type: text/plain; charset="iso-8859-1" In my opinion the redirect spec doesn't do a good job of pointing out that the redirection URI could be a non-HTTP URI. As such I move that at least a few of the examples be changed to use non-HTTP URIs and that a sentence be thrown in somewhere pointing out explicitly that one can use non-HTTP URIs. ------_=_NextPart_001_01BF7465.33BAF4B4 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Yaron.Redirect.NotJustHTTP

In my opinion the redirect = spec doesn't do a good job of pointing out that the redirection URI = could be a non-HTTP URI. As such I move that at least a few of the = examples be changed to use non-HTTP URIs and that a sentence be thrown = in somewhere pointing out explicitly that one can use non-HTTP = URIs.

------_=_NextPart_001_01BF7465.33BAF4B4-- From w3c-dist-auth-request@w3.org Fri Feb 11 03:00:40 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02139 for ; Fri, 11 Feb 2000 03:00:40 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id CAA23910; Fri, 11 Feb 2000 02:56:21 -0500 (EST) Resent-Date: Fri, 11 Feb 2000 02:56:21 -0500 (EST) Resent-Message-Id: <200002110756.CAA23910@www19.w3.org> Message-ID: <7DE119D3D0E15543874F7561EECBDBED0261A170@BEG.platinum.corp.microsoft.com> From: Yaron Goland To: "'w3c-dist-auth@w3.org'" Date: Thu, 10 Feb 2000 23:55:56 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF7465.5A7DEFE8" Subject: Yaron.Redirect.NoAutoUpdate Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4081 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF7465.5A7DEFE8 Content-Type: text/plain; charset="iso-8859-1" The Foobar corporation has released their new redirection enhanced WebDAV server. The server can easily run on top of multiple volumes and map the volumes into the same URI namespace. In order to enhance the value of its server the Foobar corporation has put in a really cool feature. If a redirection resource and its target are both on the same volume then anytime the target is moved (within that volume) the redirection resource will have its location header response automatically adjusted. This isn't quite bind. First of all, their server can't do the redirection internally, it still needs to return a 302. Also, if the target is moved to another volume then the update doesn't work. But still, most people tend to keep their files together on the same volume so this is a really cool feature. Johnny then comes along to update his website. Because Delta-V doesn't exist he has to version by hand. The way he does it is by having a single redirection resource that points to his "tip" version directory. When version six of the website was ready Johnny moved the "tip" directory to the "five" directory and moved the "six" directory to the "tip" location. This enabled Johnny to update his website using a RFC 2518 client. This was useful because while Johnny had a redirect enabled client at home he often had to work on the road from random machines which usually had a RFC 2518 client such as Web Folders but didn't necessarily have a redirection client. However, unbeknownst to Johnny, he is using the Foobar corporation server and his redirection resource along with all of his files are on the same volume. So when Johnny moved the "tip" directory to the "five" directory the Foobar server happily updated the target of the redirection resource to point to "five". So when Johnny tested out his website he saw the old content instead of the new content. Since Johnny's request was a GET there wasn't any notice of the redirection or its destination so he couldn't even see that he was being sent to "five". He just typed in the URL, was quietly redirected and ended up in the wrong place. Even if he had seen the redirection URL (it could be displayed at the bottom of the browser window during the redirect) he still wouldn't understand how it had gotten set to "five". I can already hear the support phones ringing. The point of this example is to point out that many users will expect that since redirection resources do not guarantee integrity they will come to rely on the lack of integrity. They will depend on being able to change the target in all sorts of ways without having to worry that the redirection resource will see those changes. So if someone moves the target and then moved something else to the same name, they will reasonably expect that the redirection resource has not changed the URI it is redirecting to. Therefore I move that text be added to the definition of redirection resources specifying that the location can only be set and can only be changed through explicit user action. This will guarantee consistent/reliable behavior across all redirection resource implementations. ------_=_NextPart_001_01BF7465.5A7DEFE8 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Yaron.Redirect.NoAutoUpdate

The Foobar corporation has = released their new redirection enhanced WebDAV server. The server can = easily run on top of multiple volumes and map the volumes into the same = URI namespace. In order to enhance the value of its server the Foobar = corporation has put in a really cool feature. If a redirection resource = and its target are both on the same volume then anytime the target is = moved (within that volume) the redirection resource will have its = location header response automatically adjusted. This isn't quite bind. = First of all, their server can't do the redirection internally, it = still needs to return a 302. Also, if the target is moved to another = volume then the update doesn't work. But still, most people tend to = keep their files together on the same volume so this is a really cool = feature.

Johnny then comes along to = update his website. Because Delta-V doesn't exist he has to version by = hand. The way he does it is by having a single redirection resource = that points to his "tip" version directory. When version six = of the website was ready Johnny moved the "tip" directory to = the "five" directory and moved the "six" directory = to the "tip" location. This enabled Johnny to update his = website using a RFC 2518 client. This was useful because while Johnny = had a redirect enabled client at home he often had to work on the road = from random machines which usually had a RFC 2518 client such as Web = Folders but didn't necessarily have a redirection client.

However, unbeknownst to = Johnny, he is using the Foobar corporation server and his redirection = resource along with all of his files are on the same volume. So when = Johnny moved the "tip" directory to the "five" = directory the Foobar server happily updated the target of the = redirection resource to point to "five". So when Johnny = tested out his website he saw the old content instead of the new = content. Since Johnny's request was a GET there wasn't any notice of = the redirection or its destination so he couldn't even see that he was = being sent to "five". He just typed in the URL, was quietly = redirected and ended up in the wrong place. Even if he had seen the = redirection URL (it could be displayed at the bottom of the browser = window during the redirect) he still wouldn't understand how it had = gotten set to "five". I can already hear the support phones = ringing.

The point of this example is = to point out that many users will expect that since redirection = resources do not guarantee integrity they will come to rely on the lack = of integrity. They will depend on being able to change the target in = all sorts of ways without having to worry that the redirection resource = will see those changes. So if someone moves the target and then moved = something else to the same name, they will reasonably expect that the = redirection resource has not changed the URI it is redirecting = to.

Therefore I move that text = be added to the definition of redirection resources specifying that the = location can only be set and can only be changed through explicit user = action. This will guarantee consistent/reliable behavior across all = redirection resource implementations.

------_=_NextPart_001_01BF7465.5A7DEFE8-- From w3c-dist-auth-request@w3.org Fri Feb 11 03:02:41 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02209 for ; Fri, 11 Feb 2000 03:02:40 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id CAA23986; Fri, 11 Feb 2000 02:56:56 -0500 (EST) Resent-Date: Fri, 11 Feb 2000 02:56:56 -0500 (EST) Resent-Message-Id: <200002110756.CAA23986@www19.w3.org> Message-ID: <7DE119D3D0E15543874F7561EECBDBED0261A171@BEG.platinum.corp.microsoft.com> From: Yaron Goland To: "'w3c-dist-auth@w3.org'" Date: Thu, 10 Feb 2000 23:56:31 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF7465.6F93BBD8" Subject: Yaron.Redirect.ClientUpdate Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4082 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF7465.6F93BBD8 Content-Type: text/plain; charset="iso-8859-1" Maybe I just missed it but there doesn't seem to be any way to update the target of a redirection resource without deleting it. I move that a mechanism be provided that enables the target of a redirection resource to be updated without having to delete the resource. ------_=_NextPart_001_01BF7465.6F93BBD8 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Yaron.Redirect.ClientUpdate

Maybe I just missed it but = there doesn't seem to be any way to update the target of a redirection = resource without deleting it. I move that a mechanism be provided that = enables the target of a redirection resource to be updated without = having to delete the resource.

------_=_NextPart_001_01BF7465.6F93BBD8-- From w3c-dist-auth-request@w3.org Fri Feb 11 18:02:29 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25473 for ; Fri, 11 Feb 2000 18:02:28 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA18365; Fri, 11 Feb 2000 17:57:12 -0500 (EST) Resent-Date: Fri, 11 Feb 2000 17:57:12 -0500 (EST) Resent-Message-Id: <200002112257.RAA18365@www19.w3.org> From: ccjason@us.ibm.com X-Lotus-FromDomain: IBMUS To: "Roy T. Fielding" cc: Jim Whitehead , fielding@ebuilt.com, w3c-dist-auth@w3.org Message-ID: <85256882.007DFC73.00@D51MTA03.pok.ibm.com> Date: Fri, 11 Feb 2000 17:55:24 -0500 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Re: Qualities of URLs and resources Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4083 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list In other words, if you just remove *everything* in the bindings spec that defines an implementation, including all of the attempts at defining bindings as being something other than resources, then what you will end up with is a very simple protocol for manipulating URI mappings on remote servers. Roy, quick question. What do you mean by "a binding is a resource"? That bindings and resources are one to one? If so, when we say that two bindings point to the same "thing", what is the word you'd like to use for "thing". From w3c-dist-auth-request@w3.org Fri Feb 11 18:32:47 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26162 for ; Fri, 11 Feb 2000 18:32:42 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAA19858; Fri, 11 Feb 2000 18:27:02 -0500 (EST) Resent-Date: Fri, 11 Feb 2000 18:27:02 -0500 (EST) Resent-Message-Id: <200002112327.SAA19858@www19.w3.org> From: Jim Whitehead To: WebDAV WG Date: Fri, 11 Feb 2000 15:22:07 -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) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Subject: Reminder: WG Last Call, Redirect Reference Resources Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4084 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit This is a reminder that we are a little over 1/2 way through a working group last call for comments on the Redirect Reference Resources Protocol specification: http://www.ics.uci.edu/pub/ietf/webdav/collection/draft-ietf-webdav-redirect ref-protocol-02.txt The last call period ends February 22, 2000, at midnight, US Pacific time. The intent of the last call period is to allow working group members to perform a final review of the specification before it is submitted to the IESG for approval as a Proposed Standard. For more details on the last call, please consult the original message announcing the start of the last call period: http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/0165.html Furthermore, Yaron Goland expressed concern about holdng two back-to-back working group last call periods in this message: http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/0239.html Since I have not received any further emails expressing this same concern, and since the draft has so far received two good reviews, it is my judgement as Chair that the last call is achieving its goals, and no modifications to its schedule are necessary. - Jim Whitehead Chair, IETF WebDAV Working Group From w3c-dist-auth-request@w3.org Fri Feb 11 18:42:47 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26343 for ; Fri, 11 Feb 2000 18:42:43 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAA20184; Fri, 11 Feb 2000 18:37:09 -0500 (EST) Resent-Date: Fri, 11 Feb 2000 18:37:09 -0500 (EST) Resent-Message-Id: <200002112337.SAA20184@www19.w3.org> To: ccjason@us.ibm.com cc: w3c-dist-auth@w3.org In-reply-to: Your message of "Fri, 11 Feb 2000 17:55:24 EST." <85256882.007DFC73.00@D51MTA03.pok.ibm.com> Date: Fri, 11 Feb 2000 15:36:55 -0800 From: "Roy T. Fielding" Message-ID: <200002111536.aa06893@gremlin-relay.ics.uci.edu> Subject: Re: Qualities of URLs and resources Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4085 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list >Roy, quick question. What do you mean by "a binding is a resource"? >That bindings and resources are one to one? If so, when we say that >two bindings point to the same "thing", what is the word you'd like to >use for "thing". A binding is an internal redirect from one resource to another. The binding is a resource, and what it points to is a resource, but they are not necessarily the same resource just because the bindings exist. The binding is simply a method for establishing a temporary shared mapping mechanism for two or more URI. The client does not identify the mapping mechanism; rather, it describes the relationship between the three resources (source, destination, and source collection) such that the server can figure out on its own how to align the mapping mechanism in a mechanism-dependent manner. ....Roy From w3c-dist-auth-request@w3.org Sat Feb 12 21:05:46 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29081 for ; Sat, 12 Feb 2000 21:05:45 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id VAA04410; Sat, 12 Feb 2000 21:00:54 -0500 (EST) Resent-Date: Sat, 12 Feb 2000 21:00:54 -0500 (EST) Resent-Message-Id: <200002130200.VAA04410@www19.w3.org> To: Yaron Goland cc: "'w3c-dist-auth@w3.org'" In-reply-to: Your message of "Thu, 10 Feb 2000 23:46:30 PST." <7DE119D3D0E15543874F7561EECBDBED0261A164@BEG.platinum.corp.microsoft.com> Date: Sat, 12 Feb 2000 18:00:39 -0800 From: "Roy T. Fielding" Message-ID: <200002121800.aa26254@gremlin-relay.ics.uci.edu> Subject: Re: Yaron.Redirect.Sec4LastPar Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4086 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list >Given the numerous changes I request in my comments the previous description >is no longer accurate. I also felt that it didn't provide a sufficiently >broad overview of the total functionality provided by redirect resources. >Below I provide several paragraphs that I suggest replace the previous one: Yaron, wouldn't it be easier to just write your own version of the reference spec and propose that in its entirety? There is a point beyond which many small deltas are less efficient than a complete entity, and you passed that a few messages ago. ....Roy [I am agreeing with most of your comments] From w3c-dist-auth-request@w3.org Sat Feb 12 21:13:17 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29128 for ; Sat, 12 Feb 2000 21:13:17 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id VAA04530; Sat, 12 Feb 2000 21:08:32 -0500 (EST) Resent-Date: Sat, 12 Feb 2000 21:08:32 -0500 (EST) Resent-Message-Id: <200002130208.VAA04530@www19.w3.org> To: Yaron Goland cc: "'w3c-dist-auth@w3.org'" In-reply-to: Your message of "Thu, 10 Feb 2000 23:52:33 PST." <7DE119D3D0E15543874F7561EECBDBED0261A16C@BEG.platinum.corp.microsoft.com> Date: Sat, 12 Feb 2000 18:08:24 -0800 From: "Roy T. Fielding" Message-ID: <200002121808.aa27228@gremlin-relay.ics.uci.edu> Subject: Re: Yaron.Redirect.NoRelative Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4087 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list >Section 9 of the redirect spec allows for the use of relative URIs in the >reftarget production. Relative URIs are an extremely dangerous feature that >have caused havoc amongst system implementers. That's b.s. Relative URIs are trivial to implement and the only reason that havoc occurs is because some HTML authoring tools try to be bugward compatible with Mosaic 1.0. Protocol engines have no such constraint. ....Roy From w3c-dist-auth-request@w3.org Sat Feb 12 21:28:15 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29188 for ; Sat, 12 Feb 2000 21:28:15 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id VAA04623; Sat, 12 Feb 2000 21:23:38 -0500 (EST) Resent-Date: Sat, 12 Feb 2000 21:23:38 -0500 (EST) Resent-Message-Id: <200002130223.VAA04623@www19.w3.org> To: Jim Whitehead cc: Larry Masinter , w3c-dist-auth@w3.org In-reply-to: Your message of "Thu, 10 Feb 2000 18:09:18 PST." Date: Sat, 12 Feb 2000 18:23:18 -0800 From: "Roy T. Fielding" Message-ID: <200002121823.aa28830@gremlin-relay.ics.uci.edu> Subject: Re: Qualities of URLs and resources Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4088 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list In message , Jim Whitehead writes: >Larry Masinter writes: >> Neither of these notations captures content negotiation, and it isn't >> OK to remove 't'. The whole *point* is to understand what are >> the things that are stable over time and which things can change, and how. > >Well, it was my intent that the set of values (V1, V2, ... Vn) represent >variants of the resource at a particular instant in time, and hence I >thought I was modeling content negotiated resources. But, as Geoff Clemm >points out, both Roy and I did omit the Accept headers as an input to the >RMap function. I omitted them because they do not modify the resource mapping. If we talk instead about the content selection process, determining which V(i) to use as the representation of that resource at time t, then yes you would have to include all aspects of the request, including its context (lower-layer protocol things like IP address, SSL identity, etc.). ....Roy From w3c-dist-auth-request@w3.org Sat Feb 12 22:24:39 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00383 for ; Sat, 12 Feb 2000 22:24:39 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id WAA05016; Sat, 12 Feb 2000 22:16:57 -0500 (EST) Resent-Date: Sat, 12 Feb 2000 22:16:57 -0500 (EST) Resent-Message-Id: <200002130316.WAA05016@www19.w3.org> To: "Geoffrey M. Clemm" cc: w3c-dist-auth@w3.org In-reply-to: Your message of "Fri, 21 Jan 2000 11:56:36 EST." <10001211656.AA26520@tantalum> Date: Sat, 12 Feb 2000 19:16:40 -0800 From: "Roy T. Fielding" Message-ID: <200002121916.aa04745@gremlin-relay.ics.uci.edu> Subject: Re: draft-ietf-webdav-binding-protocol-02 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4089 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list [Yeah, I know, a little late ...] In message <10001211656.AA26520@tantalum>, "Geoffrey M. Clemm" writes: >This is a model we considered (and JimW even did some impressive ASCII >art to illustrate it), but we found that saying that "every URI >identifies a unique resource" makes the term "resource" irrelevant. If the purpose of the spec was to define "resource", then I would agree with you. However, it isn't -- resources cover a lot more ground than even HTTP/1.1 as a whole defines. What I said was that "for the purposes of the bind protocol" you can consider each URI to identify a unique resource, because the purpose of bind is to create new identifiers without the addition if another implementation mechanism (hence, whether or not it creates a new resource in the process is not applicable). >The point of the binding spec was to allow two different URI's to >identify the same "something". If we say that every URI identifies a >unique resource, then we need another term, say "object", and now all >of our semantics are in terms of URI's and objects, i.e. "A bind >causes two URI's to be mapped to the same object". The spec's problem is that it is trying to define BIND in terms of the server implementation instead of in terms of its impact on the Web interface. There is no terminology in HTTP for the implementation thingies because we didn't want anything in the protocol to influence the set of possible implementations using the protocol. It is the nature of every engineer to define things in terms of the characteristics of the components that will be used to compose the finished product. The Web doesn't work that way. The Web architecture consists of constraints on the communication model between components, based on the role of each component during an application action. Bindings need to be defined in terms of how it impacts the interface. A binding creates a new name in a collection's namespace which has an implementation mechanism identical to that of the bound resource. That's the semantics, in one sentence. The rest of the spec should simply define the syntax used to express those semantics. ....Roy From w3c-dist-auth-request@w3.org Mon Feb 14 11:40:12 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16568 for ; Mon, 14 Feb 2000 11:40:10 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id LAA02781; Mon, 14 Feb 2000 11:33:16 -0500 (EST) Resent-Date: Mon, 14 Feb 2000 11:33:16 -0500 (EST) Resent-Message-Id: <200002141633.LAA02781@www19.w3.org> To: WebDAV WG cc: reuterj@ira.uka.de, jjh@ira.uka.de Date: Mon, 14 Feb 2000 17:32:54 +0100 From: Juergen Reuter Message-ID: <"iraun1.ira.0000201:000214.163300"@ira.uka.de> Subject: Review: Redirect Reference Resources -- Part two Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4090 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Following the working group's last call for comments, below is the second part of a review of the Redirect Reference Resources Protocol. It covers chapters 7 to 11 of the protocol. ******** > 7 Operations on Collections That Contain Redirect Reference Resources > ... > Consistent with the rules in Section 6, the response for each redirect > reference encountered while processing a collection MUST be a 302 > (Found) unless a Apply-To-Redirect-Ref header is included with the > request. Just an idea: one could consider to specify the field value of the Apply-To-Redirect-Ref header to optionally contain a list of internal member URIs, allowing a request method on a collection to apply to redirect reference resources for a selected set of URIs only. > The DAV:location pseudo-property ... Just wondering: why is it called a "pseudo"-property? Is there anything on it that does not match the regular definition of a DAV property? > A referencing-aware client can either use the URI value of > the DAV:location pseudo-property to resubmit its request to the target > resource, or it can submit the request to the redirect reference > resource with Apply-To-Redirect-Ref. Once again, I suppose you merely want to present two examples of typical behaviour that a client may choose rather than limiting the client's capabilities of submitting requests. Hence, I move to fix the wording accordingly. > It is recommended that future editors of [WebDAV] define the > DAV:location pseudo-property in [WebDAV], so that non-referencing > clients will also be able to use the response to operate on the target > resource. This specification introduces redirect references to be viewed as WebDAV resources, while, from the perspective of WebDAV, redirect references are still no WebDAV resources. Hence, in WebDAV, redirect references can not be associated with properties. In so far, I do not see how to introduce a DAV:location property in WebDAV with the imposed semantics. > (This will also enable clients to operate on traditional > HTTP/1.1 302 responses in Multi-Status responses.) This probably should read: "This can also save one round-trip for WebDAV clients when operating on HTTP/1.1 302 responses in Multi-Status responses arisen from either ordinary redirect references or redirect reference resources." > Until then, non- > referencing clients will not be able to process 302 responses from > redirect reference resources encountered while processing a > collection. That is not true. You just have to do one more round-trip for each 302 response. Summarizing the last three paragraphs, I think it might be a good idea for future WebDAV specifications to somehow include the information of the Location response header field for each 302 response in a Multi-Status response; but I think this can not be done using resource properties as currently defined in WebDAV. By the way, is that the reason why the DAV:location property is called a "pseudo"-property? > 7.1 MOVE and DELETE on Collections That Contain Redirect References > ... > MOVE removes that binding and creates a new binding to the same > resource. Atomically (from WebDAV clients' perspective)? > In cases where DELETE and MOVE are applied to a collection, these > operations affect all the descendents of the collection, but they do so > indirectly. > There is no need to visit each descendent in order to process the > request. > Consequently, even if there are redirect reference > resources in a tree that is being deleted or moved, there will be no > 302 responses from the redirect reference resources. I agree that there should be no 302 repsonses, but I can not follow the argumentation. For DELETE on collections, WebDAV says: "DELETE instructs that the collection specified in the Request-URI and all resources identified by its internal member URIs are to be deleted." In the case of a redirect reference resource, this means that the redirect reference resource is to be deleted. Note, that WebDAV does not require a DELETE to be performed on the resource, but that the resource be deleted. Hence, for a DELETE on a collection, there will be no 302 response from a redirect reference resource in a collection. Similary, for a MOVE on a collection, WebDAV does not require a MOVE to be performed on each resource identified by the internal member URIs of the collection identified by the Request-URI be moved, but each of these resources be moved to locations relative to the Request-URI. Hence, for a MOVE on a collection, there will be no 302 response from a redirect reference resource in a collection. For MOVE on collections, WebDAV says: "A MOVE with "Depth: infinity" instructs that the collection identified by the Request-URI be moved to the URI specified in the Destination header, and all resources identified by its internal member URIs are to be moved to locations relative to it, recursively through all levels of the collection hierarchy." Once again, It may be worth noting that, when the DAV:reftarget property contains a relative URI, a MOVE applied to a collection may result in redirect reference resources with dangling references. Anyway, is there any difference in the semantics between a DAV:reftarget property and a DAV:location property except that DAV:reftarget may be a relative URI? If not, could the DAV:reftarget be dropped and DAV:location always be used instead? By the way, HTTP/1.1 does not allow a Location URI to be relative. I do not know the reason, but could that also be a good reason to forbid relative URIs as DAV:reftarget properties? > 7.2 LOCK on a Collection That Contains Redirect References > > LOCK poses special problems because it is atomic. An attempt to lock > (with Depth: infinity) a collection that contains redirect references > will always fail. Probably, this should read "MUST always fail" instead of "will always fail". However, I do not understand why it should fail at all. As far as I understand section 7.1, upon a DELETE redirect references are deleted rather than returning a 302 response. What is the reason that LOCK should behave differently? > Reference-aware clients can lock the collection by using Apply-To- > Redirect-Ref, and, if desired, lock the targets of the redirect > references individually. I see. The first paragraph of this section will prevent clients unaware of this specification to LOCK a collection that contains redirect references, while the above paragraph allows clients aware of this specification to perform the LOCK. However, section 8.4.10 of WebDAV says: "If the Depth header is set to infinity then the resource specified in the Request-URI along with all its internal members, all the way down the hierarchy, are to be locked." In the case of a redirect reference resource, I think the intended meaning of WebDAV is that the resource itself is the internal member to be locked, not the target resource. In so far, I think, the Apply-To-Redirect-Ref target should implicitly always be set, and a LOCK request for a collection MUST fail if in the hierarchy of collections there is an ordinary redirect reference as internal member. > 7.3 Example: PROPFIND on a Collection with Redirect Reference Resources > > Suppose a PROPFIND request with Depth = infinity > ... 'Depth = infinity' probably should read '"Depth: infinity"'. > 7.4 Example: PROPFIND with Apply-To-Redirect-Ref on a Collection with > Redirect Reference Resources > ... > Depth = infinity Cp. section 7.3. > Since the Apply-To-Redirect-Ref header is present, the response shows > the properties of the redirect reference resource in the collection > rather than the properties of its target. The response should not show the properties of the target even if the Apply-To-Redirect-Ref header is not present, since the purpose of a redirect reference resource is "to forward requests to another resource (its target)" (see introduction), unlike a direct reference resource that "automatically forwards requests to another resource, in a way that is transparent to the client" (see chapter 3). > 7.6 Example: LOCK on a Collection That Contains a Redirect Reference > Resource > ... > >> Response: > > HTTP/1.1 207 Multi-Status Section 8.10.4 of WebDAV requires that "if the lock cannot be granted to all resources, a 409 (Conflict) status code MUST be returned with a response entity body ... ". (FYI: The example in section 8.10.10 of WebDAV also erroneously returns a 207 code.) > ... > > http://www.svr.com/MyCollection/diary.html > HTTP/1.1 424 Failed Dependency > Although WebDAV does not clearly state when a 424 code should be returned upon a failed LOCK, from the example in 8.10.10 of WebDAV, I guess that upon diary.html there should no 424 be returned, because it is not an ancestor of a member that is responsible for the LOCK failing (and this behaviour would be analogous to that of DELETE as described in section 8.6.2 of WebDAV). > ... > At that point both the reference resource > and its target resource will be locked Once again, I think that at that point the target resource should not be locked, according to the purpose of a redirect reference resource "to forward requests to another resource (its target)". > 8 Operations on Targets of Redirect Reference Resources > > Operations on targets of redirect reference resources have no effect on > the reference resource. This is yet another reason that at that point (see previous paragraph) the target resource should not be locked. > 9 Relative URIs in DAV:reftarget > > The URI in the href in a DAV:reftarget property MAY be a relative > URI. See above comment on relative URIs in last paragraph to section 7.1. > In this case, the base URI to be used for resolving the relative URI to > absolute form is the URI used in the HTTP message to identify the > redirect reference resource to which the DAV:reftarget property belongs. It may be worth noting that section 5.1 of WebDAV mentions that multiple URIs may identify a single resource: "Although implicit in [RFC2068] and [RFC2396], any resource, including collection resources, MAY be identified by more than one URI. For example, a resource could be identified by multiple HTTP URLs." Hence, resolution of the relative URI for a single resource may result in multiple absolute URIs, depending on the URI used in the current HTTP request message. > When DAV:reftarget appears in the context of a Multi-Status response, it > is in a DAV:response element that contains a single DAV:href element. > The value of this DAV:href element serves as the base URI for resolving > a relative URI in DAV:reftarget. It should be noted that in this context the value of the DAV:href element always denotes a redirect reference resource, i.e. a non-collection resource. Hence, to resolve a relative URI in DAV:reftarget, the last segment of the DAV:href element must be ignored. Otherwise, in the example in section 9.2, the resolved URI would become "http://www.xxsrv.com/geog/stats.html/statistics/population/1997.html" instead of "http://www.xxsrv.com/geog/statistics/population/1997.html". > 10 Redirect References to Collections > ... > Note: If the DAV:reftarget property ends with a "/" and the remainder of > the Request-URI is non-empty (and therefore must begin with a "/"), the > final "/" in the DAV:reftarget property is dropped before the remainder > of the Request-URI is appended. I suggest to consider that the value of a DAV:reftarget property MUST NOT end with a "/". > /x/ -----> /a/ > /a/y/ -----> /b/ > /b/z.html -----> /c/d.html Personally, I would prefer a slightly different visualisation that shows the process of substitution, e.g. something like the following: /x/y/z.html | | /x -> /a | v /a/y/z.html | | /a/y -> /b | v /b/z.html | | /b/z.html -> /c/d.html | v /c/d.html > 11 Headers > > 11.1 Redirect-Ref Response Header > ... > not a plain HTTP/1.1 redirect > ... Yet another term for "ordinary redirect reference"? > 11.2 Apply-To-Redirect-Ref Request Header > See the above suggestion for an extension of this header in chapter 7. See the above discussion on forwarding and direct reference resources in chapters 4, 5 and section 7.3. > If the Apply-To-Redirect-Ref header is used on a request to any other > sort of resource besides a redirect reference resource, the server > SHOULD ignore it. This is redundant, as HTTP/1.1 already requires any unrecognized header to be ignored. ... to be continued ... Juergen Reuter From w3c-dist-auth-request@w3.org Mon Feb 14 13:57:31 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20961 for ; Mon, 14 Feb 2000 13:57:30 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA08638; Mon, 14 Feb 2000 13:52:28 -0500 (EST) Resent-Date: Mon, 14 Feb 2000 13:52:28 -0500 (EST) Resent-Message-Id: <200002141852.NAA08638@www19.w3.org> Message-ID: <8E3CFBC709A8D21191A400805F15E0DBD245A6@crte147.wc.eso.mc.xerox.com> From: "Slein, Judith A" To: "'Juergen Reuter'" , WebDAV WG Cc: jjh@ira.uka.de Date: Mon, 14 Feb 2000 13:51:54 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Review: Redirect Reference Resources -- Part one Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4091 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Juergen, Thanks very much for your detailed review of the first 6 sections of Redirect References. I am sure that most of your suggestions for improved language and focus in the spec will be accepted. I'll just comment here on a few of the deeper issues that you raise. -----Original Message----- From: Juergen Reuter [mailto:reuterj@ira.uka.de] Sent: Monday, February 07, 2000 8:51 AM To: WebDAV WG Cc: reuterj@ira.uka.de; jjh@ira.uka.de Subject: Review: Redirect Reference Resources -- Part one > If the client is aware that it is operating on a redirect reference > resource, it can resolve the reference by retrieving the reference > resource's DAV:reftarget property (defined in Section 12.1 below), whose > value contains the URI of the target resource. It can then submit > requests to the target resource. Why not using the HTTP Location header field to resolve the reference? This can be (and usually is) done even by clients that are unaware of the above. The true reason for introducing a DAV:reftarget property seems to be the possibility to *modify* the URI of the target resource rather than resolving the reference. You are right that we need to step back and consider why we introduced the DAV:reftarget property to begin with: There is no other way to find the redirect references to a given resource except by doing a search on this property. (Even with DAV:reftarget, you can only discover the local redirects to a given resource.) A referencing-aware client can operate more efficiently with this property. For example, if it needs to perform some operation on the targets of all of the redirect references in a collection, it can do a PROPFIND to retrieve all the DAV:reftarget properties at once, and submit requests directly to the target resources, instead of performing two round-trips for each redirect reference. At the moment the spec prevents the use you suggest, since it says that DAV:reftarget is readonly. The rationale for this was that changing the value of DAV:reftarget (changing what resource it points to) is effectively to create an entirely new redirect reference, so we would do better to require clients to do a new MKRESOURCE with the desired DAV:reftarget. But since the server is (probably) not going to maintain DAV:reftarget, the client might just be wanting to update it to keep it pointing at the same resource. So maybe it should be a client-writable property. > A redirect reference resource is a new type of resource. To distinguish > redirect reference resources from non-reference resources, a new value > of the DAV:resourcetype property (defined in [WebDAV]), DAV:redirectref, > is defined in Section 13.1 below. Just wondering: is there a standardized registration procedure for new DAV:resourcetype property values, e.g. something like MIME registration procedures as defined in RFC 2048? If not, that might substantially impair interoperability. There is no standardized registration procedure. Should we make this an issue on the RFC-2518 list? > 5.1 MKRESOURCE > > The body of the new resource is empty. What is the body of a resource? For standard data containers, the intended meaning seems to be clear, but what is the meaning for other resource types? In this case, this probably should read "The entity body of a response returned from a GET request on the new resource MUST be empty.", or the term "body of a resource" should be defined somewhere else. (N.b.: WebDAV also uses the term "body of a resource" in sections 8.10.2 and 17.5 without prior definition). Anyway, for clients that do not support automatic redirection, it is sensible to provide some text/html response body to be returned from a GET request that can be shown to the user. Hence, I move to take away the restriction that the body must be empty. You are right that something needs to be done about this language. Joe Orton also pointed out that there is confusion here and in our discussion of PUT with redirect references about what is allowed and what the result is. MKRESOURCE is defined not just for this spec, but also for DeltaV, and the plan is for the two specs to contain identical definitions (Section 5.1 of redirect references should be identical to what appears in the DeltaV spec). The intent is that the MKRESOURCE method lets you create a resource and set its properties, but it doesn't provide any way to do the equivalent of a PUT. So we need to find a way to express that without preventing the useful behavior you describe, of responding to GET with a response body explaining that the resource you are looking for is located somewhere else. > The properties of the new resource are as specified by the > DAV:propertyupdate request body, using PROPPATCH semantics. . . . This leads to a new question: is MKRESOURCE atomic (from all WebDAV client's perspective)? Or can another client access the new resource's properties before they fully have been initialized? If an error is encountered while initializing the properties, that means that some properties may have been initialized, while others still are undefined; atomicity would at least in that case be broken. However, if MKRESOURCE could atomically create and (read & write) lock a resource, this would prevent other clients from accessing the newly created resource until the creator decides to remove the lock. Hence, I would like to put up for discussion the following question: Should a MKRESOURCE request may contain a DAV:lockinfo XML element and those request headers defined for the LOCK method in order to request atomic creation and locking of a new resource? I would rather not take on this issue in the context of redirect references. Whatever the semantics of PROPPATCH are in RFC 2518, that's what you get here. If RFC 2518 provides a way to ask that a resource be read-locked while its properties are being set, it can be used here. Otherwise, not. I would actually be just as happy myself to have MKRESOURCE do nothing more than create a resource, and make setting its properties be a separate operation. But I know that others feel strongly that MKRESOURCE needs to do both. From w3c-dist-auth-request@w3.org Mon Feb 14 14:21:31 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21658 for ; Mon, 14 Feb 2000 14:21:28 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA09477; Mon, 14 Feb 2000 14:13:33 -0500 (EST) Resent-Date: Mon, 14 Feb 2000 14:13:33 -0500 (EST) Resent-Message-Id: <200002141913.OAA09477@www19.w3.org> Message-ID: <8E3CFBC709A8D21191A400805F15E0DBD245A7@crte147.wc.eso.mc.xerox.com> From: "Slein, Judith A" To: "'Yaron Goland'" , w3c-dist-auth@w3.org Date: Mon, 14 Feb 2000 14:13:07 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Yaron.Redirect.ReallyNoBind Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4092 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list I've been pushing the hardest to keep this stuff in. There are 2 reasons. First, it's essential that people be able to figure out whether they are reading the right spec. Redirect references and bindings are in the same space, but clearly bindings will be right for some applications and redirect references for others. There needs to be enough information for implementers to understand the basic differences and realize that there may be a spec that fits their needs better than this one. Second, it's often easier to communicate a concept by explaining what it is not than by explaining what it is. We have to do both, in my opinion. There have been continuing requests for binding-like behavior and for direct-reference-like behavior in redirect references. We can stop those requests and make it clearer what functionality we are trying to define here by saying straight out that redirect references are not like bindings, and here's why; and redirect references are not like direct references, and here's why. --Judy -----Original Message----- From: Yaron Goland [mailto:yarong@Exchange.Microsoft.com] Sent: Friday, February 11, 2000 1:31 AM To: w3c-dist-auth@w3.org Subject: Yaron.Redirect.ReallyNoBind The 6th and 8th paragraphs of the introduction of the redirect spec go into a discussion of the difference between bind and redirect resources. These sections will only serve to confuse the reader as one need understand nothing about bind in order to successfully implement redirect. As such I move that the sections discussing bind as compared to redirect resources be removed. From w3c-dist-auth-request@w3.org Mon Feb 14 15:40:15 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23287 for ; Mon, 14 Feb 2000 15:40:15 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA11860; Mon, 14 Feb 2000 15:34:52 -0500 (EST) Resent-Date: Mon, 14 Feb 2000 15:34:52 -0500 (EST) Resent-Message-Id: <200002142034.PAA11860@www19.w3.org> Message-ID: <8E3CFBC709A8D21191A400805F15E0DBD245AB@crte147.wc.eso.mc.xerox.com> From: "Slein, Judith A" To: "'Yaron Goland'" , "'w3c-dist-auth@w3.org'" Date: Mon, 14 Feb 2000 15:31:23 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Yaron.Redirect.4th2nd Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4093 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Again, I think a basic understanding of how redirect references are intended to differ from direct references is crucial to understanding the spec. I'm not wedded to any of the details of the language, though. --Judy -----Original Message----- From: Yaron Goland [mailto:yarong@Exchange.Microsoft.com] Sent: Friday, February 11, 2000 2:42 AM To: 'w3c-dist-auth@w3.org' Subject: Yaron.Redirect.4th2nd The first sentence of the second paragraph of section 4 reads: "A redirect reference resource never automatically forwards requests to its target resource." I believe that the word "automatically" is misleading in that it implies that if one sends the right header or body the redirect resource might actually forward the request for you. In addition this sentence runs afoul of Yaron.Redirect.Forwarding. As such I move that this sentence be changed to read "A redirect resource blindly issues 302 (Found) redirect responses point at its target resource." The second sentence of the same paragraph reads: "It is this characteristic that distinguishes redirect reference resource from direct reference resources and from bindings." The removal of this sentence, consistent with Yaron.Redirect.NoReferenceorDirectResource, would remove the only reference to direct reference resources outside of the terminology section. Therefore I move that this entire sentence be removed from the draft. The last two sentences of the same paragraph read: "It is also what insures that redirect reference resources will be simple to implement and that cross-server references will be possible. If the redirect reference resource were required to forward requests automatically, the server would need proxy capabilities in order to support cross-server references." I found the language confusing and it violated Yaron.Redirect.Servers. Therefore I move that the language be altered to read: "Redirect resources bring the same benefits as links in HTML documents. They can be created and maintained without the involvement or even knowledge of their target resource. This reduces the cost of linking between resources." From w3c-dist-auth-request@w3.org Mon Feb 14 17:55:28 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25922 for ; Mon, 14 Feb 2000 17:55:26 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA16619; Mon, 14 Feb 2000 17:48:03 -0500 (EST) Resent-Date: Mon, 14 Feb 2000 17:48:03 -0500 (EST) Resent-Message-Id: <200002142248.RAA16619@www19.w3.org> Message-ID: <7DE119D3D0E15543874F7561EECBDBED0261A17C@BEG.platinum.corp.microsoft.com> From: Yaron Goland To: "'Slein, Judith A'" , w3c-dist-auth@w3.org Date: Mon, 14 Feb 2000 14:47:27 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Yaron.Redirect.4th2nd Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4094 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list What evidence is available that would lead one to conclude that it would be difficult to grasp redirect references without understanding direct references, especially given that HTTP/1.1 was able to define a redirect without having to reference its direct variant? > -----Original Message----- > From: Slein, Judith A [mailto:JSlein@crt.xerox.com] > Sent: Mon, February 14, 2000 12:31 PM > To: Yaron Goland; w3c-dist-auth@w3.org > Subject: RE: Yaron.Redirect.4th2nd > > > Again, I think a basic understanding of how redirect > references are intended > to differ from direct references is crucial to understanding > the spec. I'm > not wedded to any of the details of the language, though. > > --Judy > > -----Original Message----- > From: Yaron Goland [mailto:yarong@Exchange.Microsoft.com] > Sent: Friday, February 11, 2000 2:42 AM > To: 'w3c-dist-auth@w3.org' > Subject: Yaron.Redirect.4th2nd > > > > The first sentence of the second paragraph of section 4 > reads: "A redirect > reference resource never automatically forwards requests to its target > resource." > > I believe that the word "automatically" is misleading in that > it implies > that if one sends the right header or body the redirect resource might > actually forward the request for you. In addition this > sentence runs afoul > of Yaron.Redirect.Forwarding. As such I move that this > sentence be changed > to read "A redirect resource blindly issues 302 (Found) > redirect responses > point at its target resource." > > The second sentence of the same paragraph reads: "It is this > characteristic > that distinguishes redirect reference resource from direct reference > resources and from bindings." > > The removal of this sentence, consistent with > Yaron.Redirect.NoReferenceorDirectResource, would remove the > only reference > to direct reference resources outside of the terminology > section. Therefore > I move that this entire sentence be removed from the draft. > > The last two sentences of the same paragraph read: "It is > also what insures > that redirect reference resources will be simple to implement and that > cross-server references will be possible. If the redirect reference > resource were required to forward requests automatically, the > server would > need proxy capabilities in order to support cross-server references." > > I found the language confusing and it violated Yaron.Redirect.Servers. > Therefore I move that the language be altered to read: > "Redirect resources > bring the same benefits as links in HTML documents. They can > be created and > maintained without the involvement or even knowledge of their target > resource. This reduces the cost of linking between resources." > From w3c-dist-auth-request@w3.org Mon Feb 14 18:42:35 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26508 for ; Mon, 14 Feb 2000 18:42:33 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAA18507; Mon, 14 Feb 2000 18:38:04 -0500 (EST) Resent-Date: Mon, 14 Feb 2000 18:38:04 -0500 (EST) Resent-Message-Id: <200002142338.SAA18507@www19.w3.org> Message-Id: <200002142337.SAA00271@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ X-PGP-Key: 2F07A741 ; 78 15 8E 8B C0 06 5D D1 BC 08 05 7F 42 81 7E 90 To: apps area chairs and working groups: ; cc: ietf@ietf.org reply-to: ietf@ietf.org From: Keith Moore Date: Mon, 14 Feb 2000 18:37:05 -0500 Subject: IETF Adelaide and interim meetings for APPS WGs Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4095 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list It has come to the attention of the Applications Area Directors that one or more Applications area working groups have elected to not meet in Adelaide, and instead to hold an "interim meeting" in the United States, presumably because of distance and/or cost issues. IETF is an international organization, and it is IETF's longstanding practice to hold its meetings in various locations around the planet. This serves both to encourage wider participation in IETF and also to more fairly distribute travel costs and inconvenience (over time) among all participants. The scheduleing of an interim WG meeting in the US in lieu of a WG meeting in Adelaide undermines this policy. This is insulting to non-US participants of IETF (many of whom have attended meetings in the US for years), embarassing to IETF as a whole, and a threat to IETF's international stature. Even if a working group has few participants outside the United States, a working group does not work in isolation from other working groups. Attendance at IETF meetings is an invaluable mechanism for cross-group collaboration. RFC 2418 states: Interim meetings are subject to the same rules for advance notification, reporting, open participation, and process, which apply to other working group meetings. Since normal working group meetings require advance notification via email to the entire IETF list, and the process for getting a meeting slot involves prior approval of the Area Directors, the same requirements apply to interim working group meetings. Part of the reason for prior approval being required is to ensure that the locations of the meetings are not being chosen to favor certain participants over others. There have been several violations of this policy since publication of RFC 2418. Therefore, - All interim meetings within the Applications Area which were not previously and explicitly approved by the Applications Area Directors, are hereby cancelled. - No Applications Area group will hold any interim meeting prior to April 15. - No Applications Area group which does not hold a meeting in Adelaide, will hold any interim meeting prior to July 31. (i.e. prior to the Pittsburg IETF meeting) - This applies to all face to face meetings held for the purpose of conducting working group discussion and to which the working group is invited, even if labelled "informal" or otherwise labelled to distinguish them from official working group meetings. - Exceptions to this policy may be made for recently chartered groups, but Area Director approval is still required for such groups to schedule interim meetings. for the Applications Area Directors, Keith Moore From w3c-dist-auth-request@w3.org Tue Feb 15 10:31:51 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09314 for ; Tue, 15 Feb 2000 10:31:50 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id KAA05070; Tue, 15 Feb 2000 10:24:42 -0500 (EST) Resent-Date: Tue, 15 Feb 2000 10:24:42 -0500 (EST) Resent-Message-Id: <200002151524.KAA05070@www19.w3.org> From: jamsden@us.ibm.com X-Lotus-FromDomain: IBMUS To: ietf-dav-versioning@w3.org, w3c-dist-auth@w3.org Message-ID: <85256886.00549F89.00@d54mta03.raleigh.ibm.com> Date: Tue, 15 Feb 2000 10:22:14 -0500 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Delta-V Meeting at Adelaide Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4096 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list I would like to consider scheduling a Delta-V working group meeting at Adelaide and would like to get an update on how many working group members would be interested in attending. We have made some great progress since our last meeting. There is an update to the versioning specification available at http://www.webdav.org/deltav/protocol/draft-ietf-deltav-versioning-03.txt that takes into consideration all the great feedback we got at the December IETF working group meeting. Tim Ellison has also create a really great set of scenarios at http://www.webdav.org/deltav/scenarios/scenarios-00-1.htm that tie together the versioning goals with the protocol to provide a very needed verification step. We would like to keep the momentum up, and encourage all to participate. We have also had lots of participation on the mailing list. Thanks to all who contributed, and especially to Geoff Clemm for all the hard work in the specification. Please let me know as soon as possible if you will be able to attend as there isn't much time left to schedule the meeting. If we get 12 or more attendees, I will schedule the meeting. From w3c-dist-auth-request@w3.org Wed Feb 16 04:18:39 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20919 for ; Wed, 16 Feb 2000 04:18:30 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id EAA14016; Wed, 16 Feb 2000 04:13:42 -0500 (EST) Resent-Date: Wed, 16 Feb 2000 04:13:42 -0500 (EST) Resent-Message-Id: <200002160913.EAA14016@www19.w3.org> Date: Wed, 16 Feb 2000 01:12:24 -0800 From: Kevin Wiggen To: w3c-dist-auth@w3.org Message-id: MIME-version: 1.0 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Content-type: text/plain; charset="iso-8859-1" Content-transfer-encoding: 7bit Importance: Normal X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Priority: 3 (Normal) Subject: ETags Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4097 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit I searched the spec and could not find any special details on handling ETags. Should an ETag value be updated when a dead property is changed? On the same note, do most servers update the last-modified-date when a dead property is changed? Does Webdav want to take a stand one way or another? Curious, Kevin From w3c-dist-auth-request@w3.org Wed Feb 16 04:26:53 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20990 for ; Wed, 16 Feb 2000 04:26:34 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id EAA14280; Wed, 16 Feb 2000 04:22:19 -0500 (EST) Resent-Date: Wed, 16 Feb 2000 04:22:19 -0500 (EST) Resent-Message-Id: <200002160922.EAA14280@www19.w3.org> Date: Wed, 16 Feb 2000 01:23:45 -0800 (PST) From: Greg Stein To: Kevin Wiggen cc: w3c-dist-auth@w3.org In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: ETags Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4098 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list On Wed, 16 Feb 2000, Kevin Wiggen wrote: > I searched the spec and could not find any special details on handling > ETags. > > Should an ETag value be updated when a dead property is changed? On the Probably, on the basis that an ETag represents the resource, and the properties are part of the resource. > same note, do most servers update the last-modified-date when a dead > property is changed? mod_dav does not update the last-modified-date. This is stated at http://www.webdav.org/mod_dav/#imp > Does Webdav want to take a stand one way or another? I'd prefer it didn't since it would be rather painful for me to support. But that's just me :-) Cheers, -g -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Wed Feb 16 12:26:07 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07284 for ; Wed, 16 Feb 2000 12:25:54 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA01361; Wed, 16 Feb 2000 12:14:48 -0500 (EST) Resent-Date: Wed, 16 Feb 2000 12:14:48 -0500 (EST) Resent-Message-Id: <200002161714.MAA01361@www19.w3.org> Message-ID: <8E3CFBC709A8D21191A400805F15E0DBD245B0@crte147.wc.eso.mc.xerox.com> From: "Slein, Judith A" To: "'Yaron Goland'" , "'w3c-dist-auth@w3.org'" Date: Wed, 16 Feb 2000 12:11:47 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Yaron.Redirect.NoWebDAV#1 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4099 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list The idea of trying to specify redirect references in such a way that they do not depend on implementation of any other parts of WebDAV is very appealing. As you point out in this and the following 2 comments, we would need to go back to using MKREF (which doesn't have an XML body) instead of the more generic MKRESOURCE and get rid of the DAV:reftarget property in order to make this possible. I would be willing to do both. I just want to be sure that, even though it's not required for a redirect reference to support any other parts of WebDAV, it's permissible for it to do so. If it's also a WebDAV class 1 resource, I would assume its DAV:resourcetype property would have a value DAV:redirectref. It would be possible to set properties on the redirect reference and view properties on the redirect reference using the Apply-To-Redirect-Ref header. Also it is possible to create a redirect reference in a WebDAV-compliant collection, as discussed in Section 7 of the spec. What would we lose by getting rid of DAV:reftarget? 1. Efficiency in certain scenarios, where you are operating on a collection populated with redirect references. You would have to do 2 round trips for each member of the collection instead of getting DAV:reftarget with PROPFIND for all members and addressing requests to the target. 2. Can't search on DAV:reftarget to find all references to a given resource. 3. No relative URIs (the Location header always has absolute URI), so in an environment where references are within a hierarchy that is likely to move, redirects may get broken where they would survive in the current spec. In my view these considerations are outweighed by the possibility of creating and managing redirect references without implementing any other parts of WebDAV. So I'm with you here. Thanks for the great suggestion! --Judy -----Original Message----- From: Yaron Goland [mailto:yarong@Exchange.Microsoft.com] Sent: Friday, February 11, 2000 2:44 AM To: 'w3c-dist-auth@w3.org' Subject: Yaron.Redirect.NoWebDAV#1 The redirect spec requires the use of WebDAV in order to create and query redirect resources as it makes use of the WebDAV property mechanism. However I am having trouble finding a compelling reason to require WebDAV just to implement redirect resources. A redirect resource is, in my opinion, just an enhancement to HTTP/1.1. HTTP/1.1 introduced the concept of a 302 response but did not concurrently introduce the administrative tools necessary in order to specify when a 302 response should be returned. The redirect draft helps to address this deficiency but unless there is a compelling reason to do so, it should address this deficiency in the simplest manner possible, preferably only using the tools provided by HTTP/1.1. The argument has been made that the tools introduced in the redirect draft constitute the first step in a series of additional extensions that will be made in the future. For example, the Delta-V group has certain ideas about how to use MKRESOURCE. While HTTP has a rich tradition of enabling future extensions it has always wisely chosen in the short term to limit itself to immediate needs only while ensuring that future expansion is possible. Hence the test for the redirect draft's success should be only how well it addresses the immediate needs of redirect resources and not how well it addresses the shifting needs of various future proposals. The current functionality of the redirect resource is very simple, specify a resource that, by default, will return a 302 (found) response to a specified target resource. There does not appear to be any compelling reason why the creation of a redirect resource should require anything beyond a single header on the creation request to specify the URI of the target resource. The use of a body to create a redirect resource is clearly unnecessary. This is not to say that it may not prove to be necessary in the future. However WebDAV, in particular, has set a precedent for how to deal with this sort of situation that I believe would well serve the redirect spec. In the COPY/MOVE methods we use a single destination header, rather than a body, to specify where the results of the method are to appear. One can imagine a number of reasons why one would want to have a more powerful way to specify the destination of the method. For example, one might want to specify multiple destination URIs in order to use a single round trip to cause multiple COPY/MOVE's. HTTP's header format is not well suited for this sort of extension and WebDAV's definition of the destination header wisely does not allow for it. Rather WebDAV specifies that a body MAY be included in a COPY/MOVE method but is to be ignored if not understood. This provide for a very powerful extension mechanism. For example, imagine one wanted to issue the COPY/MOVE to multiple destinations but one wasn't sure if the source supported this feature. Rather than wasting a round trip finding out if the source supports the feature one could put a single destination in the destination header and then use the body to specify the rest of the destinations. If the resource supports the extension then all destinations will be COPY/MOVE'd to. If the resource doesn't support the extension then at least one copy will be issued and the client will realize that the rest didn't occur (because the resource ignored the body) through the 207 response. If, on the other hand, one only wanted the COPY/MOVE to proceed if the resource understood the multiple destination extension then the COPY/MOVE could be issued without a destination header, just with a body. Resources that didn't support the extension would fail the request due to the absence of the destination header thus ensuring that only resources that understood the extension will actually execute the method. One could rightfully argue that this is an unnecessary complication. Why not start with a body that allows extension in the first place? The counter argument is that one should always start with as minimal functionality as possibly and only expand, grudgingly, as required. A header is much easier to process than a body and so clearly is the simplest mechanism available. This line of reasoning is especially compelling in the context of redirect resources. Given the obvious utility of redirect resources to all HTTP systems, not just WebDAV, it is incumbent upon the redirect spec to cleave as closely as possible to the base HTTP system and require as few extensions from it as possible. Therefore I believe that the current proposal, which requires the introduction of a full XML processing system just to handle a simple redirect resource is unsupportable. As such I move that whatever design is chosen for creating a redirect resource it MUST NOT include the use of a request body. From w3c-dist-auth-request@w3.org Wed Feb 16 13:11:47 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08786 for ; Wed, 16 Feb 2000 13:11:43 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA03897; Wed, 16 Feb 2000 13:05:39 -0500 (EST) Resent-Date: Wed, 16 Feb 2000 13:05:39 -0500 (EST) Resent-Message-Id: <200002161805.NAA03897@www19.w3.org> Message-ID: <8E3CFBC709A8D21191A400805F15E0DBD245B2@crte147.wc.eso.mc.xerox.com> From: "Slein, Judith A" To: "'Yaron Goland'" , "'w3c-dist-auth@w3.org'" Date: Wed, 16 Feb 2000 13:05:16 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Yaron.Redirect.NoPropsIn207 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4100 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list As long as we provide the location and resource type information somehow, I don't care how. So I'd be fine with adding a location XML element and refresource XML element to the response XML element as you propose. Note that this is already an issue for RFC 2518 (well, at least the need for the location information), since whether or not you can create redirect references, HTTP redirects can be encountered while processing a WebDAV collection. So whatever solution we end up with, it needs eventually to be incorporated into RFC 2518. -----Original Message----- From: Yaron Goland [mailto:yarong@Exchange.Microsoft.com] Sent: Friday, February 11, 2000 2:51 AM To: 'w3c-dist-auth@w3.org' Subject: Yaron.Redirect.NoPropsIn207 The third sentence of the third paragraph of section 7 currently reads: "Since a Location header and Redirect-Ref header cannot be returned for each redirect reference encountered, the same information is provided using properties in the response elements for those resources." As discussed in Yaron.Redirect.NoWebDAV#3 we should not be using WebDAV properties in the redirect draft. Therefore I move that this sentence be changed to read: "Following the conventions of the 207 (Multi-Status) format the equivalent of the redirect-ref and location header are included inside the response body." The fourth sentence of the third paragraph of section 7 currently reads: "The DAV:location pseudo-property and the DAV:resourcetype property MUST be included with the 302 status code." First, the use of a pseudo-property violates the integrity of the prop XML element of a multi-status response. One can today write a general tool that can process any multi-status response and draw property information from it. Such a tool need not even understand the particular context in which the multi-status was generated. The use of a "pseudo-property" violates this integrity be listing a value in a prop element, thereby stating it is a property, when it is in fact not. Second, it is almost always a bad idea to imply information rather than stating it. By requiring that the resourcetype property be included you are expecting that the client will understand that because the response is a 302 and because a Apply-To-Redirect-Ref header was not included and because the resource type is redirect resource therefore this is a blind 302 response. This is a lot of inferring to do. In addition the resourcetype of a resource could potentially be quite large. As such it is generally better to create a dedicated piece of information which states, exclusively and uniquely that the 302 is a blind 302 and leave it at that. As such I move that both the DAV:location "pseudo-property" and the resourcetype property be banned for the uses stated in the above mentioned sentence. I move that location information be returned in a location XML element included in the response XML element. I move that the Redirect-Ref header information be included in a refresource XML element also included in the response XML element. Based on the previous proposals I also move that the previously quoted sentence be changed to read: "The location and refresource XML elements MUST be included with the 302 status code returned in a response XML element in a 207 (Multi-Status) response." The fifth sentence of the third paragraph of section 7 currently reads: "This necessitates an extension to the syntax of the DAV:response element that was defined in [WebDAV]. The extension is defined in Section 14 below." This sentence either states something obvious or unnecessary, I can't figure out which. Regardless, it isn't needed. As such I move that it be deleted. The third paragraph of section 7 is not necessary if my previous proposals in this point are adopted therefore I move that it be deleted. The fourth paragraph of section 7 provides suggestions for future changes to the WebDAV standard. I really dislike language like this as it has no place in a standard. If changes are needed to the base WebDAV specification then put out a posting to the mailing list so they can be added to the issue list for consideration when WebDAV goes to Draft. But please leave them out of the standard. Standards are really not the proper forum for editorializing. As such I move that this paragraph be deleted. Section 7.1 of the specification basically just restates RFC 2518. Rather than clarifying the issue it just confuses the reader by forcing them to ask themselves what was so subtle in understanding the WebDAV spec that this paragraph was necessary. BTW, one should contrast section 7.1 with section 7.2. 7.2 points out a real subtly in the design of WebDAV and redirect resources that needs to be called out to implementers. I do not believe that 7.1 meets the quality bar set by 7.2. Therefore I move that section 7.1 be deleted from the specification. From w3c-dist-auth-request@w3.org Wed Feb 16 13:25:22 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09100 for ; Wed, 16 Feb 2000 13:25:16 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA04768; Wed, 16 Feb 2000 13:18:49 -0500 (EST) Resent-Date: Wed, 16 Feb 2000 13:18:49 -0500 (EST) Resent-Message-Id: <200002161818.NAA04768@www19.w3.org> Message-ID: <8E3CFBC709A8D21191A400805F15E0DBD245B3@crte147.wc.eso.mc.xerox.com> From: "Slein, Judith A" To: "'Yaron Goland'" , "Slein, Judith A" , w3c-dist-auth@w3.org Date: Wed, 16 Feb 2000 13:17:58 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Yaron.Redirect.4th2nd Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4101 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Repeated requests to have one or another method have as its default behavior on a redirect reference to operate automatically on the target resource rather than responding with 302. So it seems worthwhile jumping up and down a bit about the differences between them. --Judy -----Original Message----- From: Yaron Goland [mailto:yarong@Exchange.Microsoft.com] Sent: Monday, February 14, 2000 5:47 PM To: 'Slein, Judith A'; w3c-dist-auth@w3.org Subject: RE: Yaron.Redirect.4th2nd What evidence is available that would lead one to conclude that it would be difficult to grasp redirect references without understanding direct references, especially given that HTTP/1.1 was able to define a redirect without having to reference its direct variant? > -----Original Message----- > From: Slein, Judith A [mailto:JSlein@crt.xerox.com] > Sent: Mon, February 14, 2000 12:31 PM > To: Yaron Goland; w3c-dist-auth@w3.org > Subject: RE: Yaron.Redirect.4th2nd > > > Again, I think a basic understanding of how redirect > references are intended > to differ from direct references is crucial to understanding > the spec. I'm > not wedded to any of the details of the language, though. > > --Judy > > -----Original Message----- > From: Yaron Goland [mailto:yarong@Exchange.Microsoft.com] > Sent: Friday, February 11, 2000 2:42 AM > To: 'w3c-dist-auth@w3.org' > Subject: Yaron.Redirect.4th2nd > > > > The first sentence of the second paragraph of section 4 > reads: "A redirect > reference resource never automatically forwards requests to its target > resource." > > I believe that the word "automatically" is misleading in that > it implies > that if one sends the right header or body the redirect resource might > actually forward the request for you. In addition this > sentence runs afoul > of Yaron.Redirect.Forwarding. As such I move that this > sentence be changed > to read "A redirect resource blindly issues 302 (Found) > redirect responses > point at its target resource." > > The second sentence of the same paragraph reads: "It is this > characteristic > that distinguishes redirect reference resource from direct reference > resources and from bindings." > > The removal of this sentence, consistent with > Yaron.Redirect.NoReferenceorDirectResource, would remove the > only reference > to direct reference resources outside of the terminology > section. Therefore > I move that this entire sentence be removed from the draft. > > The last two sentences of the same paragraph read: "It is > also what insures > that redirect reference resources will be simple to implement and that > cross-server references will be possible. If the redirect reference > resource were required to forward requests automatically, the > server would > need proxy capabilities in order to support cross-server references." > > I found the language confusing and it violated Yaron.Redirect.Servers. > Therefore I move that the language be altered to read: > "Redirect resources > bring the same benefits as links in HTML documents. They can > be created and > maintained without the involvement or even knowledge of their target > resource. This reduces the cost of linking between resources." > From w3c-dist-auth-request@w3.org Wed Feb 16 16:29:55 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14366 for ; Wed, 16 Feb 2000 16:29:48 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA13914; Wed, 16 Feb 2000 16:21:48 -0500 (EST) Resent-Date: Wed, 16 Feb 2000 16:21:48 -0500 (EST) Resent-Message-Id: <200002162121.QAA13914@www19.w3.org> From: Jim Whitehead To: WebDAV WG Date: Wed, 16 Feb 2000 13:16: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.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Subject: RE: ETags Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4102 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit Accidentally caught by the spam filter. - Jim -----Original Message----- From: Douglas Steen [mailto:dsteen@ekeeper.com] Sent: Wednesday, February 16, 2000 6:30 AM To: w3c-dist-auth@w3.org Subject: [Moderator Action] RE: ETags Unfortunately, I am pretty sure that Windows 2K will NOT update the eTag when dead properties change (I haven't checked recent versions, but older ones did not). Although I agree with Greg: it should. I don't know about other WebDAV-enabled servers. Douglas R. Steen dsteen@eKeeper.Com Drag-and-Drop Web Content Management http://www.eKeeper.com -----Original Message----- From: Greg Stein [mailto:gstein@lyra.org] Sent: Wednesday, 16 February, 2000 3:24 AM To: Kevin Wiggen Cc: w3c-dist-auth@w3.org Subject: Re: ETags On Wed, 16 Feb 2000, Kevin Wiggen wrote: > I searched the spec and could not find any special details on handling > ETags. > > Should an ETag value be updated when a dead property is changed? On the Probably, on the basis that an ETag represents the resource, and the properties are part of the resource. > same note, do most servers update the last-modified-date when a dead > property is changed? mod_dav does not update the last-modified-date. This is stated at http://www.webdav.org/mod_dav/#imp > Does Webdav want to take a stand one way or another? I'd prefer it didn't since it would be rather painful for me to support. But that's just me :-) Cheers, -g -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Wed Feb 16 20:03:51 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19362 for ; Wed, 16 Feb 2000 20:03:43 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id TAA24879; Wed, 16 Feb 2000 19:58:59 -0500 (EST) Resent-Date: Wed, 16 Feb 2000 19:58:59 -0500 (EST) Resent-Message-Id: <200002170058.TAA24879@www19.w3.org> From: Jim Whitehead To: WebDAV WG Date: Wed, 16 Feb 2000 16:53:54 -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.2314.1300 Importance: Normal Subject: Binding protocol teleconf minutes - Feb 16 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4103 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit Minutes from the February 16, 2000 binding protocol teleconference are now available off the WebDAV web site, at: http://www.ics.uci.edu/pub/ietf/webdav/collection/dt/Minutes000216.txt - Jim From w3c-dist-auth-request@w3.org Thu Feb 17 15:12:46 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23301 for ; Thu, 17 Feb 2000 15:12:45 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA12522; Thu, 17 Feb 2000 15:08:23 -0500 (EST) Resent-Date: Thu, 17 Feb 2000 15:08:23 -0500 (EST) Resent-Message-Id: <200002172008.PAA12522@www19.w3.org> From: Jim Whitehead To: WebDAV WG Date: Thu, 17 Feb 2000 12:03:11 -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.2314.1300 Importance: Normal Subject: FW: [Moderator Action] RE: ETags Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4104 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit Accidentally caught by the spam filter. - Jim -----Original Message----- From: Clemm, Geoff [mailto:gclemm@rational.com] Sent: Wednesday, February 16, 2000 7:56 PM To: w3c-dist-auth@w3.org Subject: [Moderator Action] RE: ETags A good reason to not change the etag or mod-date when a property changes is that a property is often information about the resource, as opposed to "being" the resource. If I mark a resource as being "tested", I don't want it to appear that the resource has changed (thus making it look like I need to test it again). A less compelling reason (but still a consideration) is to achieve consistency between dead and live properties. You certainly don't want a change to the "last access time" of a resource to modify the etag or "modification time" of that resource. Add to this the fact that current implementations appear to not modify the etag or modification time when a dead property is modified, and I think we have a pretty case that neither the etag value nor the modification time should be changed when a dead property is updated. Cheers, Geoff > -----Original Message----- > From: Kevin Wiggen [mailto:wiggs@xythos.com] > Sent: Wednesday, February 16, 2000 4:12 AM > To: w3c-dist-auth@w3.org > Subject: ETags > > > > I searched the spec and could not find any special details on handling > ETags. > > Should an ETag value be updated when a dead property is > changed? On the > same note, do most servers update the last-modified-date when a dead > property is changed? Does Webdav want to take a stand one > way or another? > > > Curious, > Kevin > From w3c-dist-auth-request@w3.org Thu Feb 17 15:21:25 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23542 for ; Thu, 17 Feb 2000 15:21:23 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA12879; Thu, 17 Feb 2000 15:17:14 -0500 (EST) Resent-Date: Thu, 17 Feb 2000 15:17:14 -0500 (EST) Resent-Message-Id: <200002172017.PAA12879@www19.w3.org> Date: Thu, 17 Feb 2000 12:18:43 -0800 (PST) From: Greg Stein To: WebDAV WG In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: ETags Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4105 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Sounds good. Maybe we can include in the 2518 update language something like this: "Adding, changing, or removing a property MAY alter the DAV:getlastmodified property." In other words, don't rely on it happening, but also don't rely on it NOT happening. (note that I don't discriminate between live/dead props) Cheers, -g > -----Original Message----- > From: Clemm, Geoff [mailto:gclemm@rational.com] > Sent: Wednesday, February 16, 2000 7:56 PM > To: w3c-dist-auth@w3.org > Subject: [Moderator Action] RE: ETags > > > A good reason to not change the etag or mod-date when a property changes > is that a property is often information about the resource, as opposed to > "being" the resource. If I mark a resource as being "tested", I don't want > it to appear that the resource has changed (thus making it look like I need > to test it again). > A less compelling reason (but still a consideration) is to achieve > consistency > between dead and live properties. You certainly don't want a change to the > "last access time" of a resource to modify the etag or "modification time" > of > that resource. > Add to this the fact that current implementations appear to not modify the > etag or > modification time when a dead property is modified, and I think we have a > pretty > case that neither the etag value nor the modification time should > be changed when a dead property is updated. > > Cheers, > Geoff > > > -----Original Message----- > > From: Kevin Wiggen [mailto:wiggs@xythos.com] > > Sent: Wednesday, February 16, 2000 4:12 AM > > To: w3c-dist-auth@w3.org > > Subject: ETags > > > > > > > > I searched the spec and could not find any special details on handling > > ETags. > > > > Should an ETag value be updated when a dead property is > > changed? On the > > same note, do most servers update the last-modified-date when a dead > > property is changed? Does Webdav want to take a stand one > > way or another? > > > > > > Curious, > > Kevin > > > -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Thu Feb 17 15:53:11 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24283 for ; Thu, 17 Feb 2000 15:53:11 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA14112; Thu, 17 Feb 2000 15:49:00 -0500 (EST) Resent-Date: Thu, 17 Feb 2000 15:49:00 -0500 (EST) Resent-Message-Id: <200002172049.PAA14112@www19.w3.org> Date: Thu, 17 Feb 2000 12:42:33 -0800 From: Kevin Wiggen In-reply-to: To: Jim Whitehead , WebDAV WG Message-id: MIME-version: 1.0 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Content-type: text/plain; charset="iso-8859-1" Content-transfer-encoding: 7bit Importance: Normal X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Priority: 3 (Normal) Subject: RE: ETags Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4106 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit I could probably make up just as compelling reasons why the ETag and Last-Modified-Date SHOULD change during a update of a dead property etc. But I agree that it seems that no other server can (or is) supporting this. I can pull this functionality out of Xythos. I just read Greg's email, and I don't like putting the MAY in the spec. A client will never know what the server is doing. I think we just need to pick a position and put it in 2518. I am fine with changing properties does not modify the ETag or Last-Modified-Date. But I think we should be consistent. Kevin -----Original Message----- From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jim Whitehead Sent: Thursday, February 17, 2000 12:03 PM To: WebDAV WG Subject: FW: [Moderator Action] RE: ETags Accidentally caught by the spam filter. - Jim -----Original Message----- From: Clemm, Geoff [mailto:gclemm@rational.com] Sent: Wednesday, February 16, 2000 7:56 PM To: w3c-dist-auth@w3.org Subject: [Moderator Action] RE: ETags A good reason to not change the etag or mod-date when a property changes is that a property is often information about the resource, as opposed to "being" the resource. If I mark a resource as being "tested", I don't want it to appear that the resource has changed (thus making it look like I need to test it again). A less compelling reason (but still a consideration) is to achieve consistency between dead and live properties. You certainly don't want a change to the "last access time" of a resource to modify the etag or "modification time" of that resource. Add to this the fact that current implementations appear to not modify the etag or modification time when a dead property is modified, and I think we have a pretty case that neither the etag value nor the modification time should be changed when a dead property is updated. Cheers, Geoff > -----Original Message----- > From: Kevin Wiggen [mailto:wiggs@xythos.com] > Sent: Wednesday, February 16, 2000 4:12 AM > To: w3c-dist-auth@w3.org > Subject: ETags > > > > I searched the spec and could not find any special details on handling > ETags. > > Should an ETag value be updated when a dead property is > changed? On the > same note, do most servers update the last-modified-date when a dead > property is changed? Does Webdav want to take a stand one > way or another? > > > Curious, > Kevin > From w3c-dist-auth-request@w3.org Thu Feb 17 17:31:28 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26565 for ; Thu, 17 Feb 2000 17:31:25 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA17898; Thu, 17 Feb 2000 17:26:56 -0500 (EST) Resent-Date: Thu, 17 Feb 2000 17:26:56 -0500 (EST) Resent-Message-Id: <200002172226.RAA17898@www19.w3.org> From: Jim Whitehead To: WebDAV WG Date: Thu, 17 Feb 2000 14:21:49 -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) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Subject: FW: [Moderator Action] RE: ETags Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4107 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit Accidentally caught by the spam filter. - Jim -----Original Message----- From: Douglas Steen [mailto:dsteen@ekeeper.com] Sent: Thursday, February 17, 2000 12:56 PM To: WebDAV WG Subject: [Moderator Action] RE: ETags We've got two issues here: 1) Should property updates change the mod-date? 2) Should property updates change the e-tag? Re #1: > A less compelling reason (but still a consideration) is to achieve > consistency between dead and live properties. You certainly don't want a change > to the "last access time" of a resource to modify the etag or "modification time" > of that resource. Agreed. Re #2: > A good reason to not change the etag or mod-date when a property changes > is that a property is often information about the resource, as opposed to > "being" the resource. If I mark a resource as being "tested", I don't want > it to appear that the resource has changed (thus making it look like I need > to test it again). I disagree. If you mark a resource as 'tested', it is a different entity than the one not marked as 'tested'. If we're doing any sort of collaboration, I would not want my unmarked file (& props) to overwrite your marked file (& props) because my application mistakenly thinks that these entities are the same. Furthermore, what about null resources (i.e. simple collections of properties)? If a property change doesn't indicate a new entity, then there's no point in even having an e-tag -- all entities are the same. Douglas R. Steen dsteen@eKeeper.Com Drag-and-Drop Web Content Management http://www.eKeeper.com -----Original Message----- From: Greg Stein [mailto:gstein@lyra.org] Sent: Thursday, 17 February, 2000 2:19 PM To: WebDAV WG Subject: Re: ETags Sounds good. Maybe we can include in the 2518 update language something like this: "Adding, changing, or removing a property MAY alter the DAV:getlastmodified property." In other words, don't rely on it happening, but also don't rely on it NOT happening. (note that I don't discriminate between live/dead props) Cheers, -g > -----Original Message----- > From: Clemm, Geoff [mailto:gclemm@rational.com] > Sent: Wednesday, February 16, 2000 7:56 PM > To: w3c-dist-auth@w3.org > Subject: [Moderator Action] RE: ETags > > > A good reason to not change the etag or mod-date when a property changes > is that a property is often information about the resource, as opposed to > "being" the resource. If I mark a resource as being "tested", I don't want > it to appear that the resource has changed (thus making it look like I need > to test it again). > A less compelling reason (but still a consideration) is to achieve > consistency > between dead and live properties. You certainly don't want a change to the > "last access time" of a resource to modify the etag or "modification time" > of > that resource. > Add to this the fact that current implementations appear to not modify the > etag or > modification time when a dead property is modified, and I think we have a > pretty > case that neither the etag value nor the modification time should > be changed when a dead property is updated. > > Cheers, > Geoff > > > -----Original Message----- > > From: Kevin Wiggen [mailto:wiggs@xythos.com] > > Sent: Wednesday, February 16, 2000 4:12 AM > > To: w3c-dist-auth@w3.org > > Subject: ETags > > > > > > > > I searched the spec and could not find any special details on handling > > ETags. > > > > Should an ETag value be updated when a dead property is > > changed? On the > > same note, do most servers update the last-modified-date when a dead > > property is changed? Does Webdav want to take a stand one > > way or another? > > > > > > Curious, > > Kevin > > > -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Thu Feb 17 17:31:56 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26579 for ; Thu, 17 Feb 2000 17:31:53 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA17941; Thu, 17 Feb 2000 17:27:36 -0500 (EST) Resent-Date: Thu, 17 Feb 2000 17:27:36 -0500 (EST) Resent-Message-Id: <200002172227.RAA17941@www19.w3.org> From: Jim Whitehead To: WebDAV WG Date: Thu, 17 Feb 2000 14:22:32 -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) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Subject: FW: [Moderator Action] RE: ETags Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4108 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit Accidentally caught by the spam filter. (Yes, I am working on adding Douglas to the accept2 list! :-) - Jim -----Original Message----- From: Douglas Steen [mailto:dsteen@ekeeper.com] Sent: Thursday, February 17, 2000 1:13 PM To: WebDAV WG Subject: [Moderator Action] RE: ETags My vote: #1) Changing properties MUST change the e-tag #2) Changing properties MUST NOT change the last-mod-date If you consider the last-mod-date to be the last time the FILE was modified, then this would imply that dead properties ARE part of the entity, but NOT part of the file. By extension, the last-mod-date of a null resource would be inconsequential, but the e-tag of a null resource would not be. Douglas R. Steen dsteen@eKeeper.Com Drag-and-Drop Web Content Management http://www.eKeeper.com -----Original Message----- From: Kevin Wiggen [mailto:wiggs@wiggenout.com] Sent: Thursday, 17 February, 2000 2:43 PM To: Jim Whitehead; WebDAV WG Subject: RE: ETags I could probably make up just as compelling reasons why the ETag and Last-Modified-Date SHOULD change during a update of a dead property etc. But I agree that it seems that no other server can (or is) supporting this. I can pull this functionality out of Xythos. I just read Greg's email, and I don't like putting the MAY in the spec. A client will never know what the server is doing. I think we just need to pick a position and put it in 2518. I am fine with changing properties does not modify the ETag or Last-Modified-Date. But I think we should be consistent. Kevin -----Original Message----- From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jim Whitehead Sent: Thursday, February 17, 2000 12:03 PM To: WebDAV WG Subject: FW: [Moderator Action] RE: ETags Accidentally caught by the spam filter. - Jim -----Original Message----- From: Clemm, Geoff [mailto:gclemm@rational.com] Sent: Wednesday, February 16, 2000 7:56 PM To: w3c-dist-auth@w3.org Subject: [Moderator Action] RE: ETags A good reason to not change the etag or mod-date when a property changes is that a property is often information about the resource, as opposed to "being" the resource. If I mark a resource as being "tested", I don't want it to appear that the resource has changed (thus making it look like I need to test it again). A less compelling reason (but still a consideration) is to achieve consistency between dead and live properties. You certainly don't want a change to the "last access time" of a resource to modify the etag or "modification time" of that resource. Add to this the fact that current implementations appear to not modify the etag or modification time when a dead property is modified, and I think we have a pretty case that neither the etag value nor the modification time should be changed when a dead property is updated. Cheers, Geoff > -----Original Message----- > From: Kevin Wiggen [mailto:wiggs@xythos.com] > Sent: Wednesday, February 16, 2000 4:12 AM > To: w3c-dist-auth@w3.org > Subject: ETags > > > > I searched the spec and could not find any special details on handling > ETags. > > Should an ETag value be updated when a dead property is > changed? On the > same note, do most servers update the last-modified-date when a dead > property is changed? Does Webdav want to take a stand one > way or another? > > > Curious, > Kevin > From w3c-dist-auth-request@w3.org Thu Feb 17 17:32:51 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26603 for ; Thu, 17 Feb 2000 17:32:50 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA17980; Thu, 17 Feb 2000 17:28:32 -0500 (EST) Resent-Date: Thu, 17 Feb 2000 17:28:32 -0500 (EST) Resent-Message-Id: <200002172228.RAA17980@www19.w3.org> Date: Thu, 17 Feb 2000 14:30:10 -0800 (PST) From: Greg Stein To: WebDAV WG In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: RE: ETags Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4109 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list I think that we have to say MAY. Consider the case where properties are stored as part of a multi-stream file (NTFS or MacOS's HFS). I bet the date will change when you store a property. While reasonable to state that the server implementation is required to restore the modification date to the original (before storing the property), I think that is getting into dangerous territory. What if your backup solution is using the modification time to backup that multi-stream file? Or maybe there is another storage mechanism where a server couldn't restore the date(!). Putting a MAY into the spec is fine. Yes, the client won't know what the server is going to do, but that isn't that big of a deal. For most of the live properties, the client won't always know what will happen when they touch the resource. Cheers, -g On Thu, 17 Feb 2000, Kevin Wiggen wrote: > I could probably make up just as compelling reasons why the ETag and > Last-Modified-Date SHOULD change during a update of a dead property etc. > > But > > I agree that it seems that no other server can (or is) supporting this. I > can pull this functionality out of Xythos. > > I just read Greg's email, and I don't like putting the MAY in the spec. A > client will never know what the server is doing. I think we just need to > pick a position and put it in 2518. > > I am fine with changing properties does not modify the ETag or > Last-Modified-Date. But I think we should be consistent. > > Kevin > > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jim Whitehead > Sent: Thursday, February 17, 2000 12:03 PM > To: WebDAV WG > Subject: FW: [Moderator Action] RE: ETags > > > Accidentally caught by the spam filter. > > - Jim > > -----Original Message----- > From: Clemm, Geoff [mailto:gclemm@rational.com] > Sent: Wednesday, February 16, 2000 7:56 PM > To: w3c-dist-auth@w3.org > Subject: [Moderator Action] RE: ETags > > > A good reason to not change the etag or mod-date when a property changes > is that a property is often information about the resource, as opposed to > "being" the resource. If I mark a resource as being "tested", I don't want > it to appear that the resource has changed (thus making it look like I need > to test it again). > A less compelling reason (but still a consideration) is to achieve > consistency > between dead and live properties. You certainly don't want a change to the > "last access time" of a resource to modify the etag or "modification time" > of > that resource. > Add to this the fact that current implementations appear to not modify the > etag or > modification time when a dead property is modified, and I think we have a > pretty > case that neither the etag value nor the modification time should > be changed when a dead property is updated. > > Cheers, > Geoff > > > -----Original Message----- > > From: Kevin Wiggen [mailto:wiggs@xythos.com] > > Sent: Wednesday, February 16, 2000 4:12 AM > > To: w3c-dist-auth@w3.org > > Subject: ETags > > > > > > > > I searched the spec and could not find any special details on handling > > ETags. > > > > Should an ETag value be updated when a dead property is > > changed? On the > > same note, do most servers update the last-modified-date when a dead > > property is changed? Does Webdav want to take a stand one > > way or another? > > > > > > Curious, > > Kevin > > > -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Thu Feb 17 19:03:58 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27843 for ; Thu, 17 Feb 2000 19:03:57 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAA22665; Thu, 17 Feb 2000 18:59:51 -0500 (EST) Resent-Date: Thu, 17 Feb 2000 18:59:51 -0500 (EST) Resent-Message-Id: <200002172359.SAA22665@www19.w3.org> Message-ID: <024401bf79a3$44da71a0$ab171990@us.oracle.com> From: "Eric Sedlar" To: "Greg Stein" , "WebDAV WG" References: Date: Thu, 17 Feb 2000 16:01:11 -0800 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.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Subject: Re: ETags Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4110 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit Given that most filesystems allow you to update the modification date directly whenever you want, I think the MAY language is fine. Using the modification date is always based on convention, for this reason. However, if I had to choose, I would say updating a property SHOULD change the modification date. The properties should be considered part of the resource entity. Otherwise, for example, would the ACL for a resource not apply to the properties, if they are not part of the resource entity? Would you have a second ACL restricting access to the properties, separate from the ACL for the resource data itself? The implications of the properties NOT being part of the resource entity gets too yucky. Perhaps WebDAV should RECOMMEND that the modification date be updated when properties are updated, to set the convention, but not require it. --Eric ----- Original Message ----- From: Greg Stein To: WebDAV WG Sent: Thursday, February 17, 2000 2:30 PM Subject: RE: ETags > I think that we have to say MAY. Consider the case where properties are > stored as part of a multi-stream file (NTFS or MacOS's HFS). I bet the > date will change when you store a property. While reasonable to state that > the server implementation is required to restore the modification date to > the original (before storing the property), I think that is getting into > dangerous territory. What if your backup solution is using the > modification time to backup that multi-stream file? Or maybe there is > another storage mechanism where a server couldn't restore the date(!). > > Putting a MAY into the spec is fine. Yes, the client won't know what the > server is going to do, but that isn't that big of a deal. For most of the > live properties, the client won't always know what will happen when they > touch the resource. > > Cheers, > -g > > On Thu, 17 Feb 2000, Kevin Wiggen wrote: > > I could probably make up just as compelling reasons why the ETag and > > Last-Modified-Date SHOULD change during a update of a dead property etc. > > > > But > > > > I agree that it seems that no other server can (or is) supporting this. I > > can pull this functionality out of Xythos. > > > > I just read Greg's email, and I don't like putting the MAY in the spec. A > > client will never know what the server is doing. I think we just need to > > pick a position and put it in 2518. > > > > I am fine with changing properties does not modify the ETag or > > Last-Modified-Date. But I think we should be consistent. > > > > Kevin > > > > -----Original Message----- > > From: w3c-dist-auth-request@w3.org > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jim Whitehead > > Sent: Thursday, February 17, 2000 12:03 PM > > To: WebDAV WG > > Subject: FW: [Moderator Action] RE: ETags > > > > > > Accidentally caught by the spam filter. > > > > - Jim > > > > -----Original Message----- > > From: Clemm, Geoff [mailto:gclemm@rational.com] > > Sent: Wednesday, February 16, 2000 7:56 PM > > To: w3c-dist-auth@w3.org > > Subject: [Moderator Action] RE: ETags > > > > > > A good reason to not change the etag or mod-date when a property changes > > is that a property is often information about the resource, as opposed to > > "being" the resource. If I mark a resource as being "tested", I don't want > > it to appear that the resource has changed (thus making it look like I need > > to test it again). > > A less compelling reason (but still a consideration) is to achieve > > consistency > > between dead and live properties. You certainly don't want a change to the > > "last access time" of a resource to modify the etag or "modification time" > > of > > that resource. > > Add to this the fact that current implementations appear to not modify the > > etag or > > modification time when a dead property is modified, and I think we have a > > pretty > > case that neither the etag value nor the modification time should > > be changed when a dead property is updated. > > > > Cheers, > > Geoff > > > > > -----Original Message----- > > > From: Kevin Wiggen [mailto:wiggs@xythos.com] > > > Sent: Wednesday, February 16, 2000 4:12 AM > > > To: w3c-dist-auth@w3.org > > > Subject: ETags > > > > > > > > > > > > I searched the spec and could not find any special details on handling > > > ETags. > > > > > > Should an ETag value be updated when a dead property is > > > changed? On the > > > same note, do most servers update the last-modified-date when a dead > > > property is changed? Does Webdav want to take a stand one > > > way or another? > > > > > > > > > Curious, > > > Kevin > > > > > > > -- > Greg Stein, http://www.lyra.org/ > > From w3c-dist-auth-request@w3.org Thu Feb 17 19:53:57 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28339 for ; Thu, 17 Feb 2000 19:53:54 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id TAA24010; Thu, 17 Feb 2000 19:39:06 -0500 (EST) Resent-Date: Thu, 17 Feb 2000 19:39:06 -0500 (EST) Resent-Message-Id: <200002180039.TAA24010@www19.w3.org> Message-ID: <028301bf79a8$cd5faf90$ab171990@us.oracle.com> From: "Eric Sedlar" To: Date: Thu, 17 Feb 2000 16:40:49 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0280_01BF7965.BF0EA8D0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Subject: comments on ACLs Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4111 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_0280_01BF7965.BF0EA8D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable A first pass of comments on the ACL spec: * are ACLs resources? Can they be resources in some implementations? I = can see where versioning them separately might be useful, especially in = the case where I'm dynamically inheriting an ACL--I might want to select = an ACL version separately from the resource that is the source of the = ACL inheritance. I think they probably should be. * should we define some notion of a rights bundle? It would be nice to = see a nice directory listing where I could see a simple summary of what = stuff I have rights to, and I think users will want summarize rights = frequently. E.g. I define a rights bundle that gives writeowner & = writeacl rights as a group. This could help simplify things. =20 * is this a typo in the definition of the "writeowner" right (section = 6.7) --=20 The writeowner right controls the ability to change the value = of the owner right There is no "owner" right, just an "owner" property * why isn't PROPFIND used to list the ACL property (and subproperties) = for a resource? This seems totally inconsistent, since you call ACLs a = property. In general, I think I will want to get ACL information as = well as other properties about a resource, and I will want to get them = in a single request. I have no problem with the ACL method being used to update ACL = properties rather than PROPPATCH, however, although I can see a case for = using PROPPATCH in this instance. * the following text makes no sense to me (Introduction--section 1): "Properties on a resource, by default, dynamically inherit from the ACL on the resource. In other words, the resource is the ACL source for the properties" What you mean to say is that by default, the ACL controls (the big C in = ACL) access to all of the properties of a resource, but that an ACL can = be used to control access to individual properties in the resource as = well. While on this topic, I think per-property ACLs are: * incredibly expensive to maintain * create an overwhelming amount of data for users to process What is generally desired when restricting access below the object (or = resource level) is the ability to subdivide the properties of a resource = into separate sets, with an ACL for each set. If the XML used for = sub-resource ACLs looked something like: Classified ... ... ... Top Secret ... ... ... =20 I think users & implementers would understand what is going on better, = and be steered toward simpler implementations. * Why do we need rights like "writeowner" when you can define a separate = ACL for the owner property if you want, and use the regular "write" = permission --Eric ------=_NextPart_000_0280_01BF7965.BF0EA8D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
A first pass of comments on the = ACL=20 spec:
 
* are ACLs resources?  Can they be = resources=20 in some implementations?  I can see where versioning them=20 separately might be useful, especially in the case where I'm = dynamically=20 inheriting an ACL--I might want to select an ACL version separately from = the=20 resource that is the source of the ACL inheritance.  I think they = probably=20 should be.
 
* should we define some notion of a = rights=20 bundle?  It would be nice to see a nice directory listing where I = could see=20 a simple summary of what stuff I have rights to, and I think users will = want=20 summarize rights frequently.  E.g. I define a rights bundle that = gives=20 writeowner & writeacl rights as a group.  This could help = simplify=20 things.
 
* is this a typo in the definition of = the=20 "writeowner" right (section 6.7) --
  <aclspec>The writeowner = right controls=20 the ability to change the value of the owner = right</aclspec>
 
  There is no "owner" right, just = an "owner"=20 property
 
* why isn't PROPFIND used to list the = ACL property=20 (and subproperties) for a resource?  This seems totally = inconsistent, since=20 you call ACLs a property.  In general, I think I will want to get = ACL=20 information as well as other properties about a resource, and I will = want to get=20 them in a single request.
 
I have no problem with the ACL method = being used to=20 update ACL properties rather than PROPPATCH, however, although I can see = a case=20 for using PROPPATCH in this instance.
 
* the following text makes no sense to = me=20 (Introduction--section 1):
 
"Properties on a resource, by default, = dynamically=20 inherit from the
   ACL on the resource. In other words, = the=20 resource is the ACL source
   for the = properties"
 
What you mean to say is that by = default, the ACL=20 controls (the big C in ACL) access to all of the properties of a = resource, but=20 that an ACL can be used to control access to individual properties in = the=20 resource as well.
 
While on this topic, I think = per-property ACLs=20 are:
 
* incredibly expensive to = maintain
* create an overwhelming amount of data = for users=20 to process
 
What is generally desired when = restricting access=20 below the object (or resource level) is the ability to subdivide the = properties=20 of a resource into separate sets, with an ACL for each set.  If the = XML=20 used for sub-resource ACLs looked something like:
 
<acl>
 =20 <d:displayname>Classified</d:displayname>
  = <ace>...</ace>
  = <ace>...</ace>
  <applies-to = prop=3D"foo"/>
  <applies-to = prop=3D"bar"/>
  ...
</acl>
 <acl>
  <d:displayname>Top=20 Secret</displayname>
  = <ace>...</ace>
  = <ace>...</ace>
  <applies-to=20 prop=3D"default"/>
  ...
</acl>
I think users & implementers would understand what is going on = better,=20 and be steered toward simpler implementations.
 
* Why do we need rights like "writeowner" when you can define a = separate=20 ACL for the owner property if you want, and use the regular "write"=20 permission
 
--Eric
 
------=_NextPart_000_0280_01BF7965.BF0EA8D0-- From w3c-dist-auth-request@w3.org Thu Feb 17 19:54:37 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28356 for ; Thu, 17 Feb 2000 19:54:37 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id TAA24221; Thu, 17 Feb 2000 19:41:09 -0500 (EST) Resent-Date: Thu, 17 Feb 2000 19:41:09 -0500 (EST) Resent-Message-Id: <200002180041.TAA24221@www19.w3.org> Message-ID: <028a01bf79a9$15c2b8e0$ab171990@us.oracle.com> From: "Eric Sedlar" To: References: <7DE119D3D0E15543874F7561EECBDBED0261A170@BEG.platinum.corp.microsoft.com> Date: Thu, 17 Feb 2000 16:42:47 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0287_01BF7966.05BB0170" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Subject: Re: Yaron.Redirect.NoAutoUpdate Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4112 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_0287_01BF7966.05BB0170 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Yaron, just to be clear, is it your position that if you wanted this = cool AutoUpdate feature (which I'm a big fan of as way to stop whining = when you disallow cyclic bindings), you need a type of binding (i.e. a = weak binding) rather than a redirect reference? --Eric ------=_NextPart_000_0287_01BF7966.05BB0170 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Yaron, just to be clear, is it your = position that=20 if you wanted this cool AutoUpdate feature (which I'm a big fan of as = way to=20 stop whining when you disallow cyclic bindings), you need a type of = binding=20 (i.e. a weak binding) rather than a redirect reference?
 
--Eric
 
------=_NextPart_000_0287_01BF7966.05BB0170-- From w3c-dist-auth-request@w3.org Thu Feb 17 20:04:21 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28521 for ; Thu, 17 Feb 2000 20:04:20 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id TAA24940; Thu, 17 Feb 2000 19:48:58 -0500 (EST) Resent-Date: Thu, 17 Feb 2000 19:48:58 -0500 (EST) Resent-Message-Id: <200002180048.TAA24940@www19.w3.org> Message-ID: <7DE119D3D0E15543874F7561EECBDBED0261A197@BEG.platinum.corp.microsoft.com> From: Yaron Goland To: "W3c-Dist-Auth (E-mail)" Date: Thu, 17 Feb 2000 16:47:52 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: The WebDAV Book of Why - V. Alpha 3 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4113 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list The WebDAV Book of Why V.Alpha 3 - 2/17/2000 2:39 PM 1 Introduction This is my personal collection of posts from the WebDAV mailing list. I use this collection to save me time in answering questions about the design of the WebDAV distributed authoring standard. In here you will find answers to everything you ever wanted to know, but were wise enough not to ask, about how WebDAV ended up the way it did. Many of these papers contain histories of how various features were developed. Almost all the histories are wrong. The reason they are wrong is that: a) I have a lousy memory b) I didn't bother to actually research my answers c) All of the above On the other hand I have been reviewing some of the old drafts, meeting notes and mailing lists and there is quite a story in there. Did you know that WebDAV was originally written to use POST? That WebDAV had support for fully distributed searching and eventing? We have all the drafts, all the meeting notes and the entire mail archive. I'm sure there is a researcher out there who would just love to dive in to a fully documented history of the development of a protocol. For more information please contact Jim Whitehead, chief librarian and head researcher of the WebDAV archives. Disclaimer: Nothing said here is official, binding, normative, a standard or representative of working group consensus. The official history of the working group is contained in the meeting minutes, the mailing list and the untold drafts the working group produced. The final word on all standards issues is the RFC and failing that, working group consensus. 2 Changes This is the third Alpha release of this reference. The following new articles were added: Why are WebDAV's XML namespace rules different than the W3C's? If you are going to write WebDAV Standards - PLEASE READ THIS Thoughts on writing standards that real clients can support or "why the server can just say no" philosophy doesn't work Why IDs need to be Opaque Tokens Why IE's Web Folders are accessed through File/Open The following article Was Removed: Versioning, Collections and Sources 3 Index 3.1 Properties A History of WebDAV's Property Design - An explanation of WebDAV's property design, in the form of a fairy tale. The DAV Property/Message Object Model - Explains the relationship of WebDAV to XML HTTP Design Issues, lessons from WebDAV's Property and Depth header experiences - Learn from our mistakes in WebDAV, read this if you are going to write application protocols Ramifications of WebDAV's property design decisions - This post explores the screw ups we made in the WebDAV property design. 3.2 XML Why are WebDAV's XML namespace rules different than the W3C's? How WebDAV Uses the Value argument in defining XML elements XML Attributes and the WebDAV object model - Why WebDAV doesn't use XML attributes 3.3 COPY/MOVE COPY and Methods - Discusses all aspects of COPY's behavior but how it deals with properties. COPY and Properties - Focuses in on explaining COPY's behavior with properties. Why MOVE isn't really defined as a COPY followed by a DELETE Why MOVE Eats Write Locks 3.4 Odds and Ends Collections, Resourcetype and Hierarchy in WebDAV - Explains the reasoning behind the design of collections and how they interact with the namespace, how hierarchy works, etc. This one is really long but touches on an enormous number of topics. Whatever Happened to the Destroy Header and the UNDELETE method? Why Multi-Status is a 2xx Response 3.5 Useful Design Heuristics When to Use the Header vs. the Body for Method Arguments If you are going to write WebDAV Standards - PLEASE READ THIS - Explains how to structure early drafts so as to get maximum consensus in the shortest period of time. Thoughts on writing standards that real clients can support or "why the server can just say no" philosophy doesn't work 3.6 General Philosophy Levels of HTTP Nirvana or POST Vs. New Methods Why IDs need to be Opaque Tokens - This paper explains, in gory detail, why URL Munging is a really bad idea. Why IE's Web Folders are accessed through File/Open - Ever wonder how Microsoft designs UI? From w3c-dist-auth-request@w3.org Fri Feb 18 13:42:11 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28891 for ; Fri, 18 Feb 2000 13:42:11 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA20520; Fri, 18 Feb 2000 13:38:03 -0500 (EST) Resent-Date: Fri, 18 Feb 2000 13:38:03 -0500 (EST) Resent-Message-Id: <200002181838.NAA20520@www19.w3.org> From: Jim Whitehead To: WebDAV WG Date: Fri, 18 Feb 2000 10:32:59 -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) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Subject: FW: [Moderator Action] RE: ETags Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4115 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit Accidentally caught by the spam filter -- but, I've now added Douglas to the accept2 list! :-) - Jim -----Original Message----- From: Douglas Steen [mailto:dsteen@ekeeper.com] Sent: Thursday, February 17, 2000 2:39 PM To: WebDAV WG Subject: [Moderator Action] RE: ETags Sounds reasonable for the last-mod-date, but can we still do a MUST for the e-tags? Douglas R. Steen dsteen@eKeeper.Com Drag-and-Drop Web Content Management http://www.eKeeper.com -----Original Message----- From: Greg Stein [mailto:gstein@lyra.org] Sent: Thursday, 17 February, 2000 4:30 PM To: WebDAV WG Subject: RE: ETags I think that we have to say MAY. Consider the case where properties are stored as part of a multi-stream file (NTFS or MacOS's HFS). I bet the date will change when you store a property. While reasonable to state that the server implementation is required to restore the modification date to the original (before storing the property), I think that is getting into dangerous territory. What if your backup solution is using the modification time to backup that multi-stream file? Or maybe there is another storage mechanism where a server couldn't restore the date(!). Putting a MAY into the spec is fine. Yes, the client won't know what the server is going to do, but that isn't that big of a deal. For most of the live properties, the client won't always know what will happen when they touch the resource. Cheers, -g On Thu, 17 Feb 2000, Kevin Wiggen wrote: > I could probably make up just as compelling reasons why the ETag and > Last-Modified-Date SHOULD change during a update of a dead property etc. > > But > > I agree that it seems that no other server can (or is) supporting this. I > can pull this functionality out of Xythos. > > I just read Greg's email, and I don't like putting the MAY in the spec. A > client will never know what the server is doing. I think we just need to > pick a position and put it in 2518. > > I am fine with changing properties does not modify the ETag or > Last-Modified-Date. But I think we should be consistent. > > Kevin > > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jim Whitehead > Sent: Thursday, February 17, 2000 12:03 PM > To: WebDAV WG > Subject: FW: [Moderator Action] RE: ETags > > > Accidentally caught by the spam filter. > > - Jim > > -----Original Message----- > From: Clemm, Geoff [mailto:gclemm@rational.com] > Sent: Wednesday, February 16, 2000 7:56 PM > To: w3c-dist-auth@w3.org > Subject: [Moderator Action] RE: ETags > > > A good reason to not change the etag or mod-date when a property changes > is that a property is often information about the resource, as opposed to > "being" the resource. If I mark a resource as being "tested", I don't want > it to appear that the resource has changed (thus making it look like I need > to test it again). > A less compelling reason (but still a consideration) is to achieve > consistency > between dead and live properties. You certainly don't want a change to the > "last access time" of a resource to modify the etag or "modification time" > of > that resource. > Add to this the fact that current implementations appear to not modify the > etag or > modification time when a dead property is modified, and I think we have a > pretty > case that neither the etag value nor the modification time should > be changed when a dead property is updated. > > Cheers, > Geoff > > > -----Original Message----- > > From: Kevin Wiggen [mailto:wiggs@xythos.com] > > Sent: Wednesday, February 16, 2000 4:12 AM > > To: w3c-dist-auth@w3.org > > Subject: ETags > > > > > > > > I searched the spec and could not find any special details on handling > > ETags. > > > > Should an ETag value be updated when a dead property is > > changed? On the > > same note, do most servers update the last-modified-date when a dead > > property is changed? Does Webdav want to take a stand one > > way or another? > > > > > > Curious, > > Kevin > > > -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Fri Feb 18 13:42:27 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28907 for ; Fri, 18 Feb 2000 13:42:27 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA20481; Fri, 18 Feb 2000 13:37:22 -0500 (EST) Resent-Date: Fri, 18 Feb 2000 13:37:22 -0500 (EST) Resent-Message-Id: <200002181837.NAA20481@www19.w3.org> From: Jim Whitehead To: WebDAV WG Date: Fri, 18 Feb 2000 10:32: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.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Subject: FW: [Moderator Action] RE: ETags Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4114 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit Accidentally caught by the spam filter. I've added gclemm@rational.com to the accept2 list. - Jim -----Original Message----- From: Clemm, Geoff [mailto:gclemm@rational.com] Sent: Thursday, February 17, 2000 2:46 PM To: WebDAV WG Subject: [Moderator Action] RE: ETags I agree with Kevin. Whatever the spec says, it should say "MUST". Leaving it as a MAY would be a disservice to clients. Given the reasons described below, I vote that the spec should say that modifying a property (live or dead) of a resource MUST NOT modify the ETag or modification date. Cheers, Geoff -----Original Message----- From: Kevin Wiggen [mailto:wiggs@wiggenout.com] Sent: Thursday, February 17, 2000 3:43 PM To: Jim Whitehead; WebDAV WG Subject: RE: ETags I could probably make up just as compelling reasons why the ETag and Last-Modified-Date SHOULD change during a update of a dead property etc. But I agree that it seems that no other server can (or is) supporting this. I can pull this functionality out of Xythos. I just read Greg's email, and I don't like putting the MAY in the spec. A client will never know what the server is doing. I think we just need to pick a position and put it in 2518. I am fine with changing properties does not modify the ETag or Last-Modified-Date. But I think we should be consistent. Kevin -----Original Message----- From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jim Whitehead Sent: Thursday, February 17, 2000 12:03 PM To: WebDAV WG Subject: FW: [Moderator Action] RE: ETags Accidentally caught by the spam filter. - Jim -----Original Message----- From: Clemm, Geoff [mailto:gclemm@rational.com] Sent: Wednesday, February 16, 2000 7:56 PM To: w3c-dist-auth@w3.org Subject: [Moderator Action] RE: ETags A good reason to not change the etag or mod-date when a property changes is that a property is often information about the resource, as opposed to "being" the resource. If I mark a resource as being "tested", I don't want it to appear that the resource has changed (thus making it look like I need to test it again). A less compelling reason (but still a consideration) is to achieve consistency between dead and live properties. You certainly don't want a change to the "last access time" of a resource to modify the etag or "modification time" of that resource. Add to this the fact that current implementations appear to not modify the etag or modification time when a dead property is modified, and I think we have a pretty case that neither the etag value nor the modification time should be changed when a dead property is updated. Cheers, Geoff > -----Original Message----- > From: Kevin Wiggen [mailto:wiggs@xythos.com] > Sent: Wednesday, February 16, 2000 4:12 AM > To: w3c-dist-auth@w3.org > Subject: ETags > > > > I searched the spec and could not find any special details on handling > ETags. > > Should an ETag value be updated when a dead property is > changed? On the > same note, do most servers update the last-modified-date when a dead > property is changed? Does Webdav want to take a stand one > way or another? > > > Curious, > Kevin > From w3c-dist-auth-request@w3.org Fri Feb 18 15:59:47 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01777 for ; Fri, 18 Feb 2000 15:59:46 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA26536; Fri, 18 Feb 2000 15:55:00 -0500 (EST) Resent-Date: Fri, 18 Feb 2000 15:55:00 -0500 (EST) Resent-Message-Id: <200002182055.PAA26536@www19.w3.org> Message-ID: <01d801bf7a52$a602ede0$ab171990@us.oracle.com> From: "Eric Sedlar" To: "Jim Whitehead" , "WebDAV WG" References: Date: Fri, 18 Feb 2000 12:56:37 -0800 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.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Subject: RE: ETags Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4116 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit If the resource is an XML file, am I allowed to make some of the pieces of that available as WebDAV properties? Say I want to keep DAV:displayname in sync with the tag inside the document. If so, I would want to change the ETag when those properties are updated. --Eric > -----Original Message----- > From: Douglas Steen [mailto:dsteen@ekeeper.com] > Sent: Thursday, February 17, 2000 2:39 PM > To: WebDAV WG > Subject: [Moderator Action] RE: ETags > > > Sounds reasonable for the last-mod-date, but can we still do a MUST for the > e-tags? > > Douglas R. Steen > dsteen@eKeeper.Com > Drag-and-Drop Web Content Management > http://www.eKeeper.com > > -----Original Message----- > From: Greg Stein [mailto:gstein@lyra.org] > Sent: Thursday, 17 February, 2000 4:30 PM > To: WebDAV WG > Subject: RE: ETags > > > I think that we have to say MAY. Consider the case where properties are > stored as part of a multi-stream file (NTFS or MacOS's HFS). I bet the > date will change when you store a property. While reasonable to state that > the server implementation is required to restore the modification date to > the original (before storing the property), I think that is getting into > dangerous territory. What if your backup solution is using the > modification time to backup that multi-stream file? Or maybe there is > another storage mechanism where a server couldn't restore the date(!). > > Putting a MAY into the spec is fine. Yes, the client won't know what the > server is going to do, but that isn't that big of a deal. For most of the > live properties, the client won't always know what will happen when they > touch the resource. > > Cheers, > -g > > On Thu, 17 Feb 2000, Kevin Wiggen wrote: > > I could probably make up just as compelling reasons why the ETag and > > Last-Modified-Date SHOULD change during a update of a dead property etc. > > > > But > > > > I agree that it seems that no other server can (or is) supporting this. I > > can pull this functionality out of Xythos. > > > > I just read Greg's email, and I don't like putting the MAY in the spec. A > > client will never know what the server is doing. I think we just need to > > pick a position and put it in 2518. > > > > I am fine with changing properties does not modify the ETag or > > Last-Modified-Date. But I think we should be consistent. > > > > Kevin > > > > -----Original Message----- > > From: w3c-dist-auth-request@w3.org > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jim Whitehead > > Sent: Thursday, February 17, 2000 12:03 PM > > To: WebDAV WG > > Subject: FW: [Moderator Action] RE: ETags > > > > > > Accidentally caught by the spam filter. > > > > - Jim > > > > -----Original Message----- > > From: Clemm, Geoff [mailto:gclemm@rational.com] > > Sent: Wednesday, February 16, 2000 7:56 PM > > To: w3c-dist-auth@w3.org > > Subject: [Moderator Action] RE: ETags > > > > > > A good reason to not change the etag or mod-date when a property changes > > is that a property is often information about the resource, as opposed to > > "being" the resource. If I mark a resource as being "tested", I don't > want > > it to appear that the resource has changed (thus making it look like I > need > > to test it again). > > A less compelling reason (but still a consideration) is to achieve > > consistency > > between dead and live properties. You certainly don't want a change to > the > > "last access time" of a resource to modify the etag or "modification time" > > of > > that resource. > > Add to this the fact that current implementations appear to not modify the > > etag or > > modification time when a dead property is modified, and I think we have a > > pretty > > case that neither the etag value nor the modification time should > > be changed when a dead property is updated. > > > > Cheers, > > Geoff > > > > > -----Original Message----- > > > From: Kevin Wiggen [mailto:wiggs@xythos.com] > > > Sent: Wednesday, February 16, 2000 4:12 AM > > > To: w3c-dist-auth@w3.org > > > Subject: ETags > > > > > > > > > > > > I searched the spec and could not find any special details on handling > > > ETags. > > > > > > Should an ETag value be updated when a dead property is > > > changed? On the > > > same note, do most servers update the last-modified-date when a dead > > > property is changed? Does Webdav want to take a stand one > > > way or another? > > > > > > > > > Curious, > > > Kevin > > > > > > > -- > Greg Stein, http://www.lyra.org/ > > From w3c-dist-auth-request@w3.org Fri Feb 18 19:28:21 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04377 for <webdav-archive@odin.ietf.org>; Fri, 18 Feb 2000 19:28:21 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id TAA04996; Fri, 18 Feb 2000 19:24:05 -0500 (EST) Resent-Date: Fri, 18 Feb 2000 19:24:05 -0500 (EST) Resent-Message-Id: <200002190024.TAA04996@www19.w3.org> From: Jim Whitehead <ejw@ics.uci.edu> To: Eric Sedlar <esedlar@us.oracle.com>, WebDAV WG <w3c-dist-auth@w3.org> Date: Fri, 18 Feb 2000 16:18:49 -0800 Message-ID: <NDBBIKLAGLCOPGKGADOJMEFPCOAA.ejw@ics.uci.edu> 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) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: <01d801bf7a52$a602ede0$ab171990@us.oracle.com> Subject: RE: ETags Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/4117 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit > If the resource is an XML file, am I allowed to make some of the pieces of > that available as WebDAV properties? Say I want to keep > DAV:displayname in > sync with the <title> tag inside the document. If so, I would want to > change the ETag when those properties are updated. At a first glance, this seems reasonable to me. There isn't anything in RFC 2518 that I can think of that prohibits this. - Jim From w3c-dist-auth-request@w3.org Sat Feb 19 15:01:39 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27359 for <webdav-archive@odin.ietf.org>; Sat, 19 Feb 2000 15:01:38 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA22029; Sat, 19 Feb 2000 14:54:47 -0500 (EST) Resent-Date: Sat, 19 Feb 2000 14:54:47 -0500 (EST) Resent-Message-Id: <200002191954.OAA22029@www19.w3.org> Date: Sat, 19 Feb 2000 11:56:29 -0800 (PST) From: Greg Stein <gstein@lyra.org> To: w3c-dist-auth@w3.org cc: dav-dev@lyra.org Message-ID: <Pine.LNX.4.10.10002191148470.8706-100000@nebula.lyra.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: DAV:executable ? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/4118 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Hi all, I'd like to add an extension to mod_dav that provides a live property that can be queried/set, which corresponds to "executable" permissions in a Unix file system. Joe Orton has also said he'd provide the corresponding capability on the client. We just need to settle on How To Do It Right, so I'll come here to ask... :-) The scenario for this is uploading a CGI script. When the script is first placed, it won't have the executable flags turned on. The client then follows up with a PROPPATCH to turn the flags on. So... I've got a few questions here: * is there a more general semantic to use? e.g. all permission types rather than just executable? * this doesn't really feel like an ACL -- this is actually stating "this resource should be executable", rather than adjusting who can interact (and how) with the resource * should I place this into the DAV: namespace, or use a private one? (I'd use http://www.webdav.org/props/ if DAV: wasn't appropriate) Other comments/suggestions appreciated, as always! Cheers, -g -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Sun Feb 20 21:12:14 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14512 for <webdav-archive@odin.ietf.org>; Sun, 20 Feb 2000 21:12:14 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id VAA09879; Sun, 20 Feb 2000 21:06:46 -0500 (EST) Resent-Date: Sun, 20 Feb 2000 21:06:46 -0500 (EST) Resent-Message-Id: <200002210206.VAA09879@www19.w3.org> Message-ID: <65B141FB11CCD211825700A0C9D609BC01FA5A26@chef.lex.rational.com> From: "Clemm, Geoff" <gclemm@Rational.Com> To: "'w3c-dist-auth@w3.org'" <w3c-dist-auth@w3.org> Date: Sun, 20 Feb 2000 20:54:23 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Yaron.Redirect.NoRelative Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/4119 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list There are many cases where "fixing up the references" is not feasible. For example, if you are not moving a collection, but rather are creating an alias for it (e.g. via BIND), then you need references that work with either of the legal names for the collection. Since relative references are trivial for a server to implement, and very useful for many client applications, I believe it is important for them to be supported. Cheers, Geoff -----Original Message----- From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Yaron Goland Sent: Friday, February 11, 2000 2:53 AM To: 'w3c-dist-auth@w3.org' Subject: Yaron.Redirect.NoRelative Section 9 of the redirect spec allows for the use of relative URIs in the reftarget production. Relative URIs are an extremely dangerous feature that have caused havoc amongst system implementers. Even so, in many circumstances they offer such a high value that the problems they cause are worth dealing with. I do not believe that this is one of those circumstances. The primary (and in my opinion only) utility for relative URIs is to allow humans to type in relative URIs so that they can create links and documents without having to specify their final location. For example, a web site designer can use Notepad to type in the links for their web page using relative URLs. That way the web site designer can test out the site in their test location and not have to go through and change all the links when they move it to their final destination. This exact functionality could, of course, be implemented automatically. For example, Microsoft FrontPage is able to check Office and HTML documents and identify their links. If an Office or HTML document is moved then FrontPage will automatically check all the links, see if the move breaks any of them and if so it will automatically fix them. Hence the utility of relative URIs is mainly that it saves some humans in some cases some work. That is, it was easier to implement relative URIs then to enable all servers to read all file formats and be able to fix links. There is a second benefit to relative URIs that apply uniquely to protocols - they save bytes. If one is returning a large number of links that are all relative to some base one can save bytes by returning the URIs in a relative form. The downside to relative URIs is figuring out what the base is. HTTP provides at least two different mechanisms including the request-URI and the content-base header. Various data formats then provide their own solutions. Both HTML and XML have proposals/implementations for what the base should be. The rules for figuring out the base are complex and rarely implemented consistently. As the PM for WinInet dealing with the subtleties of relative URIs was one of the banes of my experience. What is especially bad is the conflict. If a request has a content-base header and a base specification in the HTML in the request which one is to be used? There are rules for figuring this out but they are rarely properly implemented. The end result of the confusion is that it is best to avoid relative URIs whenever possible. In the case of WebDAV the human benefits for the use of relative URIs are obviously irrelevant. Therefore the only argument for the use of relative URIs is that they save bytes. However given that we are using XML the bandwidth taken by the URIs is the absolutely least of our problems. As such when choosing between a simple, easy to process rule "the URI is always absolute" and a rule that introduces additional complexity for little benefit "the URI is relative", we should clearly come down on the side of simplicity. Therefore I move that relative URIs be removed from protocol elements in the redirect spec and that section 9 be deleted in its entirety. From w3c-dist-auth-request@w3.org Mon Feb 21 03:32:47 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01332 for <webdav-archive@odin.ietf.org>; Mon, 21 Feb 2000 03:32:47 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id DAA25605; Mon, 21 Feb 2000 03:19:38 -0500 (EST) Resent-Date: Mon, 21 Feb 2000 03:19:38 -0500 (EST) Resent-Message-Id: <200002210819.DAA25605@www19.w3.org> Message-ID: <7DE119D3D0E15543874F7561EECBDBED02619E5D@BEG.platinum.corp.microsoft.com> From: Yaron Goland <yarong@Exchange.Microsoft.com> To: "'Clemm, Geoff'" <gclemm@Rational.Com>, w3c-dist-auth@w3.org Date: Mon, 21 Feb 2000 00:19:05 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Yaron.Redirect.NoRelative Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/4120 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list I am not arguing that relative URLs must be banned from everything, everywhere. I am just asking that relative URL support be removed from the DAV:RefTarget element used in the MKRESOURCE method. If there is a scenario where a MKRESOURCE intended to create a redirect resource cannot properly work without the ability to specify a relative URL in the DAV:RefTarget XML element then I will withdraw my objection. Otherwise, based on K.I.S.S. and my arguments below, we need to pull out relative URL support in the DAV:RefTarget XML element. Yaron > -----Original Message----- > From: Clemm, Geoff [mailto:gclemm@Rational.Com] > Sent: Sun, February 20, 2000 5:54 PM > To: w3c-dist-auth@w3.org > Subject: RE: Yaron.Redirect.NoRelative > > > There are many cases where "fixing up the references" is not feasible. > For example, if you are not moving a collection, but rather > are creating > an alias for it (e.g. via BIND), then you need references that work > with either of the legal names for the collection. > > Since relative references are trivial for a server to implement, and > very useful for many client applications, I believe it is important > for them to be supported. > > Cheers, > Geoff > > > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On > Behalf Of Yaron Goland > Sent: Friday, February 11, 2000 2:53 AM > To: 'w3c-dist-auth@w3.org' > Subject: Yaron.Redirect.NoRelative > > > Section 9 of the redirect spec allows for the use of relative > URIs in the > reftarget production. Relative URIs are an extremely > dangerous feature that > have caused havoc amongst system implementers. Even so, in many > circumstances they offer such a high value that the problems > they cause are > worth dealing with. I do not believe that this is one of those > circumstances. > The primary (and in my opinion only) utility for relative > URIs is to allow > humans to type in relative URIs so that they can create links > and documents > without having to specify their final location. For example, > a web site > designer can use Notepad to type in the links for their web page using > relative URLs. That way the web site designer can test out > the site in their > test location and not have to go through and change all the > links when they > move it to their final destination. > This exact functionality could, of course, be implemented > automatically. For > example, Microsoft FrontPage is able to check Office and HTML > documents and > identify their links. If an Office or HTML document is moved > then FrontPage > will automatically check all the links, see if the move > breaks any of them > and if so it will automatically fix them. > Hence the utility of relative URIs is mainly that it saves > some humans in > some cases some work. That is, it was easier to implement > relative URIs then > to enable all servers to read all file formats and be able to > fix links. > There is a second benefit to relative URIs that apply > uniquely to protocols > - they save bytes. If one is returning a large number of > links that are all > relative to some base one can save bytes by returning the > URIs in a relative > form. > The downside to relative URIs is figuring out what the base is. HTTP > provides at least two different mechanisms including the > request-URI and the > content-base header. Various data formats then provide their > own solutions. > Both HTML and XML have proposals/implementations for what the > base should > be. The rules for figuring out the base are complex and > rarely implemented > consistently. As the PM for WinInet dealing with the > subtleties of relative > URIs was one of the banes of my experience. > What is especially bad is the conflict. If a request has a > content-base > header and a base specification in the HTML in the request > which one is to > be used? There are rules for figuring this out but they are > rarely properly > implemented. > The end result of the confusion is that it is best to avoid > relative URIs > whenever possible. > In the case of WebDAV the human benefits for the use of > relative URIs are > obviously irrelevant. Therefore the only argument for the use > of relative > URIs is that they save bytes. However given that we are using XML the > bandwidth taken by the URIs is the absolutely least of our > problems. As such > when choosing between a simple, easy to process rule "the URI > is always > absolute" and a rule that introduces additional complexity for little > benefit "the URI is relative", we should clearly come down on > the side of > simplicity. > Therefore I move that relative URIs be removed from protocol > elements in the > redirect spec and that section 9 be deleted in its entirety. > From w3c-dist-auth-request@w3.org Mon Feb 21 14:20:45 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15006 for <webdav-archive@odin.ietf.org>; Mon, 21 Feb 2000 14:20:45 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA14987; Mon, 21 Feb 2000 14:16:26 -0500 (EST) Resent-Date: Mon, 21 Feb 2000 14:16:26 -0500 (EST) Resent-Message-Id: <200002211916.OAA14987@www19.w3.org> Message-ID: <8E3CFBC709A8D21191A400805F15E0DB0211F962@crte147.wc.eso.mc.xerox.com> From: "Slein, Judith A" <JSlein@crt.xerox.com> To: "'Yaron Goland'" <yarong@Exchange.Microsoft.com>, "'Clemm, Geoff'" <gclemm@Rational.Com>, w3c-dist-auth@w3.org Date: Mon, 21 Feb 2000 14:16:02 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Yaron.Redirect.NoRelative Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/4121 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list I've been assuming that we would stand by our general philosophy, that servers never have to verify that the target exists, or track the target as it moves. So they don't have to maintain the value of DAV:reftarget. Of course, we don't currently forbid servers to do that. I've also assumed that servers would generally do the minimum required of them. So in general, when they receive a MKRESOURCE to create a redirect reference, they would just stuff the value of DAV:reftarget into the (dead) property. The client would know enough about its application to make a judgment about whether a relative or absolute URI in DAV:reftarget would be more likely to survive unbroken over time, given that the server is not going to do anything to maintain it. If the application is one where most redirect references have targets within a hierarchy that typically gets moved as a whole, it will be safer to use relative URIs than absolute URIs. --Judy -----Original Message----- From: Yaron Goland [mailto:yarong@Exchange.Microsoft.com] Sent: Monday, February 21, 2000 3:19 AM To: 'Clemm, Geoff'; w3c-dist-auth@w3.org Subject: RE: Yaron.Redirect.NoRelative I am not arguing that relative URLs must be banned from everything, everywhere. I am just asking that relative URL support be removed from the DAV:RefTarget element used in the MKRESOURCE method. If there is a scenario where a MKRESOURCE intended to create a redirect resource cannot properly work without the ability to specify a relative URL in the DAV:RefTarget XML element then I will withdraw my objection. Otherwise, based on K.I.S.S. and my arguments below, we need to pull out relative URL support in the DAV:RefTarget XML element. Yaron > -----Original Message----- > From: Clemm, Geoff [mailto:gclemm@Rational.Com] > Sent: Sun, February 20, 2000 5:54 PM > To: w3c-dist-auth@w3.org > Subject: RE: Yaron.Redirect.NoRelative > > > There are many cases where "fixing up the references" is not feasible. > For example, if you are not moving a collection, but rather > are creating > an alias for it (e.g. via BIND), then you need references that work > with either of the legal names for the collection. > > Since relative references are trivial for a server to implement, and > very useful for many client applications, I believe it is important > for them to be supported. > > Cheers, > Geoff > > > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On > Behalf Of Yaron Goland > Sent: Friday, February 11, 2000 2:53 AM > To: 'w3c-dist-auth@w3.org' > Subject: Yaron.Redirect.NoRelative > > > Section 9 of the redirect spec allows for the use of relative > URIs in the > reftarget production. Relative URIs are an extremely > dangerous feature that > have caused havoc amongst system implementers. Even so, in many > circumstances they offer such a high value that the problems > they cause are > worth dealing with. I do not believe that this is one of those > circumstances. > The primary (and in my opinion only) utility for relative > URIs is to allow > humans to type in relative URIs so that they can create links > and documents > without having to specify their final location. For example, > a web site > designer can use Notepad to type in the links for their web page using > relative URLs. That way the web site designer can test out > the site in their > test location and not have to go through and change all the > links when they > move it to their final destination. > This exact functionality could, of course, be implemented > automatically. For > example, Microsoft FrontPage is able to check Office and HTML > documents and > identify their links. If an Office or HTML document is moved > then FrontPage > will automatically check all the links, see if the move > breaks any of them > and if so it will automatically fix them. > Hence the utility of relative URIs is mainly that it saves > some humans in > some cases some work. That is, it was easier to implement > relative URIs then > to enable all servers to read all file formats and be able to > fix links. > There is a second benefit to relative URIs that apply > uniquely to protocols > - they save bytes. If one is returning a large number of > links that are all > relative to some base one can save bytes by returning the > URIs in a relative > form. > The downside to relative URIs is figuring out what the base is. HTTP > provides at least two different mechanisms including the > request-URI and the > content-base header. Various data formats then provide their > own solutions. > Both HTML and XML have proposals/implementations for what the > base should > be. The rules for figuring out the base are complex and > rarely implemented > consistently. As the PM for WinInet dealing with the > subtleties of relative > URIs was one of the banes of my experience. > What is especially bad is the conflict. If a request has a > content-base > header and a base specification in the HTML in the request > which one is to > be used? There are rules for figuring this out but they are > rarely properly > implemented. > The end result of the confusion is that it is best to avoid > relative URIs > whenever possible. > In the case of WebDAV the human benefits for the use of > relative URIs are > obviously irrelevant. Therefore the only argument for the use > of relative > URIs is that they save bytes. However given that we are using XML the > bandwidth taken by the URIs is the absolutely least of our > problems. As such > when choosing between a simple, easy to process rule "the URI > is always > absolute" and a rule that introduces additional complexity for little > benefit "the URI is relative", we should clearly come down on > the side of > simplicity. > Therefore I move that relative URIs be removed from protocol > elements in the > redirect spec and that section 9 be deleted in its entirety. > From w3c-dist-auth-request@w3.org Mon Feb 21 14:37:52 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15285 for <webdav-archive@odin.ietf.org>; Mon, 21 Feb 2000 14:37:51 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA15455; Mon, 21 Feb 2000 14:33:35 -0500 (EST) Resent-Date: Mon, 21 Feb 2000 14:33:35 -0500 (EST) Resent-Message-Id: <200002211933.OAA15455@www19.w3.org> Message-ID: <8E3CFBC709A8D21191A400805F15E0DB0211F963@crte147.wc.eso.mc.xerox.com> From: "Slein, Judith A" <JSlein@crt.xerox.com> To: "'Yaron Goland'" <yarong@Exchange.Microsoft.com>, "'w3c-dist-auth@w3.org'" <w3c-dist-auth@w3.org> Date: Mon, 21 Feb 2000 14:33:12 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Yaron.Redirect.Sec4LastPar Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/4122 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list In a number of your comments, you suggest that we use the expression "blind response" to characterize the 302 that you get back from a redirect reference resource. Can you say more about what you are trying to convey with "blind"? In this message, it looks as if it is supposed to contrast with the 302 you would get back from a non-redirect-reference-resource. How is one of these responses more blind than the other? Or perhaps I'm just off on the wrong track altogether. Thanks. --Judy -----Original Message----- From: Yaron Goland [mailto:yarong@Exchange.Microsoft.com] Sent: Friday, February 11, 2000 2:47 AM To: 'w3c-dist-auth@w3.org' Subject: Yaron.Redirect.Sec4LastPar The last paragraph of section 4 currently reads: Since a redirect reference resource is a resource, it can have its own properties and body, and methods can be applied to the reference resource as well as to its target resource. The Apply-To-Redirect-Ref request header (defined in Section 11.2 below) is provided so that referencing-aware clients can control whether an operation is applied to the redirect reference resource or to its target resource. The Apply- To-Redirect-Ref header can be used with most requests to redirect reference resources. This header is particularly useful with PROPFIND, to retrieve the reference resource's own properties. Given the numerous changes I request in my comments the previous description is no longer accurate. I also felt that it didn't provide a sufficiently broad overview of the total functionality provided by redirect resources. Below I provide several paragraphs that I suggest replace the previous one: Redirect resources are resources and thus have their own state. However the default response of a redirect resource to all methods is a 302 (Found). A mechanism is needed that instructs the redirect resource to handle a method directly rather than blindly responding to it with a 302 (Found). The Apply-To-Redirect-Ref request header (defined in Section 11.2 below) provides such a mechanism. For example, if a user issues a PUT request without the Apply-To-Redirect-Ref request header then the redirect resource will respond with a 302 (Found). However, if the redirect resource supports PUT and if the requestor is properly authorized then a PUT issued to a redirect resource with a Apply-To-Redirect-Ref header will result in the body of the PUT request being stored for future response to a GET request, assuming the GET has a Apply-To-Redirect-Ref header. Please note that it is perfectly legal for the response to a request to a redirect reference resource with the Apply-To-Redirect-Ref header to result in a 302 (Found). In this case the 302 (Found) will not be a blind response but rather will be the correct result of the method. Also note that such a response would not include a redirect-ref header. From w3c-dist-auth-request@w3.org Mon Feb 21 14:42:50 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15351 for <webdav-archive@odin.ietf.org>; Mon, 21 Feb 2000 14:42:49 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA15701; Mon, 21 Feb 2000 14:38:24 -0500 (EST) Resent-Date: Mon, 21 Feb 2000 14:38:24 -0500 (EST) Resent-Message-Id: <200002211938.OAA15701@www19.w3.org> Message-ID: <8E3CFBC709A8D21191A400805F15E0DB0211F964@crte147.wc.eso.mc.xerox.com> From: "Slein, Judith A" <JSlein@crt.xerox.com> To: "'Yaron Goland'" <yarong@Exchange.Microsoft.com>, "'w3c-dist-auth@w3.org'" <w3c-dist-auth@w3.org> Date: Mon, 21 Feb 2000 14:38:04 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Yaron.Redirect.PUT Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/4123 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Right. This is definitely a mistake that needs to be fixed. --Judy -----Original Message----- From: Yaron Goland [mailto:yarong@Exchange.Microsoft.com] Sent: Friday, February 11, 2000 2:49 AM To: 'w3c-dist-auth@w3.org' Subject: Yaron.Redirect.PUT The last sentence of the last paragraph of section 6.2 reads: "The result in this case is that the reference resource is replaced by a non-reference resource having the content submitted with the request." If a Apply-To-Redirect-Ref PUT results in the reference resource being replaced then the reference spec will have robbed its users of any mechanism to specify the response to a Apply-To-Redirect-Ref GET. I can't find any reason for requiring this behavior given that a Apply-To-Redirect-Ref DELETE followed by a PUT can achieve the same result and still leave users the ability to specify the results of a Apply-To-Redirect-Ref GET. As such I move that this sentence be deleted. BTW, the reason I suggest deleting the sentence rather than replacing it with language specifying what happens when a PUT is applied is that there is no requirement that a PUT set the GET result. For example, the user may do a PUT with text/html and the server may choose to return it as text/plain. So it is very difficult to precisely specify what the result of a PUT is. What it is not, however, is a way to delete a resource. Otherwise it would make a mockery of unique resource IDs. Imagine I create a document and want to track it. What the document is created it is issued a resource ID that I record. That way, even if the document is moved, I can find it through its resource ID. If PUT worked as specified above then every time someone PUT to the resource the old resource would be deleted and a new one would be created with a new resource ID, so much for being able to track the document. As such it is clear that a PUT should not cause an implied DELETE. From w3c-dist-auth-request@w3.org Mon Feb 21 14:48:25 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15459 for <webdav-archive@odin.ietf.org>; Mon, 21 Feb 2000 14:48:24 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA16001; Mon, 21 Feb 2000 14:44:08 -0500 (EST) Resent-Date: Mon, 21 Feb 2000 14:44:08 -0500 (EST) Resent-Message-Id: <200002211944.OAA16001@www19.w3.org> Message-ID: <8E3CFBC709A8D21191A400805F15E0DB0211F965@crte147.wc.eso.mc.xerox.com> From: "Slein, Judith A" <JSlein@crt.xerox.com> To: "'Yaron Goland'" <yarong@Exchange.Microsoft.com>, "'w3c-dist-auth@w3.org'" <w3c-dist-auth@w3.org> Date: Mon, 21 Feb 2000 14:43:46 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Yaron.Redirect.BlindRedirect Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/4124 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Again, I have a problem with the expression "blind" till I hear more from you. But I think the important piece of information the client gets from the Redirect-Ref header is that the resource understands the Apply-To-Redirect-Ref header. So that's why it makes sense to return Redirect-Ref header with the 302, but not with a response to a request that was already using Apply-To-Redirect-Ref. So perhaps you would be happier if we just say this. --Judy -----Original Message----- From: Yaron Goland [mailto:yarong@Exchange.Microsoft.com] Sent: Friday, February 11, 2000 2:50 AM To: 'w3c-dist-auth@w3.org' Subject: Yaron.Redirect.BlindRedirect The second sentence of the last paragraph of section 6.3 reads: "The Redirect-Ref header informs a reference-aware client that this is not an ordinary HTTP 1.1 redirect, but is a redirect reference resource. " If the purpose of the Redirect-Ref header was solely to inform the client that they were dealing with a redirect resource then the header would be returned on all responses from a redirect resource, even those with a Apply-To-Redirect-Ref header. However the purpose of the Redirect-Ref header is to let redirect aware clients determine that they are dealing with a blindly generated 302. As such I move that the sentence be changed to state: "The Redirect-Ref header informs a redirect aware client that they have received a blind 302 response from a redirect resource." Similarly the main paragraph of section 11.1 currently reads: "The Redirect-Ref header is used in all 302 responses from redirect resources. Its presence informs reference-aware clients that the response is not a plain HTTP/1.1 redirect, but is a response from a redirect reference resource." I move that it be re-written to read: "The Redirect-Ref header is used to mark blind 302 responses from redirect resources." From w3c-dist-auth-request@w3.org Mon Feb 21 15:30:00 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15979 for <webdav-archive@odin.ietf.org>; Mon, 21 Feb 2000 15:29:58 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA18771; Mon, 21 Feb 2000 15:25:35 -0500 (EST) Resent-Date: Mon, 21 Feb 2000 15:25:35 -0500 (EST) Resent-Message-Id: <200002212025.PAA18771@www19.w3.org> Message-ID: <8E3CFBC709A8D21191A400805F15E0DB0211F966@crte147.wc.eso.mc.xerox.com> From: "Slein, Judith A" <JSlein@crt.xerox.com> To: "'Yaron Goland'" <yarong@Exchange.Microsoft.com>, "'w3c-dist-auth@w3.org'" <w3c-dist-auth@w3.org> Date: Mon, 21 Feb 2000 15:25:18 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Yaron.Redirect.S10 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/4125 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Comments interspersed in <js></js> tags. -----Original Message----- From: Yaron Goland [mailto:yarong@Exchange.Microsoft.com] Sent: Friday, February 11, 2000 2:54 AM To: 'w3c-dist-auth@w3.org' Subject: Yaron.Redirect.S10 Section 10 of the redirect spec requires that given a HTTP URL http://foo/bar/blah <http://foo/bar/blah> as the request-URI of a method if http://foo/ <http://foo/> or http://foo/bar/ <http://foo/bar/> are redirect resources then the request must be redirected to the locations specified by those redirect resources with the remaining part of the request-URI appended to the redirection location. This means that when a HTTP URL is submitted the server must examine each segment of the URL and determine if any of those segments point to a redirect resource. This means that every time a URL is submitted a minimum of N lookups must occur where N equals the number of segments of the URL. This has a devastating effect on efficiency. <js> I don't think it's quite that bad. The server would probably first check whether it has a mapping for the whole URI. Only if it doesn't would the server have to start checking subpaths. So it's more complicated code, but not a dramatic effect on efficiency. </js> In the current HTTP system one can implement a HTTP URL to resource mapping mechanism in two steps. Step 1 - Look up the name and get back the internal pointer to the resource. Step 2 - Use internal point to submit method to resource. Section 10 changes this, for all HTTP URL namespaces that have redirect support, to be: For (segment 1 to segment N) { If (typeof(segment) == redirect) { Issue 300 } } Segment(Method) The section 10 requirement would be the first time we ever required that the processing of a URL to resource mapping was dependent on the state of any resource other than the target. This seems like a really bad precedent to set as it significantly increases the complexity and cost of handling HTTP. In addition this requirement makes it very difficult and extremely inefficient to distribute one's namespace. If one wants to put http://foo/ <http://foo/> on one server, http://foo/bar <http://foo/bar> on another server and http://foo/bar/blah <http://foo/bar/blah> on a third server then any requests to http://foo/bar/blah <http://foo/bar/blah> MUST be sent to the two others servers in order to figure out if any of them is a redirect resources. This is an enormous burden to put on implementers wishing to distribute their namespace. (Note that in a WebDAV consistent namespace there would be a similar requirement but it would only apply to the immediate parent and so at most one other system, not N other systems as the redirect draft requires.) <js> Again, you would first attempt to resolve the URL in the usual way, and only if that fails would you have to start checking sub-paths instead of rejecting the request out of hand. </js> This all having been said, the motive behind introducing the section 10 behavior is clear and reasonable. The desire is to enable redirect resources to create the same experience for the end user as a bind resource. However here we run into an issue that is peculiar to HTTP. HTTP's resource namespace is not consistent. Even the WebDAV namespace, if non-WebDAV resources are included, is not required to be consistent. Namespace consistency brings with it too high a cost in terms of coordination and complexity to be mandatory. Therefore, at minimum, we require a type of redirect resource that does not have the section 10 behavior. This resource would expose the behavior we see today in various HTTP servers that allow their users to create 300 resources. Therefore I move that a type of redirect resource be specified in the redirect spec that does not have section 10 behavior. That having been said I am sympathetic to the desire to have the section 10 rules. They certainly replicate the behavior seen today in many systems. As such I will not object to the inclusion of a redirect resource with section 10 behavior in the redirect spec. However I do move that the authors must address the issue of what happens when the redirection location isn't a HTTP URL. How do we handle a request for http://foo/bar/blah <http://foo/bar/blah> when http://foo/bar <http://foo/bar> is a redirect resource to ftp://itsy/bitsy <ftp://itsy/bitsy> ? <js> We haven't really discussed this type of case, and you are right that we have to address it somehow. In the particular example you give, we could just have the server follow the rules in section 10, and respond with a 302 and Location: ftp://itsy/bitsy/blah <ftp://itsy/bitsy/blah> . The client would then have to figure out whether there is anything in ftp corresponding to the method in its original request. </js> Paragraph 3 of section 10 reads: Note: If the DAV:reftarget property ends with a "/" and the remainder of the Request-URI is non-empty (and therefore must begin with a "/"), the final "/" in the DAV:reftarget property is dropped before the remainder of the Request-URI is appended. This behavior is in contradiction to both RFC 2518 and RFC 2616. Resources that end with a "/" are currently considered different resources from those that do not end with a "/". This is exactly the same issue brought up in Yaron.NoSlash ( http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/0069.html <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/0069.html> ) and I would love to see option 2 as listed there adopted. Failing that the authors must adopt option 1 and change the draft. Either way, I move that the authors must address this issue based on the requirements placed in Yaron.NoSlash. <js> I don't think this does raise the same issue. All we are doing here is making sure that you don't end up with a URL that has 2 consecutive slashes in the middle somewhere. </js> From w3c-dist-auth-request@w3.org Mon Feb 21 15:56:16 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16384 for <webdav-archive@odin.ietf.org>; Mon, 21 Feb 2000 15:56:15 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA19796; Mon, 21 Feb 2000 15:52:01 -0500 (EST) Resent-Date: Mon, 21 Feb 2000 15:52:01 -0500 (EST) Resent-Message-Id: <200002212052.PAA19796@www19.w3.org> Message-ID: <8E3CFBC709A8D21191A400805F15E0DB0211F967@crte147.wc.eso.mc.xerox.com> From: "Slein, Judith A" <JSlein@crt.xerox.com> To: "'Yaron Goland'" <yarong@Exchange.Microsoft.com>, "'w3c-dist-auth@w3.org'" <w3c-dist-auth@w3.org> Date: Mon, 21 Feb 2000 15:51:42 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Yaron.Redirect.ClientUpdate Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/4126 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list As long as we have the DAV:reftarget property, the obvious thing to do is allow clients to update its value. If you want to get rid of that property, as it seems you do from NoWebDAV#3, then I suppose we would need something like an UPDATEREFTARGET method. --Judy -----Original Message----- From: Yaron Goland [mailto:yarong@Exchange.Microsoft.com] Sent: Friday, February 11, 2000 2:57 AM To: 'w3c-dist-auth@w3.org' Subject: Yaron.Redirect.ClientUpdate Maybe I just missed it but there doesn't seem to be any way to update the target of a redirection resource without deleting it. I move that a mechanism be provided that enables the target of a redirection resource to be updated without having to delete the resource. From w3c-dist-auth-request@w3.org Mon Feb 21 17:17:46 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18265 for <webdav-archive@odin.ietf.org>; Mon, 21 Feb 2000 17:17:44 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA23463; Mon, 21 Feb 2000 17:13:19 -0500 (EST) Resent-Date: Mon, 21 Feb 2000 17:13:19 -0500 (EST) Resent-Message-Id: <200002212213.RAA23463@www19.w3.org> Date: Mon, 21 Feb 2000 21:39:17 +0000 From: Joe Orton <joe@orton.demon.co.uk> To: Greg Stein <gstein@lyra.org> Cc: w3c-dist-auth@w3.org, dav-dev@lyra.org Message-ID: <20000221213917.D1257@ankh.dunno.local> Mail-Followup-To: Greg Stein <gstein@lyra.org>, w3c-dist-auth@w3.org, dav-dev@lyra.org References: <Pine.LNX.4.10.10002191148470.8706-100000@nebula.lyra.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <Pine.LNX.4.10.10002191148470.8706-100000@nebula.lyra.org>; from gstein@lyra.org on Sat, Feb 19, 2000 at 11:56:29AM -0800 Subject: Re: DAV:executable ? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/4127 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list > * is there a more general semantic to use? e.g. all permission types > rather than just executable? This is my worry. Are people going to come along and say "But I want my scripts to be chmod 0700" (or whatever)? I'm more tempted by a "unix-permissions" type property, and allowing access to the real file permissions as an octal value. Regards, joe From w3c-dist-auth-request@w3.org Mon Feb 21 20:29:53 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19771 for <webdav-archive@odin.ietf.org>; Mon, 21 Feb 2000 20:29:52 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id UAA26392; Mon, 21 Feb 2000 20:25:33 -0500 (EST) Resent-Date: Mon, 21 Feb 2000 20:25:33 -0500 (EST) Resent-Message-Id: <200002220125.UAA26392@www19.w3.org> From: Jim Whitehead <ejw@ics.uci.edu> To: WebDAV WG <w3c-dist-auth@w3.org> Date: Mon, 21 Feb 2000 17:20:15 -0800 Message-ID: <NDBBIKLAGLCOPGKGADOJEEHLCOAA.ejw@ics.uci.edu> 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) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Subject: Re: DAV:executable ? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/4128 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit Caught by the spam filter -- I've added Russ to the accept2 list. - Jim -----Original Message----- From: dav-dev-admin@lyra.org [mailto:dav-dev-admin@lyra.org]On Behalf Of Russ Pridemore Sent: Sunday, February 20, 2000 4:25 PM To: Joe Orton Cc: Greg Stein; w3c-dist-auth@w3.org; dav-dev@lyra.org Subject: Re: [dav-dev] Re: DAV:executable ? It seems to me that this issue could best be dealt with by the DAV server configuration instead of depending on clients. A developer working with Windows systems for both client and server could neglect to set this property and see no ill effects. Until the product shipped and someone tried their client with a UNIX server. My $0.02... Russ Joe Orton wrote: > > * is there a more general semantic to use? e.g. all permission types > > rather than just executable? > > This is my worry. Are people going to come along and say "But I want my > scripts to be chmod 0700" (or whatever)? I'm more tempted by a > "unix-permissions" type property, and allowing access to the real file > permissions as an octal value. > > Regards, > > joe > > _______________________________________________ > dav-dev maillist - dav-dev@lyra.org > http://dav.lyra.org/mailman/listinfo/dav-dev _______________________________________________ dav-dev maillist - dav-dev@lyra.org http://dav.lyra.org/mailman/listinfo/dav-dev From w3c-dist-auth-request@w3.org Mon Feb 21 20:36:57 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19925 for <webdav-archive@odin.ietf.org>; Mon, 21 Feb 2000 20:36:56 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id UAA26491; Mon, 21 Feb 2000 20:32:49 -0500 (EST) Resent-Date: Mon, 21 Feb 2000 20:32:49 -0500 (EST) Resent-Message-Id: <200002220132.UAA26491@www19.w3.org> From: Jim Whitehead <ejw@ics.uci.edu> To: Joe Orton <joe@orton.demon.co.uk>, Greg Stein <gstein@lyra.org> Cc: w3c-dist-auth@w3.org, dav-dev@lyra.org MMDF-Warning: Parse error in original version of preceding line at gremlin-relay.ics.uci.edu Date: Mon, 21 Feb 2000 17:27:30 -0800 Message-ID: <NDBBIKLAGLCOPGKGADOJMEHLCOAA.ejw@ics.uci.edu> 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) In-Reply-To: <20000221213917.D1257@ankh.dunno.local> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Subject: RE: DAV:executable ? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/4129 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit > > > * is there a more general semantic to use? e.g. all permission types > > rather than just executable? > > This is my worry. Are people going to come along and say "But I want my > scripts to be chmod 0700" (or whatever)? I'm more tempted by a > "unix-permissions" type property, and allowing access to the real file > permissions as an octal value. Here's the slippery slope. What is really needed are more than just executable permissions. But, creating just a Unix permissions property doesn't handle interoperability very well, since it doesn't map especially well to non-Unix filesystems. Then, once you start looking at the needed access permissions for DAV, you realize that the ability to create a resource, then share it with other users is also important. Next thing you know, you're dealing with just about the same set of issues as are in the access control draft. Yaron's been promising a new revision of the ACL spec. for some time now, and I'm anxiously awaiting it. If you have other ideas on how this should work, please write them up in either a mail message, or better yet, an Internet-Draft. Heck, even writing up the Unix permissions property idea would be useful, since it would act as a good null-hypothesis to anything else we come up with. - Jim From w3c-dist-auth-request@w3.org Mon Feb 21 21:06:43 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20228 for <webdav-archive@odin.ietf.org>; Mon, 21 Feb 2000 21:06:42 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id VAA27079; Mon, 21 Feb 2000 21:02:31 -0500 (EST) Resent-Date: Mon, 21 Feb 2000 21:02:31 -0500 (EST) Resent-Message-Id: <200002220202.VAA27079@www19.w3.org> From: Jim Whitehead <ejw@ics.uci.edu> To: WebDAV WG <w3c-dist-auth@w3.org> Date: Mon, 21 Feb 2000 17:57:17 -0800 Message-ID: <NDBBIKLAGLCOPGKGADOJOEHNCOAA.ejw@ics.uci.edu> 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) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Subject: FW: Last Call: NFS version 4 to Proposed Standard Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/4130 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit FYI, this NFSv4 I-D has an access control scheme, locking, and hard links. You might find it interesting to look at... - Jim -----Original Message----- From: scoya@cnri.reston.va.us [mailto:scoya@cnri.reston.va.us]On Behalf Of The IESG Sent: Monday, February 21, 2000 6:15 AM To: IETF-Announce: ; Cc: nfsv4-wg@sunroof.eng.sun.com Subject: Last Call: NFS version 4 to Proposed Standard The IESG has received a request from the Network File System Version 4 Working Group to consider NFS version 4 <draft-ietf-nfsv4-06.txt> as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by March 6, 2000. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-nfsv4-06.txt From w3c-dist-auth-request@w3.org Tue Feb 22 14:40:42 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20227 for <webdav-archive@odin.ietf.org>; Tue, 22 Feb 2000 14:40:37 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA06538; Tue, 22 Feb 2000 14:35:05 -0500 (EST) Resent-Date: Tue, 22 Feb 2000 14:35:05 -0500 (EST) Resent-Message-Id: <200002221935.OAA06538@www19.w3.org> From: Jim Whitehead <ejw@ics.uci.edu> To: WebDAV WG <w3c-dist-auth@w3.org> Date: Tue, 22 Feb 2000 11:29:44 -0800 Message-ID: <NDBBIKLAGLCOPGKGADOJKEIGCOAA.ejw@ics.uci.edu> 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) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Subject: Pictures from Washington IETF :-) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/4131 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit Last November I took a couple of pictures during the Advanced Collections Breakout session at the Washington, DC IETF meeting, and I've finally gotten around to scanning them in. For starters, we have the famous "aha!" moment, when Yaron finally groked the bindings spec (notice "the light" streaming in from the window): http://www.ics.uci.edu/pub/ietf/webdav/wash99/yaron-aha.jpg And, Geoff's reaction to this event (what does it mean that there's a picture of the White House above him?): http://www.ics.uci.edu/pub/ietf/webdav/wash99/geoff-yeah.jpg I also have a picture of Judy Slein (showing the infinite patience needed to deal with the Advanced Collections specs): http://www.ics.uci.edu/pub/ietf/webdav/wash99/judy.jpg Kevin Wiggen ("man, I could have implemented this spec. in the time we just spent talking about it!"): http://www.ics.uci.edu/pub/ietf/webdav/wash99/kevin.jpg Pete Carlson, Tyson Chihaya, and Jason Crawford (left to right) ("Nobody gets out of this room until there's rought consensus!"): http://www.ics.uci.edu/pub/ietf/webdav/wash99/pete-tyson-jason.jpg I also scanned in this oldie-but-goodie from the Munich IETF meeting, held in August, 1997. When Yaron of Microsoft and Asad of Netscape walked into a cutlery store where they just so happened to have a sword lying around, the following picture was inevitable... (Yaron is on the left, Asad is on the right -- actually, they did get along really well, occasional stock price barbs aside.) http://www.ics.uci.edu/pub/ietf/webdav/wash99/yaron-asad.jpg - Jim From w3c-dist-auth-request@w3.org Tue Feb 22 15:02:27 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20986 for <webdav-archive@odin.ietf.org>; Tue, 22 Feb 2000 15:02:13 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA08524; Tue, 22 Feb 2000 14:57:16 -0500 (EST) Resent-Date: Tue, 22 Feb 2000 14:57:16 -0500 (EST) Resent-Message-Id: <200002221957.OAA08524@www19.w3.org> Message-Id: <200002221957.LAA10762@kronos.arc.nasa.gov> To: w3c-dist-auth@w3.org Date: Tue, 22 Feb 2000 11:57:01 -0800 From: Chris Knight <cknight@ptolemy.arc.nasa.gov> Subject: hello and some ACL spec questions Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/4132 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Hello all, I'm in the process of developing an object store for a document management system we use here at NASA Ames, and I decided (a while ago) to implement it with full access control. The WebDAV ACL spec seemed like a logical choice, being in the same application space as our current and future target applications (web-based document management, eventually moving to WebDAV support as well.) This object store provides persistence for (Python, currently) objects with extension for large objects (usu. files stored on the document management system.) The basic user data components of the system are objects and attributes. I've taken out the "meat" of the application logic behind the "ACL protocol" defined in the draft spec, I haven't implemented the XML engine to take client configurations and map them to application objects. With regards to the spec, Objects relate to Entities and Collections (no distinction, entities can contain other entities) and attributes relate (of course) to properties. Principals are simply other objects in the database (authentication is out of the scope of this part of the project, so let's not go down that primrose path. ;) Methods are also stored (as attributes.) Currently, for "containment" (both for determining if a user has access and for determining if an object is the child of another object) I use the attribute (multiple-)inheritance tree. (So, there are two trees in my environment: the ACL tree [single inheritance] and the attribute/containment tree [multiple inheritance.]) ACL's, ACE's, ownership, "containment" and ACL inheritance are all stored in a seperate data space from the content. In this environment, I expect property manipulation to be much more commonplace of an activity than on traditional document management (WebDAV) systems. Since this is an abstract object datastore, much of the issues of WebDAV methods mapping to the access rights don't really apply (although there should be some mapping between my object database's operations and the WebDAV methods, I would guess.) Needless to say, in the process of implementing this software, I've come across a couple questions that remain unresolved in the spec. I know that Yaron (and possibly others) are currently working on a (major?) re-write of the spec, but until that comes out I'd like to get your opinions on these questions (and, possibly, to spark interest in the spec's revision.) One of the things I'd like to see in the spec is less of a WebDAV protocol-specific list of methods; a generic list of operations. Here's a stab at such a thing (which brings up some of my questions), please correct me on these: Entities -------- create an entity - createchild for any containing collections delete an entity - deletechild for any containing collections, delete for this entity modify (the contents of) an entity - write for the entity read the contents of an entity - read for the entity read the "contents" of a collection - read for the collection (???) remove an entity from a collection - deletechild for the collection add an entity to a collection - createchild for the collection Entity ACLs ----------- read the ACL for an entity - readacl for the entity create an ACL for an entity - writeacl for the entity modify the ACL for an entity - writeacl for the entity delete the ACL for an entity - writeacl for the entity Property ACLs ------------- create an ACL for a property - writeacl for the property (entity) modify the ACL for a property - writeacl for the property delete the ACL for a property - writeacl for the property Owner ----- read the owner of an entity - (none needed) modify the owner of an entity - writeowner delete the owner of an entity - (all entities must have an owner) Properties ---------- add a new property - createchild for the entity (???) modify the contents of an existing property - write for the property delete a property - delete for the property, deletechild for the entity (???) From w3c-dist-auth-request@w3.org Tue Feb 22 16:49:31 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24538 for <webdav-archive@odin.ietf.org>; Tue, 22 Feb 2000 16:49:28 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA11946; Tue, 22 Feb 2000 16:44:34 -0500 (EST) Resent-Date: Tue, 22 Feb 2000 16:44:34 -0500 (EST) Resent-Message-Id: <200002222144.QAA11946@www19.w3.org> To: WebDAV WG <w3c-dist-auth@w3.org> cc: reuterj@ira.uka.de, jjh@ira.uka.de Date: Tue, 22 Feb 2000 22:44:47 +0100 From: Juergen Reuter <reuterj@ira.uka.de> Message-ID: <"iraun1.ira.0085201:000222.214417"@ira.uka.de> Subject: Review: Redirect Reference Resources -- Part three Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/4133 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Following the working group's last call for comments, below is the third and last part of a review of the Redirect Reference Resources Protocol. It covers chapters 12 to 24 of the protocol. ******** > 12 Properties > > 12.2 location Pseudo-Property > ... This pseudo-property is not expected > to be stored on the reference resource. ..., but its value it computed directly from the value of the target resource. Hence, I would call it a live property (rather than a pseudo-property). But why should this property not be expected to be stored on the reference resource for (just hypothetically) e.g. caching purposes? Anyway, I would prefer to see the location property and the target resource property to be made a single property, even if that means not allowing a relative URI as value of a target resource. > 16 Security Considerations > > This section is provided to make WebDAV applications aware of the > security implications of this protocol. This protocol can not make WebDAV applications, that are not aware of this protocol, aware of any implication of this protocol. Hence I suggest to replace the phrase "WebDAV applications" by "applications that implement this protocol". > 16.4 Private Locations May Be Revealed > > There are several ways that redirect reference resources may reveal > information about directory structures. ... I would like to suggest the term "directory" be replaced with "collection". In fact, this implication is not newly introduced in this protocol; it holds for any protocol with hierarchical access paths (and hence should not need to be mentioned in this protocol). > In some environments, the owner of a resource > might be able to use access control to prevent others from creating > references to that resource. That would not be consistent with the concept of redirect references as weak links (e.g. think of moving a resource to a different location that is already the target of some redirection reference). > 17 Internationalization Considerations > ... > WebDAV applications MUST support the character set tagging, character > set encoding, and the language tagging functionality of the XML > specification. This constraint ensures that the human-readable content > of this specification complies with [RFC2277]. This protocol is an extension for WebDAV; hence the above paragraph is redundant. > As in [WebDAV}, ... ^ A little typo. > For error reporting, [WebDAV] follows the convention of HTTP/1.1 status > codes, including with each status code a short, English description of > the code (e.g., 423 Locked). Internationalized applications will ignore > this message, and display an appropriate message in the user's language > and character set. > > This specification introduces no new strings that are displayed to users > as part of normal, error-free operation of the protocol. > > For rationales for these decisions and advice for application > implementors, see [WebDAV]. Once again, this is redundant. Why not just saying: "This specification does not introduce any new string that is displayed to users as part of normal, error-free operation of the protocol. For error reporting, rationales on internationalization considerations and advice for application implementors, see [WebDAV]." > 18 IANA Considerations > > This document uses the namespaces defined by [WebDAV] for properties and > XML elements. All other IANA considerations mentioned in [WebDAV] also > apply to this document. As this protocol is an extension to WebDAV, I think it is sufficient to mention that this protocol does not need any new considerations to be applied. > 22 References > ... > [B] J. Slein, E.J. Whitehead Jr., J. Davis, G. Clemm, C. Fay, J. > Crawford, "WebDAV Bindings." Internet Draft (work in progress) draft- > ietf-webdav-binding-protocol-02. Xerox, UC Irvine, CourseNet, Rational, > FileNet, IBM. December, 1999. See the comments in part one of this review on referencing the bindings protocol. > 24 Appendices > > 24.1 Appendix 1: Extensions to the WebDAV Document Type Definition > ... > <!ELEMENT response (href, ((href*, status, prop?) | (propstat+)), > responsedescription?) > It may be worth noting that, in contrast to what the headline says, this element is not an extension to the WebDAV DTD, but a replacement for the WebDAV DTD element with the same name. ******** Best regards, Juergen Reuter From w3c-dist-auth-request@w3.org Tue Feb 22 18:54:05 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27801 for <webdav-archive@odin.ietf.org>; Tue, 22 Feb 2000 18:54:04 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAA20074; Tue, 22 Feb 2000 18:49:35 -0500 (EST) Resent-Date: Tue, 22 Feb 2000 18:49:35 -0500 (EST) Resent-Message-Id: <200002222349.SAA20074@www19.w3.org> Message-ID: <7DE119D3D0E15543874F7561EECBDBED02619E60@BEG.platinum.corp.microsoft.com> From: Yaron Goland <yarong@Exchange.Microsoft.com> To: "'Jim Whitehead'" <ejw@ics.uci.edu>, WebDAV WG <w3c-dist-auth@w3.org> Date: Tue, 22 Feb 2000 15:48:52 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Pictures from Washington IETF :-) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/4134 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Actually this isn't the only time that Jim and others have taken pictures. Obviously along with the mail archives, the draft archives, the paper archives and the WebDAV book of why, we need a picture archive! Of course you can only say Yaron of Microsoft for so long. As of Friday I will no longer be working for Microsoft. It has been a total blast representing Microsoft's interests in the IETF. Future questions about Microsoft and WebDAV should go to Alex Hopmann (alexhop@microsoft.com), Josh Cohen (joshco@microsoft.com) and Henrik Frystyk Nielsen (henrikn@microsoft.com). > -----Original Message----- > From: Jim Whitehead [mailto:ejw@ics.uci.edu] > Sent: Tue, February 22, 2000 11:30 AM > To: WebDAV WG > Subject: Pictures from Washington IETF :-) > > > Last November I took a couple of pictures during the Advanced > Collections > Breakout session at the Washington, DC IETF meeting, and I've > finally gotten > around to scanning them in. > > For starters, we have the famous "aha!" moment, when Yaron > finally groked > the bindings spec (notice "the light" streaming in from the window): > http://www.ics.uci.edu/pub/ietf/webdav/wash99/yaron-aha.jpg > > And, Geoff's reaction to this event (what does it mean that there's a > picture of the White House above him?): > http://www.ics.uci.edu/pub/ietf/webdav/wash99/geoff-yeah.jpg > > I also have a picture of Judy Slein (showing the infinite > patience needed to > deal with the Advanced Collections specs): > http://www.ics.uci.edu/pub/ietf/webdav/wash99/judy.jpg > > Kevin Wiggen ("man, I could have implemented this spec. in > the time we just > spent talking about it!"): > http://www.ics.uci.edu/pub/ietf/webdav/wash99/kevin.jpg > > Pete Carlson, Tyson Chihaya, and Jason Crawford (left to > right) ("Nobody > gets out of this room until there's rought consensus!"): > http://www.ics.uci.edu/pub/ietf/webdav/wash99/pete-tyson-jason.jpg > > I also scanned in this oldie-but-goodie from the Munich IETF > meeting, held > in August, 1997. When Yaron of Microsoft and Asad of Netscape > walked into a > cutlery store where they just so happened to have a sword > lying around, the > following picture was inevitable... (Yaron is on the left, > Asad is on the > right -- actually, they did get along really well, occasional > stock price > barbs aside.) > http://www.ics.uci.edu/pub/ietf/webdav/wash99/yaron-asad.jpg > > - Jim > From w3c-dist-auth-request@w3.org Tue Feb 22 19:32:39 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28144 for <webdav-archive@odin.ietf.org>; Tue, 22 Feb 2000 19:32:38 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id TAA22487; Tue, 22 Feb 2000 19:28:21 -0500 (EST) Resent-Date: Tue, 22 Feb 2000 19:28:21 -0500 (EST) Resent-Message-Id: <200002230028.TAA22487@www19.w3.org> Message-ID: <002d01bf7d95$2355d510$ab171990@us.oracle.com> From: "Eric Sedlar" <esedlar@us.oracle.com> To: "Yaron Goland" <yarong@Exchange.Microsoft.com>, "'Jim Whitehead'" <ejw@ics.uci.edu>, "WebDAV WG" <w3c-dist-auth@w3.org> Cc: <alexhop@microsoft.com>, <joshco@microsoft.com> References: <7DE119D3D0E15543874F7561EECBDBED02619E60@BEG.platinum.corp.microsoft.com> Date: Tue, 22 Feb 2000 16:30:07 -0800 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.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Subject: Re: Pictures from Washington IETF :-) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/4135 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit Is someone taking over the WebDAV ACL spec from Yaron? --Eric ----- Original Message ----- From: Yaron Goland <yarong@Exchange.Microsoft.com> To: 'Jim Whitehead' <ejw@ics.uci.edu>; WebDAV WG <w3c-dist-auth@w3.org> Sent: Tuesday, February 22, 2000 3:48 PM Subject: RE: Pictures from Washington IETF :-) > Actually this isn't the only time that Jim and others have taken pictures. > Obviously along with the mail archives, the draft archives, the paper > archives and the WebDAV book of why, we need a picture archive! > > Of course you can only say Yaron of Microsoft for so long. As of Friday I > will no longer be working for Microsoft. It has been a total blast > representing Microsoft's interests in the IETF. Future questions about > Microsoft and WebDAV should go to Alex Hopmann (alexhop@microsoft.com), Josh > Cohen (joshco@microsoft.com) and Henrik Frystyk Nielsen > (joshco@microsoft.com). > > > -----Original Message----- > > From: Jim Whitehead [mailto:ejw@ics.uci.edu] > > Sent: Tue, February 22, 2000 11:30 AM > > To: WebDAV WG > > Subject: Pictures from Washington IETF :-) > > > > > > Last November I took a couple of pictures during the Advanced > > Collections > > Breakout session at the Washington, DC IETF meeting, and I've > > finally gotten > > around to scanning them in. > > > > For starters, we have the famous "aha!" moment, when Yaron > > finally groked > > the bindings spec (notice "the light" streaming in from the window): > > http://www.ics.uci.edu/pub/ietf/webdav/wash99/yaron-aha.jpg > > > > And, Geoff's reaction to this event (what does it mean that there's a > > picture of the White House above him?): > > http://www.ics.uci.edu/pub/ietf/webdav/wash99/geoff-yeah.jpg > > > > I also have a picture of Judy Slein (showing the infinite > > patience needed to > > deal with the Advanced Collections specs): > > http://www.ics.uci.edu/pub/ietf/webdav/wash99/judy.jpg > > > > Kevin Wiggen ("man, I could have implemented this spec. in > > the time we just > > spent talking about it!"): > > http://www.ics.uci.edu/pub/ietf/webdav/wash99/kevin.jpg > > > > Pete Carlson, Tyson Chihaya, and Jason Crawford (left to > > right) ("Nobody > > gets out of this room until there's rought consensus!"): > > http://www.ics.uci.edu/pub/ietf/webdav/wash99/pete-tyson-jason.jpg > > > > I also scanned in this oldie-but-goodie from the Munich IETF > > meeting, held > > in August, 1997. When Yaron of Microsoft and Asad of Netscape > > walked into a > > cutlery store where they just so happened to have a sword > > lying around, the > > following picture was inevitable... (Yaron is on the left, > > Asad is on the > > right -- actually, they did get along really well, occasional > > stock price > > barbs aside.) > > http://www.ics.uci.edu/pub/ietf/webdav/wash99/yaron-asad.jpg > > > > - Jim > > > > From w3c-dist-auth-request@w3.org Tue Feb 22 19:49:06 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28275 for <webdav-archive@odin.ietf.org>; Tue, 22 Feb 2000 19:49:05 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id TAA23770; Tue, 22 Feb 2000 19:44:53 -0500 (EST) Resent-Date: Tue, 22 Feb 2000 19:44:53 -0500 (EST) Resent-Message-Id: <200002230044.TAA23770@www19.w3.org> Message-ID: <9BE3A7FF0D67C341819FCA57736D5BC5B19A85@dino.platinum.corp.microsoft.com> From: Alex Hopmann <alexhop@Exchange.Microsoft.com> To: "'Eric Sedlar'" <esedlar@us.oracle.com>, Yaron Goland <yarong@Exchange.Microsoft.com>, Jim Whitehead <ejw@ics.uci.edu>, WebDAV WG <w3c-dist-auth@w3.org> Cc: Josh Cohen <joshco@Exchange.Microsoft.com>, Chris Kaler <ckaler@microsoft.com> Date: Tue, 22 Feb 2000 16:43:17 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Pictures from Washington IETF :-) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/4136 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list We have a couple of folks including myself and Chris who are interested in ACL stuff and want to work on this going forward, although most of us aren't going to make it to Australia this time around. Alex -----Original Message----- From: Eric Sedlar [mailto:esedlar@us.oracle.com] Sent: Tuesday, February 22, 2000 4:30 PM To: Yaron Goland; Jim Whitehead; WebDAV WG Cc: Alex Hopmann; Josh Cohen Subject: Re: Pictures from Washington IETF :-) Is someone taking over the WebDAV ACL spec from Yaron? --Eric ----- Original Message ----- From: Yaron Goland <yarong@Exchange.Microsoft.com> To: 'Jim Whitehead' <ejw@ics.uci.edu>; WebDAV WG <w3c-dist-auth@w3.org> Sent: Tuesday, February 22, 2000 3:48 PM Subject: RE: Pictures from Washington IETF :-) > Actually this isn't the only time that Jim and others have taken pictures. > Obviously along with the mail archives, the draft archives, the paper > archives and the WebDAV book of why, we need a picture archive! > > Of course you can only say Yaron of Microsoft for so long. As of Friday I > will no longer be working for Microsoft. It has been a total blast > representing Microsoft's interests in the IETF. Future questions about > Microsoft and WebDAV should go to Alex Hopmann (alexhop@microsoft.com), Josh > Cohen (joshco@microsoft.com) and Henrik Frystyk Nielsen > (joshco@microsoft.com). > > > -----Original Message----- > > From: Jim Whitehead [mailto:ejw@ics.uci.edu] > > Sent: Tue, February 22, 2000 11:30 AM > > To: WebDAV WG > > Subject: Pictures from Washington IETF :-) > > > > > > Last November I took a couple of pictures during the Advanced > > Collections > > Breakout session at the Washington, DC IETF meeting, and I've > > finally gotten > > around to scanning them in. > > > > For starters, we have the famous "aha!" moment, when Yaron > > finally groked > > the bindings spec (notice "the light" streaming in from the window): > > http://www.ics.uci.edu/pub/ietf/webdav/wash99/yaron-aha.jpg > > > > And, Geoff's reaction to this event (what does it mean that there's a > > picture of the White House above him?): > > http://www.ics.uci.edu/pub/ietf/webdav/wash99/geoff-yeah.jpg > > > > I also have a picture of Judy Slein (showing the infinite > > patience needed to > > deal with the Advanced Collections specs): > > http://www.ics.uci.edu/pub/ietf/webdav/wash99/judy.jpg > > > > Kevin Wiggen ("man, I could have implemented this spec. in > > the time we just > > spent talking about it!"): > > http://www.ics.uci.edu/pub/ietf/webdav/wash99/kevin.jpg > > > > Pete Carlson, Tyson Chihaya, and Jason Crawford (left to > > right) ("Nobody > > gets out of this room until there's rought consensus!"): > > http://www.ics.uci.edu/pub/ietf/webdav/wash99/pete-tyson-jason.jpg > > > > I also scanned in this oldie-but-goodie from the Munich IETF > > meeting, held > > in August, 1997. When Yaron of Microsoft and Asad of Netscape > > walked into a > > cutlery store where they just so happened to have a sword > > lying around, the > > following picture was inevitable... (Yaron is on the left, > > Asad is on the > > right -- actually, they did get along really well, occasional > > stock price > > barbs aside.) > > http://www.ics.uci.edu/pub/ietf/webdav/wash99/yaron-asad.jpg > > > > - Jim > > > > From w3c-dist-auth-request@w3.org Wed Feb 23 11:52:00 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26048 for <webdav-archive@odin.ietf.org>; Wed, 23 Feb 2000 11:51:58 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id LAA00957; Wed, 23 Feb 2000 11:47:06 -0500 (EST) Resent-Date: Wed, 23 Feb 2000 11:47:06 -0500 (EST) Resent-Message-Id: <200002231647.LAA00957@www19.w3.org> Message-Id: <200002231646.IAA11466@kronos.arc.nasa.gov> To: Alex Hopmann <alexhop@Exchange.Microsoft.com> cc: "'Eric Sedlar'" <esedlar@us.oracle.com>, Yaron Goland <yarong@Exchange.Microsoft.com>, Jim Whitehead <ejw@ics.uci.edu>, WebDAV WG <w3c-dist-auth@w3.org>, Josh Cohen <joshco@Exchange.Microsoft.com>, Chris Kaler <ckaler@microsoft.com> In-reply-to: Your message of "Tue, 22 Feb 2000 16:43:17 PST." <9BE3A7FF0D67C341819FCA57736D5BC5B19A85@dino.platinum.corp.microsoft.com> Date: Wed, 23 Feb 2000 08:46:44 -0800 From: Chris Knight <cknight@ptolemy.arc.nasa.gov> Subject: Re: Pictures from Washington IETF :-) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/4137 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list > We have a couple of folks including myself and Chris who are interested in > ACL stuff and want to work on this going forward, although most of us aren't > going to make it to Australia this time around. Whoo, if the next IETF meeting is in Australia, I'm definitely interested in helping with the spec. ;^} From w3c-dist-auth-request@w3.org Wed Feb 23 13:27:12 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29281 for <webdav-archive@odin.ietf.org>; Wed, 23 Feb 2000 13:27:09 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA09737; Wed, 23 Feb 2000 13:16:21 -0500 (EST) Resent-Date: Wed, 23 Feb 2000 13:16:21 -0500 (EST) Resent-Message-Id: <200002231816.NAA09737@www19.w3.org> Message-ID: <65B141FB11CCD211825700A0C9D609BC01D4D715@chef.lex.rational.com> From: "Clemm, Geoff" <gclemm@Rational.Com> To: "WebDAV (E-mail)" <w3c-dist-auth@w3.org> Date: Wed, 23 Feb 2000 13:03:54 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Labels Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/4138 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list I don't think it helps to say that they are URL-encoded if we are required to transmit it in a URL. These leaves the client wondering whether they got the label in the URL-encoded form or not (e.g. when it appears in a Revision-Selector header. I believe it will be simpler and less error-prone if we just say that they are UTF-8 Unicode characters that have been URL-encoded. Any client that handles URL's will be able to handle URL-encoding, and assumedly any WebDAV client will need to be able to handle URL's. Cheers, Geoff -----Original Message----- From: Tim_Ellison@oti.com [mailto:Tim_Ellison@oti.com] Sent: Wednesday, February 23, 2000 9:57 AM To: ietf-dav-versioning@w3.org Subject: Re: Labels <geoff> I agree with those on the mailing list who have argued that it is sufficient to internationalize labels to the extent that URL's are internationalized, which does not include tagging with language and charset. </geoff> Jim W. pointed out that URLs are exempted from the internationallization rules. I suggest that we say labels are UTF-8 Unicode characters; and the resulting bytes are URL-encoded if we are required to transmit it in a URL (unlikely). Tim From w3c-dist-auth-request@w3.org Wed Feb 23 16:26:49 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03014 for <webdav-archive@odin.ietf.org>; Wed, 23 Feb 2000 16:26:49 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA22643; Wed, 23 Feb 2000 16:22:06 -0500 (EST) Resent-Date: Wed, 23 Feb 2000 16:22:06 -0500 (EST) Resent-Message-Id: <200002232122.QAA22643@www19.w3.org> From: Jim Whitehead <ejw@ics.uci.edu> To: WebDAV WG <w3c-dist-auth@w3.org> Date: Wed, 23 Feb 2000 13:16:43 -0800 Message-ID: <NDBBIKLAGLCOPGKGADOJOEKCCOAA.ejw@ics.uci.edu> 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) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Subject: End: WG Last Call: Redirect References Protocol Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/4139 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit The working group last call on the Redirect References Protocol has now ended. <draft-ietf-webdav-redirectref-protocol-02> http://www.ics.uci.edu/pub/ietf/webdav/collection/draft-ietf-webdav-redirect ref-protocol-02.txt Based on the comments received during the last call period, a new revision of this document will be produced, and go through a shorter last call period, prior to being send along to the IESG for approval as a Proposed Standard. - Jim Whitehead Chair, IETF WebDAV Working Group From w3c-dist-auth-request@w3.org Thu Feb 24 00:13:03 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10884 for <webdav-archive@odin.ietf.org>; Thu, 24 Feb 2000 00:13:02 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id AAA04811; Thu, 24 Feb 2000 00:08:00 -0500 (EST) Resent-Date: Thu, 24 Feb 2000 00:08:00 -0500 (EST) Resent-Message-Id: <200002240508.AAA04811@www19.w3.org> Message-ID: <7DE119D3D0E15543874F7561EECBDBED02619E63@BEG.platinum.corp.microsoft.com> From: Yaron Goland <yarong@Exchange.Microsoft.com> To: "'Roy T. Fielding'" <fielding@kiwi.ICS.UCI.EDU> Cc: w3c-dist-auth@w3.org Date: Wed, 23 Feb 2000 21:07:09 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Subject: RE: Yaron.Redirect.Sec4LastPar Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/4140 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Ideally I would have just rewritten the draft and included comments explaining why I changed from the original draft. I just didn't have the time. =( BTW, I talked with Jim and Geoff and told them that I was leaving MS (yes, they knew before the mailing list =) and that I would have zero time. I indicated that the best I could do with the drafts is dive bomb in a bunch of comments and I probably wouldn't even have time to respond to comments on my comments. I asked them if they preferred if I just said nothing. They asked me to post the comments, so I did so. I am trying now to find a little time to respond to comments but closing up my job at MS and moving to a start up is eating all my time. Yaron > -----Original Message----- > From: Roy T. Fielding [mailto:fielding@kiwi.ICS.UCI.EDU] > Sent: Sat, February 12, 2000 6:01 PM > To: Yaron Goland > Cc: w3c-dist-auth@w3.org > Subject: Re: Yaron.Redirect.Sec4LastPar > > > >Given the numerous changes I request in my comments the > previous description > >is no longer accurate. I also felt that it didn't provide a > sufficiently > >broad overview of the total functionality provided by > redirect resources. > >Below I provide several paragraphs that I suggest replace > the previous one: > > Yaron, wouldn't it be easier to just write your own version of the > reference spec and propose that in its entirety? There is a > point beyond > which many small deltas are less efficient than a complete entity, > and you passed that a few messages ago. > > ....Roy [I am agreeing with most of your comments] > From w3c-dist-auth-request@w3.org Thu Feb 24 00:46:39 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11313 for <webdav-archive@odin.ietf.org>; Thu, 24 Feb 2000 00:46:38 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id AAA05799; Thu, 24 Feb 2000 00:42:01 -0500 (EST) Resent-Date: Thu, 24 Feb 2000 00:42:01 -0500 (EST) Resent-Message-Id: <200002240542.AAA05799@www19.w3.org> Message-ID: <7DE119D3D0E15543874F7561EECBDBED030B53D4@BEG.platinum.corp.microsoft.com> From: Yaron Goland <yarong@Exchange.Microsoft.com> To: "'Slein, Judith A'" <JSlein@crt.xerox.com>, w3c-dist-auth@w3.org Date: Wed, 23 Feb 2000 21:41:10 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Yaron.Redirect.ReallyNoBind Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/4141 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list See below. > -----Original Message----- > From: Slein, Judith A [mailto:JSlein@crt.xerox.com] > Sent: Mon, February 14, 2000 11:13 AM > To: Yaron Goland; w3c-dist-auth@w3.org > Subject: RE: Yaron.Redirect.ReallyNoBind > > > I've been pushing the hardest to keep this stuff in. There > are 2 reasons. > > First, it's essential that people be able to figure out > whether they are > reading the right spec. Redirect references and bindings are > in the same > space, but clearly bindings will be right for some > applications and redirect > references for others. There needs to be enough information for > implementers to understand the basic differences and realize > that there may > be a spec that fits their needs better than this one. > If the changes I proposed for the redirect spec are accepted then I think redirect will appear substantially different than the bind spec to such an extend that confusing them would be impossible. > Second, it's often easier to communicate a concept by > explaining what it is > not than by explaining what it is. We have to do both, in my opinion. > There have been continuing requests for binding-like behavior and for > direct-reference-like behavior in redirect references. We > can stop those > requests and make it clearer what functionality we are trying > to define here > by saying straight out that redirect references are not like > bindings, and > here's why; and redirect references are not like direct > references, and > here's why. > In practice I find that telling people what something is not just confuses them. Of course that is just my experience and your mileage may vary. > --Judy > > -----Original Message----- > From: Yaron Goland [mailto:yarong@Exchange.Microsoft.com] > Sent: Friday, February 11, 2000 1:31 AM > To: w3c-dist-auth@w3.org > Subject: Yaron.Redirect.ReallyNoBind > > > > The 6th and 8th paragraphs of the introduction of the > redirect spec go into > a discussion of the difference between bind and redirect > resources. These > sections will only serve to confuse the reader as one need understand > nothing about bind in order to successfully implement > redirect. As such I > move that the sections discussing bind as compared to > redirect resources be > removed. > From w3c-dist-auth-request@w3.org Thu Feb 24 00:54:03 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11361 for <webdav-archive@odin.ietf.org>; Thu, 24 Feb 2000 00:54:02 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id AAA05914; Thu, 24 Feb 2000 00:49:17 -0500 (EST) Resent-Date: Thu, 24 Feb 2000 00:49:17 -0500 (EST) Resent-Message-Id: <200002240549.AAA05914@www19.w3.org> Message-ID: <7DE119D3D0E15543874F7561EECBDBED030B53D5@BEG.platinum.corp.microsoft.com> From: Yaron Goland <yarong@Exchange.Microsoft.com> To: "'Slein, Judith A'" <JSlein@crt.xerox.com>, w3c-dist-auth@w3.org, "'yaron@goland.org'" <yaron@goland.org> Date: Wed, 23 Feb 2000 21:48:08 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Yaron.Redirect.NoWebDAV#1 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/4142 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list See below > -----Original Message----- > From: Slein, Judith A [mailto:JSlein@crt.xerox.com] > Sent: Wed, February 16, 2000 9:12 AM > To: Yaron Goland; w3c-dist-auth@w3.org > Subject: RE: Yaron.Redirect.NoWebDAV#1 > > > The idea of trying to specify redirect references in such a > way that they do > not depend on implementation of any other parts of WebDAV is > very appealing. > As you point out in this and the following 2 comments, we > would need to go > back to using MKREF (which doesn't have an XML body) instead > of the more > generic MKRESOURCE and get rid of the DAV:reftarget property > in order to > make this possible. > > I would be willing to do both. > > I just want to be sure that, even though it's not required > for a redirect > reference to support any other parts of WebDAV, it's > permissible for it to > do so. If it's also a WebDAV class 1 resource, I would assume its > DAV:resourcetype property would have a value DAV:redirectref. > It would be > possible to set properties on the redirect reference and view > properties on > the redirect reference using the Apply-To-Redirect-Ref header. > Agreed. > Also it is possible to create a redirect reference in a > WebDAV-compliant > collection, as discussed in Section 7 of the spec. > > What would we lose by getting rid of DAV:reftarget? > > 1. Efficiency in certain scenarios, where you are operating > on a collection > populated with redirect references. You would have to do 2 > round trips for > each member of the collection instead of getting > DAV:reftarget with PROPFIND > for all members and addressing requests to the target. > Maybe I'm missing something but wouldn't the results for a PROPFIND on all the redirect resources be a 300 and wouldn't that 300 contain the redirect target? Isn't that the same information that would have been contained in the DAV:reftarget element? Doesn't that therefore mean that there is no loss of efficiency? > 2. Can't search on DAV:reftarget to find all references to a > given resource. > Actually, there is no reason why you can't define a DAV:reftarget token for use with DASL. As I discuss in one of my points DASL can search on anything with a name, what is being searched does NOT have to be something retrievable through a PROPFIND. > 3. No relative URIs (the Location header always has absolute > URI), so in an > environment where references are within a hierarchy that is > likely to move, > redirects may get broken where they would survive in the current spec. > I admit to not understanding this one. How does the use of relative or absolute URIs in the protocol effect how information is stored at either the client or the server? Perhaps an example would help. > In my view these considerations are outweighed by the possibility of > creating and managing redirect references without > implementing any other > parts of WebDAV. So I'm with you here. Thanks for the great > suggestion! > Always a pleasure. > --Judy > Yaron > -----Original Message----- > From: Yaron Goland [mailto:yarong@Exchange.Microsoft.com] > Sent: Friday, February 11, 2000 2:44 AM > To: 'w3c-dist-auth@w3.org' > Subject: Yaron.Redirect.NoWebDAV#1 > > > > The redirect spec requires the use of WebDAV in order to > create and query > redirect resources as it makes use of the WebDAV property > mechanism. However > I am having trouble finding a compelling reason to require > WebDAV just to > implement redirect resources. A redirect resource is, in my > opinion, just an > enhancement to HTTP/1.1. > > HTTP/1.1 introduced the concept of a 302 response but did not > concurrently > introduce the administrative tools necessary in order to > specify when a 302 > response should be returned. > > The redirect draft helps to address this deficiency but > unless there is a > compelling reason to do so, it should address this deficiency in the > simplest manner possible, preferably only using the tools provided by > HTTP/1.1. > > The argument has been made that the tools introduced in the > redirect draft > constitute the first step in a series of additional > extensions that will be > made in the future. For example, the Delta-V group has > certain ideas about > how to use MKRESOURCE. While HTTP has a rich tradition of > enabling future > extensions it has always wisely chosen in the short term to > limit itself to > immediate needs only while ensuring that future expansion is possible. > > Hence the test for the redirect draft's success should be > only how well it > addresses the immediate needs of redirect resources and not > how well it > addresses the shifting needs of various future proposals. > > The current functionality of the redirect resource is very > simple, specify a > resource that, by default, will return a 302 (found) response > to a specified > target resource. > > There does not appear to be any compelling reason why the > creation of a > redirect resource should require anything beyond a single > header on the > creation request to specify the URI of the target resource. > The use of a > body to create a redirect resource is clearly unnecessary. > This is not to > say that it may not prove to be necessary in the future. > However WebDAV, in > particular, has set a precedent for how to deal with this > sort of situation > that I believe would well serve the redirect spec. > > In the COPY/MOVE methods we use a single destination header, > rather than a > body, to specify where the results of the method are to > appear. One can > imagine a number of reasons why one would want to have a more > powerful way > to specify the destination of the method. For example, one > might want to > specify multiple destination URIs in order to use a single > round trip to > cause multiple COPY/MOVE's. HTTP's header format is not well > suited for this > sort of extension and WebDAV's definition of the destination > header wisely > does not allow for it. Rather WebDAV specifies that a body > MAY be included > in a COPY/MOVE method but is to be ignored if not understood. > This provide > for a very powerful extension mechanism. For example, imagine > one wanted to > issue the COPY/MOVE to multiple destinations but one wasn't > sure if the > source supported this feature. Rather than wasting a round > trip finding out > if the source supports the feature one could put a single > destination in the > destination header and then use the body to specify the rest of the > destinations. If the resource supports the extension then all > destinations > will be COPY/MOVE'd to. If the resource doesn't support the > extension then > at least one copy will be issued and the client will realize > that the rest > didn't occur (because the resource ignored the body) through the 207 > response. If, on the other hand, one only wanted the > COPY/MOVE to proceed if > the resource understood the multiple destination extension then the > COPY/MOVE could be issued without a destination header, just > with a body. > Resources that didn't support the extension would fail the > request due to > the absence of the destination header thus ensuring that only > resources that > understood the extension will actually execute the method. > > One could rightfully argue that this is an unnecessary > complication. Why not > start with a body that allows extension in the first place? > The counter > argument is that one should always start with as minimal > functionality as > possibly and only expand, grudgingly, as required. A header > is much easier > to process than a body and so clearly is the simplest > mechanism available. > > This line of reasoning is especially compelling in the > context of redirect > resources. Given the obvious utility of redirect resources to all HTTP > systems, not just WebDAV, it is incumbent upon the redirect > spec to cleave > as closely as possible to the base HTTP system and require as > few extensions > from it as possible. > > Therefore I believe that the current proposal, which requires the > introduction of a full XML processing system just to handle a simple > redirect resource is unsupportable. As such I move that > whatever design is > chosen for creating a redirect resource it MUST NOT include > the use of a > request body. > From w3c-dist-auth-request@w3.org Thu Feb 24 01:00:52 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11393 for <webdav-archive@odin.ietf.org>; Thu, 24 Feb 2000 01:00:52 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id AAA06133; Thu, 24 Feb 2000 00:56:15 -0500 (EST) Resent-Date: Thu, 24 Feb 2000 00:56:15 -0500 (EST) Resent-Message-Id: <200002240556.AAA06133@www19.w3.org> Message-ID: <7DE119D3D0E15543874F7561EECBDBED02619E65@BEG.platinum.corp.microsoft.com> From: Yaron Goland <yarong@Exchange.Microsoft.com> To: "'Slein, Judith A'" <JSlein@crt.xerox.com>, w3c-dist-auth@w3.org, "'yaron@goland.org'" <yaron@goland.org> Date: Wed, 23 Feb 2000 21:55:34 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Yaron.Redirect.NoPropsIn207 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/4143 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Agreed. BTW 302_AND_MULTISTATUS in http://www.ics.uci.edu/pub/ietf/webdav/protocol/issues.html identifies this problem so we will make sure to address it when WebDAV goes up for draft. > -----Original Message----- > From: Slein, Judith A [mailto:JSlein@crt.xerox.com] > Sent: Wed, February 16, 2000 10:05 AM > To: Yaron Goland; w3c-dist-auth@w3.org > Subject: RE: Yaron.Redirect.NoPropsIn207 > > > As long as we provide the location and resource type > information somehow, I > don't care how. So I'd be fine with adding a location XML element and > refresource XML element to the response XML element as you propose. > > Note that this is already an issue for RFC 2518 (well, at > least the need for > the location information), since whether or not you can > create redirect > references, HTTP redirects can be encountered while > processing a WebDAV > collection. So whatever solution we end up with, it needs > eventually to be > incorporated into RFC 2518. > > -----Original Message----- > From: Yaron Goland [mailto:yarong@Exchange.Microsoft.com] > Sent: Friday, February 11, 2000 2:51 AM > To: 'w3c-dist-auth@w3.org' > Subject: Yaron.Redirect.NoPropsIn207 > > > > The third sentence of the third paragraph of section 7 > currently reads: > "Since a Location header and Redirect-Ref header cannot be > returned for each > redirect reference encountered, the same information is provided using > properties in the response elements for those resources." > > As discussed in Yaron.Redirect.NoWebDAV#3 we should not be > using WebDAV > properties in the redirect draft. Therefore I move that this > sentence be > changed to read: "Following the conventions of the 207 > (Multi-Status) format > the equivalent of the redirect-ref and location header are > included inside > the response body." > > The fourth sentence of the third paragraph of section 7 > currently reads: > "The DAV:location pseudo-property and the DAV:resourcetype > property MUST be > included with the 302 status code." > > First, the use of a pseudo-property violates the integrity of > the prop XML > element of a multi-status response. One can today write a > general tool that > can process any multi-status response and draw property > information from it. > Such a tool need not even understand the particular context > in which the > multi-status was generated. The use of a "pseudo-property" > violates this > integrity be listing a value in a prop element, thereby > stating it is a > property, when it is in fact not. > > Second, it is almost always a bad idea to imply information > rather than > stating it. By requiring that the resourcetype property be > included you are > expecting that the client will understand that because the > response is a 302 > and because a Apply-To-Redirect-Ref header was not included > and because the > resource type is redirect resource therefore this is a blind > 302 response. > This is a lot of inferring to do. In addition the > resourcetype of a resource > could potentially be quite large. As such it is generally > better to create a > dedicated piece of information which states, exclusively and > uniquely that > the 302 is a blind 302 and leave it at that. > > As such I move that both the DAV:location "pseudo-property" and the > resourcetype property be banned for the uses stated in the > above mentioned > sentence. > > I move that location information be returned in a location XML element > included in the response XML element. > I move that the Redirect-Ref header information be included > in a refresource > XML element also included in the response XML element. > > Based on the previous proposals I also move that the previously quoted > sentence be changed to read: "The location and refresource > XML elements MUST > be included with the 302 status code returned in a response > XML element in a > 207 (Multi-Status) response." > > The fifth sentence of the third paragraph of section 7 > currently reads: > "This necessitates an extension to the syntax of the > DAV:response element > that was defined in [WebDAV]. The extension is defined in Section 14 > below." > > This sentence either states something obvious or unnecessary, > I can't figure > out which. Regardless, it isn't needed. As such I move that > it be deleted. > > The third paragraph of section 7 is not necessary if my > previous proposals > in this point are adopted therefore I move that it be deleted. > > The fourth paragraph of section 7 provides suggestions for > future changes to > the WebDAV standard. I really dislike language like this as > it has no place > in a standard. If changes are needed to the base WebDAV > specification then > put out a posting to the mailing list so they can be added to > the issue list > for consideration when WebDAV goes to Draft. But please leave > them out of > the standard. Standards are really not the proper forum for > editorializing. > As such I move that this paragraph be deleted. > > Section 7.1 of the specification basically just restates RFC > 2518. Rather > than clarifying the issue it just confuses the reader by > forcing them to ask > themselves what was so subtle in understanding the WebDAV > spec that this > paragraph was necessary. BTW, one should contrast section 7.1 > with section > 7.2. 7.2 points out a real subtly in the design of WebDAV and redirect > resources that needs to be called out to implementers. I do > not believe that > 7.1 meets the quality bar set by 7.2. Therefore I move that > section 7.1 be > deleted from the specification. > From w3c-dist-auth-request@w3.org Thu Feb 24 01:40:56 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA13943 for <webdav-archive@odin.ietf.org>; Thu, 24 Feb 2000 01:40:56 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id BAA06541; Thu, 24 Feb 2000 01:36:45 -0500 (EST) Resent-Date: Thu, 24 Feb 2000 01:36:45 -0500 (EST) Resent-Message-Id: <200002240636.BAA06541@www19.w3.org> Message-ID: <7DE119D3D0E15543874F7561EECBDBED030B53DA@BEG.platinum.corp.microsoft.com> From: Yaron Goland <yarong@Exchange.Microsoft.com> To: "'Slein, Judith A'" <JSlein@crt.xerox.com>, w3c-dist-auth@w3.org Date: Wed, 23 Feb 2000 22:35:52 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Yaron.Redirect.Sec4LastPar Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/4144 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list The term "blind response" is meant to convey the idea that the redirect resource, once it determined that there isn't a pass-through header, blindly, without any thought, responds with a 302. I introduce the "blind response" phrase to pull away from the "automatic response" phrase because the "automatic response" phrase gives me the idea that rather than return a 302 the resource will actually act as a sort of proxy for the request and forward it itself to the target and return the response. I'm just trying to avoid confusing the reader. > -----Original Message----- > From: Slein, Judith A [mailto:JSlein@crt.xerox.com] > Sent: Mon, February 21, 2000 11:33 AM > To: Yaron Goland; w3c-dist-auth@w3.org > Subject: RE: Yaron.Redirect.Sec4LastPar > > > In a number of your comments, you suggest that we use the > expression "blind > response" to characterize the 302 that you get back from a redirect > reference resource. Can you say more about what you are > trying to convey > with "blind"? In this message, it looks as if it is supposed > to contrast > with the 302 you would get back from a > non-redirect-reference-resource. How > is one of these responses more blind than the other? Or > perhaps I'm just off > on the wrong track altogether. > > Thanks. > > --Judy > > -----Original Message----- > From: Yaron Goland [mailto:yarong@Exchange.Microsoft.com] > Sent: Friday, February 11, 2000 2:47 AM > To: 'w3c-dist-auth@w3.org' > Subject: Yaron.Redirect.Sec4LastPar > > > > The last paragraph of section 4 currently reads: > > Since a redirect reference resource is a resource, it can > have its own > properties and body, and methods can be applied to the reference > resource as well as to its target resource. The > Apply-To-Redirect-Ref > request header (defined in Section 11.2 below) is provided so that > referencing-aware clients can control whether an operation is > applied to > the redirect reference resource or to its target resource. > The Apply- > To-Redirect-Ref header can be used with most requests to redirect > reference resources. This header is particularly useful with > PROPFIND, > to retrieve the reference resource's own properties. > > Given the numerous changes I request in my comments the > previous description > is no longer accurate. I also felt that it didn't provide a > sufficiently > broad overview of the total functionality provided by > redirect resources. > Below I provide several paragraphs that I suggest replace the > previous one: > > Redirect resources are resources and thus have their own > state. However the > default response of a redirect resource to all methods is a > 302 (Found). A > mechanism is needed that instructs the redirect resource to > handle a method > directly rather than blindly responding to it with a 302 (Found). The > Apply-To-Redirect-Ref request header (defined in Section 11.2 below) > provides such a mechanism. > > For example, if a user issues a PUT request without the > Apply-To-Redirect-Ref request header then the redirect > resource will respond > with a 302 (Found). However, if the redirect resource > supports PUT and if > the requestor is properly authorized then a PUT issued to a redirect > resource with a Apply-To-Redirect-Ref header will result in > the body of the > PUT request being stored for future response to a GET > request, assuming the > GET has a Apply-To-Redirect-Ref header. > > Please note that it is perfectly legal for the response to a > request to a > redirect reference resource with the Apply-To-Redirect-Ref > header to result > in a 302 (Found). In this case the 302 (Found) will not be a > blind response > but rather will be the correct result of the method. Also > note that such a > response would not include a redirect-ref header. > From w3c-dist-auth-request@w3.org Thu Feb 24 01:57:19 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15336 for <webdav-archive@odin.ietf.org>; Thu, 24 Feb 2000 01:57:19 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id BAA06729; Thu, 24 Feb 2000 01:53:11 -0500 (EST) Resent-Date: Thu, 24 Feb 2000 01:53:11 -0500 (EST) Resent-Message-Id: <200002240653.BAA06729@www19.w3.org> Message-ID: <7DE119D3D0E15543874F7561EECBDBED02619E67@BEG.platinum.corp.microsoft.com> From: Yaron Goland <yarong@Exchange.Microsoft.com> To: "'Slein, Judith A'" <JSlein@crt.xerox.com>, w3c-dist-auth@w3.org, "'yaron@goland.org'" <yaron@goland.org> Date: Wed, 23 Feb 2000 22:52:34 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Yaron.Redirect.S10 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/4145 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list The main contention in Judy's comments is that implementing the section 10 rules isn't that bad because you can always do a hash look up first on a name and if you don't get a hit then you can begin the segment by segment walk. I disagree with the assessment that the cost is trivial. Every single time a URL mis-hits the server will be forced to spend time walking all of its segments in order to figure out if the URL may point to a redirect resource. The cost of processing a bogus URL has gone from O(1) to O(N). That makes it very easy to use bogus URLs as a denial of service attack. This all begs the issue, BTW, of the fact that the design means that processing URLs correctly pointing to redirect resources will cost O(N). All this having been said, as I indicate below, I understand why the authors want to make redirect resources behave as they have specified and I am sympathetic to their goals. I think the best compromise is for us to create two types of redirect resources (created by two different methods). One type is a simple HTTP redirect resource. No fancy namespace rules. No section 10 behavior. All it does is blindly return a 302 to a certain value, that is it. It doesn't matter if it is in a WebDAV namespace or not. It just returns a 302. Then we create a complex HTTP redirect resource with section 10 behavior. People who want to take on the O(N) costs associated with it are free to do so. But let's not penalize WebDAV implementers who just want a simple 302 by forcing a O(N) solution on them. As for my comment regarding paragraph 3 of section 10, I agree with Judy's comment that my analysis is flawed and so remove my comment. Yaron > -----Original Message----- > From: Slein, Judith A [mailto:JSlein@crt.xerox.com] > Sent: Mon, February 21, 2000 12:25 PM > To: Yaron Goland; w3c-dist-auth@w3.org > Subject: RE: Yaron.Redirect.S10 > > > Comments interspersed in <js></js> tags. > > -----Original Message----- > From: Yaron Goland [mailto:yarong@Exchange.Microsoft.com] > Sent: Friday, February 11, 2000 2:54 AM > To: 'w3c-dist-auth@w3.org' > Subject: Yaron.Redirect.S10 > > > > Section 10 of the redirect spec requires that given a HTTP URL > http://foo/bar/blah <http://foo/bar/blah> as the request-URI > of a method if > http://foo/ <http://foo/> or http://foo/bar/ <http://foo/bar/> are > redirect resources then the request must be redirected to the > locations > specified by those redirect resources with the remaining part of the > request-URI appended to the redirection location. This means > that when a > HTTP URL is submitted the server must examine each segment of > the URL and > determine if any of those segments point to a redirect > resource. This means > that every time a URL is submitted a minimum of N lookups > must occur where N > equals the number of segments of the URL. This has a > devastating effect on > efficiency. > > <js> I don't think it's quite that bad. The server would > probably first > check whether it has a mapping for the whole URI. Only if it > doesn't would > the server have to start checking subpaths. So it's more > complicated code, > but not a dramatic effect on efficiency. </js> > > In the current HTTP system one can implement a HTTP URL to > resource mapping > mechanism in two steps. > > Step 1 - Look up the name and get back the internal pointer > to the resource. > > Step 2 - Use internal point to submit method to resource. > > Section 10 changes this, for all HTTP URL namespaces that > have redirect > support, to be: > > For (segment 1 to segment N) { > If (typeof(segment) == redirect) { > Issue 300 > } > } > Segment(Method) > > The section 10 requirement would be the first time we ever > required that the > processing of a URL to resource mapping was dependent on the > state of any > resource other than the target. This seems like a really bad > precedent to > set as it significantly increases the complexity and cost of > handling HTTP. > > In addition this requirement makes it very difficult and extremely > inefficient to distribute one's namespace. If one wants to > put http://foo/ > <http://foo/> on one server, http://foo/bar <http://foo/bar> > on another > server and http://foo/bar/blah <http://foo/bar/blah> on a > third server then > any requests to http://foo/bar/blah <http://foo/bar/blah> > MUST be sent to > the two others servers in order to figure out if any of them > is a redirect > resources. This is an enormous burden to put on implementers > wishing to > distribute their namespace. (Note that in a WebDAV consistent > namespace > there would be a similar requirement but it would only apply to the > immediate parent and so at most one other system, not N other > systems as the > redirect draft requires.) > > <js> Again, you would first attempt to resolve the URL in the > usual way, and > only if that fails would you have to start checking sub-paths > instead of > rejecting the request out of hand. </js> > > This all having been said, the motive behind introducing the > section 10 > behavior is clear and reasonable. The desire is to enable > redirect resources > to create the same experience for the end user as a bind > resource. However > here we run into an issue that is peculiar to HTTP. HTTP's resource > namespace is not consistent. Even the WebDAV namespace, if non-WebDAV > resources are included, is not required to be consistent. Namespace > consistency brings with it too high a cost in terms of > coordination and > complexity to be mandatory. > > Therefore, at minimum, we require a type of redirect resource > that does not > have the section 10 behavior. This resource would expose the > behavior we see > today in various HTTP servers that allow their users to create 300 > resources. Therefore I move that a type of redirect resource > be specified in > the redirect spec that does not have section 10 behavior. > > That having been said I am sympathetic to the desire to have > the section 10 > rules. They certainly replicate the behavior seen today in > many systems. As > such I will not object to the inclusion of a redirect > resource with section > 10 behavior in the redirect spec. However I do move that the > authors must > address the issue of what happens when the redirection > location isn't a HTTP > URL. How do we handle a request for http://foo/bar/blah > <http://foo/bar/blah> when http://foo/bar <http://foo/bar> > is a redirect > resource to ftp://itsy/bitsy <ftp://itsy/bitsy> ? > > <js> We haven't really discussed this type of case, and you > are right that > we have to address it somehow. In the particular example you > give, we could > just have the server follow the rules in section 10, and > respond with a 302 > and Location: ftp://itsy/bitsy/blah <ftp://itsy/bitsy/blah> . > The client > would then have to figure out whether there is anything in > ftp corresponding > to the method in its original request. </js> > > Paragraph 3 of section 10 reads: > > Note: If the DAV:reftarget property ends with a "/" and the > remainder of > the Request-URI is non-empty (and therefore must begin with a > "/"), the > final "/" in the DAV:reftarget property is dropped before the > remainder > of the Request-URI is appended. > > This behavior is in contradiction to both RFC 2518 and RFC > 2616. Resources > that end with a "/" are currently considered different > resources from those > that do not end with a "/". This is exactly the same issue > brought up in > Yaron.NoSlash ( > http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/0069.html > <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/ 0069.html> ) and I would love to see option 2 as listed there adopted. Failing that the authors must adopt option 1 and change the draft. Either way, I move that the authors must address this issue based on the requirements placed in Yaron.NoSlash. <js> I don't think this does raise the same issue. All we are doing here is making sure that you don't end up with a URL that has 2 consecutive slashes in the middle somewhere. </js> From w3c-dist-auth-request@w3.org Thu Feb 24 01:59:59 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15518 for <webdav-archive@odin.ietf.org>; Thu, 24 Feb 2000 01:59:59 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id BAA06837; Thu, 24 Feb 2000 01:55:47 -0500 (EST) Resent-Date: Thu, 24 Feb 2000 01:55:47 -0500 (EST) Resent-Message-Id: <200002240655.BAA06837@www19.w3.org> Message-ID: <7DE119D3D0E15543874F7561EECBDBED030B53DC@BEG.platinum.corp.microsoft.com> From: Yaron Goland <yarong@Exchange.Microsoft.com> To: "'Slein, Judith A'" <JSlein@crt.xerox.com>, w3c-dist-auth@w3.org, "'yarong@goland.org'" <yarong@goland.org> Date: Wed, 23 Feb 2000 22:55:07 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Yaron.Redirect.ClientUpdate Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/4146 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list We can either let them use MKREF to update it or we can introduce a UPDATEREFTARGET method. Lately I have been leaning to introducing new methods in order to simplify the standard text. Re-using existing methods for related functionality has proven to make specs harder to read. For example, in my GENA spec I specified that SUBSCRIBE can be used with a NT header to create a subscription and with a Subscription-ID header but no NT header to renew a subscription. The result is that I had to put in some fairly confusing language to explain what to do if a request has both a NT and a Subscription-ID header. After that experience I just introduce a RESUBSCRIBE method to simplify things. Of course, this isn't a perfect solution since the more methods you have the more things people have to put on their slides when they explain WebDAV. =) > -----Original Message----- > From: Slein, Judith A [mailto:JSlein@crt.xerox.com] > Sent: Mon, February 21, 2000 12:52 PM > To: Yaron Goland; w3c-dist-auth@w3.org > Subject: RE: Yaron.Redirect.ClientUpdate > > > As long as we have the DAV:reftarget property, the obvious > thing to do is > allow clients to update its value. If you want to get rid of > that property, > as it seems you do from NoWebDAV#3, then I suppose we would > need something > like an UPDATEREFTARGET method. > > --Judy > > -----Original Message----- > From: Yaron Goland [mailto:yarong@Exchange.Microsoft.com] > Sent: Friday, February 11, 2000 2:57 AM > To: 'w3c-dist-auth@w3.org' > Subject: Yaron.Redirect.ClientUpdate > > > > Maybe I just missed it but there doesn't seem to be any way > to update the > target of a redirection resource without deleting it. I move that a > mechanism be provided that enables the target of a > redirection resource to > be updated without having to delete the resource. > From w3c-dist-auth-request@w3.org Thu Feb 24 03:01:11 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24351 for <webdav-archive@odin.ietf.org>; Thu, 24 Feb 2000 03:01:10 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id CAA08833; Thu, 24 Feb 2000 02:56:39 -0500 (EST) Resent-Date: Thu, 24 Feb 2000 02:56:39 -0500 (EST) Resent-Message-Id: <200002240756.CAA08833@www19.w3.org> Message-ID: <7DE119D3D0E15543874F7561EECBDBED02619DE6@BEG.platinum.corp.microsoft.com> From: Yaron Goland <yarong@Exchange.Microsoft.com> To: "'Geoffrey M. Clemm'" <geoffrey.clemm@rational.com>, w3c-dist-auth@w3.org, "'yaron@goland.org'" <yaron@goland.org> Date: Wed, 23 Feb 2000 23:56:00 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Subject: An analysis of the proposal to place locks on URIs rather than re sources Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/4147 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list The following mind blowingly long nightmare of a post was never intended to be posted. The reason is that I find that dropping 3.5 page long posts on WG mailing lists is a really great way to make people's eyes glaze over. However I still write up the really long posts because I find that it helps me ensure that my own arguments are at least internally consistent. It also allows me to project where arguments about an issue are likely to go. I then use those projections to head off certain threads before they start and to generally direct the discussion to the conclusion I would like to see. I knew reading all that Plato would help some day. However the changes in my employer are sucking away all my time. As such I am dumping this nightmare on the group mostly because I know that Geoff will read it and then call me up and ask lots of questions. I suppose I could just have sent this to Geoff but there are a number of people on the list who get really annoyed when I do that. They claim that they actually read these outrageous monster posts. I think they are daft but I find it best not to annoy the truly daft. As such, without further ado, my thoughts on Geoff's original locking proposal. Execute summary: The proposal to put locks on URIs rather than resources introduces URIs as first class objects into HTTP that are able to do things like answer methods. This introduces a number of complications and contradictions into the HTTP object model. As such, in order to best maintain the HTTP object model and to enable it to be both robustly expressed and extended one must understand HTTP in terms of the state of the resources. Part of the state of a resource is the set of URIs under which it is accessible. A write LOCK request is then understood as asking, in part, that one member of that set of URIs only be removable by the lock owner. Long Winded Examination of Proposal: I oppose the proposal that locks be placed on URIs rather than on resources. There is no such thing as a URI in the sense that URIs do not have addressable existences. Only resources can be addressed and therefore locks can only exist on resources. To attempt to turn URIs into something that can have state one introduces an endless recursion. If state can be associated with a URI then one must be able to access that state. Of course that means one needs a URI to get to the state of the first URI. But since URIs can have state that means that the URI that points to the URI with state can itself have state which means one needs a URI to point to the URI that points to the URI with state and so on. Let's examine a manifestation of this problem. In his letter below Geoff states that the proposal to associate locks with URIs rather than resources would result in a situation where "...a LOCK request *never* requires a lock token". I though hard about this, trying to understand exactly what it meant. Below I lay out my thinking process so that if I have misunderstood the proposal my error can be found and corrected. Imagine user U takes out a depth 0 lock on collection C. Collection C has no children. The ramification is that no one but U may add a new child to C. User A then shows up and wants to create a new resource with the URL C/R. Before creating the resource, however, A would like to first reserve the name C/R. To this end A takes out a lock on C/R. To someone thinking in terms of the current locking system we appear to have reached a contradiction. No one but U may add a child to C but Geoff has clearly stated that A can lock C/R without having to present a lock token. What has happened is that the example illustrates a critical but subtle difference between the two proposals. In the old system locks are on resources. Therefore for A to lock the name C/R, A MUST have locked some resource which claims to be accessible through C/R. This is where lock null resources came in. Therefore the act of locking C/R created a new resource, this new resource is a child of C, no one but U may add a child to C, therefore A's lock request would be denied. But in the new proposal locks aren't on resources, they are on URIs. Therefore when A locks C/R it is not locking a resource, it is locking a name. Names aren't members of collections, resources are. Therefore A can lock C/R without running afoul of U's lock on C because C/R, even though it is locked, is still not a member of the collection. When A will run into trouble is when it attempts, through a COPY, MOVE, PROPPATCH, PUT, MKCOL, etc. to associate the URL C/R with a resource. By associating a resource with C/R A will cause that resource to become a member of C. Of course U has reserved the right to create new members of C, therefore A's request will be rejected. But this analysis seems to explain Geoff's statement that in the new locking system one never needs a lock token to take out a lock. The previous line of reasoning seems to produce at least two major issues. The first issue is that I believe that a lock of depth 0 on a collection should reserve both the right to add new members and the exclusive right to choose the name of the new members. That means that when U locked C not only should it be impossible for anyone but U to add a new resource to C but U should also have the exclusive right to choose whatever name it wants for that new member. Therefore I would argue that A's lock on C/R should fail because the act of allowing A to take out the lock would restrict U in his choice of names for new resources of C. That is, C couldn't decide to create a new child of C and call it C/R because the name was locked by A even though C had locked C. The trivial solution to this issue is to state that a depth 0 lock on a collection actually locks both the collection and any names which have the collection's name as a base. Let us now look at an example where this solution causes serious problems. Let us imagine again that we have a collection C, but this time it already has a child resource called C/X. User U takes out a depth 0 lock on C. Under the old locking system this would mean that no one but C could delete C/X but anyone could, for example, issue a PUT against C/X. U's lock only covered the adding and removing of members to C, not changing their state. But under the new system user Z could not issue a PUT against C/X if U has locked C with a depth 0 lock. The reason is that in order to reserve for U the exclusive right to choose the name of the children of C it was necessary to lock all names that began with C, including C/X. However the very definition of the new proposal is that a lock is on the URI, not the resource. Therefore the act of locking all URIs that began with the segment C meant that the resources referred to by those children where themselves locked. That is, by locking C we are forced to lock C/X in order to reserve for C the right to control the name C/X. But in locking C/X we removed the right for anyone but U to issue a PUT against C/X. The point here is extremely subtle and I apologize for my ham fisted attempts to tease it out. What is happening is that the new proposal actually calls for there to be two different types of locks. The first type of lock is the one on the URI C. This is the lock that prevents anyone from issuing PUT, DELETE, PROPPATCH, etc. against C. The second type of lock is the ones on the URIs that begin with the segment C. This lock only prevents DELETE and if the URI isn't associated with a resource, PUT/MKCOL/COPY/MOVE/etc. The general rule in protocols is that there are only three numbers, 0, 1 and infinity. That we need 2 different lock types to cover this scenario therefore makes me nervous because 2 lock types will almost certainly mean we actually need an infinite number of lock types to cover a variety of different situations. The second issue has to do with the problem of having state on URIs. Let us use the previous example to illustrate the problem. U has locked C. A has locked C/R. No resource is associated with C/R. So under the new proposal, everything is fine. However, what happens when someone performs a PROPFIND, depth infinity, on C? Do they see C/R? I imagine the answer is no because C/R, given the reasoning before, is not a member of C. C/R will only become a member of C when a resource is associated with C/R. However, if U were to attempt to issue a PUT against C/R then U would get a lock error since the name C/R is locked by A and therefore only A may associate a resource with C/R. Of course A can't associate a resource with C/R because of U's lock on C. But that isn't even the problem I'm worried about. Deadlocks are an inherent problem in any distributed system. What worries me is how do we figure out which URIs under C are locked? You can imagine this to be a very common act for an administrator to want to do. Today the way we handle this is through a recursive PROPFIND. The reason this works is that one can only lock resources, all resources which are bound to a name with C as a segment are children of C, all children of C show up in a recursive PROPFIND. It is because locks are on resources that we can always discover what under C is locked. The new proposal, however, places locks on the URI, not the resource. As such the PROPFIND can't tell you that C/R is locked because C/R is not bound to a resource and only resources show up in PROPFIND. This is then the problem of having state on URIs. Because the URI C/R has its own state, it is locked, we need a way to find that out. One way to do this is to issue a LOCK request against C/R. But what does it mean to issue a method against C/R? Methods are issued against resources yet there is no resource associated with C/R, therefore who answers the method call? In the object model I previous proposed (http://lists.w3.org/Archives/Public/w3c-dist-auth/1999JulSep/0020.html) I suggested that the resource that would handle the method sent to C/R is the universal NULL resource. But that answer can't apply here. The reason is that the universal NULL resource is, well, universal. It doesn't have any state of its own. Here we need state, that state is that the name C/R is locked. But again, the lock is on the name, not the resource. There is no resource. So who answered the method sent to C/R with a LOCK error? In HTTP the only thing that answers methods are resources but there is no resource here, just a name. The result is that now we need some way of talking to "names". Without this mechanism there is no way to ask questions like "Which names under C are locked?". This means that URIs are now resources. They must be, otherwise they couldn't answer methods. If they can't answer methods then we can't get lock errors. Therefore they must be resources. At least by making URIs resources we can ask questions like "which URIs are locked". However I don't look forward to PROPFIND responses since they will contain every single possible name. After all, PROPFIND returns all the resources that are members of C. All URIs are resources. Therefore all possible URIs under C are members of C and therefore will be returned by PROPFIND. Of course, URIs can't be resources. Because the whole new locking proposal is that locks aren't on resources at all. Ack. In conclusion (yes, it's over!!!!!) I believe that in order to best maintain the HTTP object model and to enable it to be both robustly expressed and extended one must understand HTTP in terms of the state of the resources. Part of the state of a resource is the set of URIs under which it is accessible. A LOCK request is then understood as asking that one member of that set of URIs not be removed from the table during the duration of the LOCK. In other words, resources have state, URIs don't. Yaron > -----Original Message----- > From: Geoffrey M. Clemm [mailto:geoffrey.clemm@rational.com] > Sent: Thu, December 30, 1999 2:33 PM > To: w3c-dist-auth@w3.org > Subject: Re: Creating a lock-null in a locked collection > > > > As an addendum to Yaron's response, I'll note that there is a proposal > that WebDAV locking is better understood as locks on URL's rather than > on resources. This not only makes the current WebDAV locking behavior > easier to motivate (e.g. a resource "loses" a lock after a move > because it is no longer identified by the locked URL), but removes the > need to define a "lock null resource". > > One effect of this proposal would be that the answer to Joe's question > would change, i.e. that a LOCK request *never* requires a lock token. > A LOCK request can fail (such as when it would collide with > an existing > exclusive lock), but no failure would be resolvable through > the addition > of a lock token. > > FYI, the current state of the lock proposal is: > > A lock can be placed on a URL with a LOCK request. This URL is called > the "lock base". If the lock is Depth:N, then a lock is induced on > any URL that consists of the lock base extended by N or fewer > segments. Only an authorized holder of a lock token for a locked URL > can modify either the state of the resource identified by the URL, or > which resource is identified by the URL. A URL MAY NOT be locked > with two exclusive locks with the same locktype. > > Cheers, > Geoff > > From: "Yaron Goland (Exchange)" <yarong@Exchange.Microsoft.com> > > The depth 0 lock controls the ability to add level 1 > children to the > collection. > A lock null resource is a resource and hence is a member > of whatever > collections it exists within. > Therefore to create a lock null resource as a level 1 > child of a collection > with a depth 0 lock one must have the depth 0 lock. > > In other words, yes, you must submit the token on the LOCK > on /foo/bar. > > Yaron > > > -----Original Message----- > > From: Joe Orton [mailto:joe@orton.demon.co.uk] > > Sent: Thu, December 30, 1999 6:45 AM > > To: w3c-dist-auth@w3.org > > Subject: Creating a lock-null in a locked collection > > > > > > I have an depth 0 write lock on /foo/. If I do LOCK /foo/bar > > to create a > > lock-null resource, do I need to submit the locktoken > for /foo/ in the > > LOCK request? Or only in the PUT to /foo/bar later? > > > > (Or is it decided that lock-null resources are going to go away?) > > > > joe > > > From w3c-dist-auth-request@w3.org Thu Feb 24 03:22:38 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24514 for <webdav-archive@odin.ietf.org>; Thu, 24 Feb 2000 03:22:36 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id DAA09306; Thu, 24 Feb 2000 03:14:06 -0500 (EST) Resent-Date: Thu, 24 Feb 2000 03:14:06 -0500 (EST) Resent-Message-Id: <200002240814.DAA09306@www19.w3.org> Message-ID: <7DE119D3D0E15543874F7561EECBDBED02619DFA@BEG.platinum.corp.microsoft.com> From: Yaron Goland <yarong@Exchange.Microsoft.com> To: "'Eric Sedlar'" <esedlar@us.oracle.com> Cc: w3c-dist-auth@w3.org, "'yaron@goland.org'" <yaron@goland.org> Date: Thu, 24 Feb 2000 00:13:24 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF7E9E.C2891BE2" Subject: RE: Your proposal Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/4148 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF7E9E.C2891BE2 Content-Type: text/plain (Note: I found this in my drafts directory, figured I would send it out) See below [WARNING: O.k. I admit it, Eric's letter sent me down memory lane. So this e-mail is seriously long. However if you are interested in some of the history behind how XML ended up the way it is, how XML ended up in WebDAV and some of the work I and others at MS did to make WebDAV actually happen, read on!] -----Original Message----- From: Eric Sedlar [mailto:esedlar@us.oracle.com] Sent: Mon, January 03, 2000 4:33 PM To: Yaron Goland Cc: w3c-dist-auth@w3.org Subject: Re: Your proposal Now we get into our areas of disagreement. * I mentioned HTTP as having lousy performance WITHIN A SINGLE PROCESS. I guarantee you that a function call is much cheaper than formatting the request into a stream, writing into a loopback socket, reading the result back, parsing it, and then the reverse. Another example is SQL access to properties of a resource. If I want to query the resource data efficiently, I need to be able to treat properties of the resource as "virtual data", not make a series of function calls on each item in the query set. If I want to write a servlet that takes an HTML form input and changes WebDAV properties, I definitely want a functional API (in Java). Everyone knows that SMB sucks and is incredibly chatty. As far as HTTP performance, it mostly depends on the amount of functionality you can pack into one request. If I have to issue a GETLOCKED name request followed by a bunch of other requests to get all of the state of a particular resource, HTTP will suck. My point was that the WebDAV model is actually bigger than HTTP--other data access systems (like SQL and XML technologies) should also be able to manipulate the data easily. <Yaron> I certainly wouldn't want someone accessing a DB on their local machine to have to run their requests through DAV. What a waste, a full trip through the protocol stack just for a local request? Of course they should be able to work through SQL and other mechanisms. In fact, in fulfilling my role as the lead author of the WebDAV specification and the chief WebDAV evangelist at Microsoft I was worked hand-in-hand with the ODBC/OLE DB/ADO teams at Microsoft to ensure that the model we were putting together would be easily accessible through their APIs. That is why, for example, OLD DB 2.5 has a native WebDAV provider. This is what was used to implement the WebDAV support in Web Folders. I also worked hand-in-hand with the SMB folks at Microsoft to make sure that the WebDAV model was such that we could run WebDAV directly over the file system and at the same time access it through the Win32 file APIs and SMB without any conflicts. That is why Win 2000 is able to ship a native WebDAV implementation that works directly off the file system allowing for simultaneous access by FTP/SMB/WebDAV/Win 32. At the same time I also coordinated with the Exchange group at Microsoft to ensure that the WebDAV model was consistent with POP/IMAP/MAPI. That is why Exchange 2000 (the upcoming release of Exchange) has a full WebDAV implementation that enables you to access your e-mail box simultaneously through POP/IMAP/MAPI/WebDAV. I also coordinated with our Active Directory team to ensure that the WebDAV model was consistent with LDAP/ADSI. I also coordinated with the SQL team to ensure that WebDAV could be easily layered on top of SQL so that one could do direct SQL queries as well as normal work. There are a number of other groups that I also coordinated with but unfortunately I can't release any data about that. But look forward to some interesting uses of WebDAV coming down the line. My favorite current example is pointing Office 2000 against Exchange 2000. Office sees Exchange as just another file store while Exchange sees Office as just another WebDAV client. The result is that you can save your files in your e-mail directories thus having your files automatically replicated and backed up for you. Very cool use of DAV. I think we will see even cooler uses of DAV when DASL starts to get deployed. With DAV/DASL you can control/search your E-mail store, file store, directory or database with the same protocol using the same data model. I have been working for over 3 years to bring this vision to fruition. So obviously I am deeply interested in the issues of enabling access to stores that support WebDAV through many APIs and protocols.. That having been said I disagree with your statement that having to make multiple requests to describe a resource will destroy performance. A properly implemented HTTP server will support pipelining which, as repeated experiments have demonstrated, has equivalent performance to having one big message but with much cleaner protocol semantics. So long as the connection is kept open (default in HTTP/1.1) and the process is not spun down after each request there is no difference between processing one huge message and processing a string of messages that are pipelined in. In fact, in the WebDAV Book of Why I discuss in detail how depth came about and why we used depth instead of just pipelining. It is an interesting story, you will see that while performance was involved, it had nothing to do with the cost of parsing messages. You might want to read that section entitled "<"This is another fine protocol you've gotten me into!">" available in <http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0303.html> http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0303.html. Keep in mind, btw, that the server does need to be a bit smart. For example, it should wait a little bit before processing a message in order to see if the next message can be bundled into a single API call to the underlying system. There are lots of tricks but these tricks are all well known. So it isn't a big deal. </Yaron> * Another reason for making all information about a resource available as properties is using XSL to format an HTML page giving access to all of this data. There is a lot of support for not requiring a lot of programming (ala JSPs or ASPs) to format data within a page. <Yaron> No one I'm aware of is arguing against making the information available through XML. The argument is simply this: Do we get the information through a PROPFIND or do we get it through multiple requests, each of which are free to return XML. My response is that we must do the later because of the need to support content negotiation. In order to keep the WebDAV property model as simple as possible it does not support any form of content negotiation. This means that I can't say "I want the name property in French" or "I want the picture you have stored in this property returned as JPEG." The only way to get this sort of negotiation is through individual method requests. If we only provide these properties through PROPFIND then we dumb DAV down to the level of a static database table and prevent people from developing more intelligent systems. The only real counter argument I see against using multiple methods is the possible performance ramifications but as I argued in the previous paragraph the introduction of pipelining into HTTP/1.1 makes this largely a non-issue. </Yaron> * I don't understand why you think it will be easier to handle protocol extensions on the client side by using additional HTTP methods rather than resources. XML applications are used to ignoring elements that they don't care about--extensibility is one of the key wins of XML vs. traditional OO languages. It allows DOM objects to be passed around multiple areas of the system better. For example, let's say that I have some client library which implements the client side of the HTTP protocol, and allows plugins to that client to access the XML DOM for each resource. I can install a new client plugin to handle new properties that appear in that DOM, but I won't be able to extend the HTTP protocol. HTTP protocol implementation is typically at a lower level of the client or server than properties. <Yaron> The main reason that I believe that adding new methods is easy is that I have implemented a number of XML/DAV systems and it has repeatedly proven simpler to support new methods than new elements. This is mostly because the HTTP model is flat so that I can access things like the method name or a head directly where as with XML I have to navigate through a tree. This is the same logic that leads people to use attributes in XML, which as I argue in the WebDAV book of why is a really stupid thing to do. But I digress. As for ignoring elements, it is funny to hear someone say that XML is used to ignoring elements. I first became involved with XML before it was called XML. I had helped write a proposal called Web Collections that would later be put together with a bunch of other proposals in order to become what we now know as XML. In fact, my boss at the time was Thomas Reardon who was MS's representative to the W3C and the leading proponent both at MS and the W3C for XML. Now a days only the old timers remember the work he did in making XML real but in my estimation without him XML never would have taken off. As such I have been involved in helping with the XML design since day one. One of the problems we ran into with XML when it was first introduced was the question of handling unrecognized elements. At the time the SGML heads had total control over XML much to the anger and dismay of those of us born after the turn of the last century. At the time the SGML heads were arguing hard and fast against have a definition of well formidness. What they wanted to do was to require a DTD be available for all XML documents. These were the same geniuses who argued against the introduction of namespaces. In fact it was their sheer cussedness that prevented us from being able to just name an XML element as a URL. They refused to allow in the forward slash and other characters that would have been necessary to allow URLs in the name of elements. That is where the namespace hack came from. Anyway, I'm digressing. So the SGML heads were arguing that you always had to have a DTD so therefore, naturally, if you had an "unrecognized" element it was an error and you should fail the entire XML document! Those of us from the post-Diluvium age were aghast. Unfortunately Tim Berners-Lee (TBL) was convinced that we had to keep support of the SGML community. I remember getting lectured by Andrew Layman (who hated what the SGML guys were doing as well) about the "millions" of SGML documents out there and the need to work with them. Of course now nobody knows or cares about those ***BLEEP*** SGML documents, but a lot of the really awful crap you see in XML is the result of the deals that TBL made with the SGML guys to keep their support. TBL touches on this topic a little bit in his book. Anyway, the SGML guys were finally argued into accepting the idea of "well formidness" and thus we were freed of needing a DTD. However this left open the question of what to do when you hit an element you didn't recognize. Oh man were there flame fests on that topic. People in the protocol business tend to think of XML as just a tree so for us it is natural to just prune the XML tree at an unrecognized node. But the SGML guys don't see a tree when they see XML, they see a markup language. So, for example, imagine I have the following entry in my XML document "<p>He was a <bold>grand</bold> man!</p>. Now let us imagine that your XML parser supports the <p> tag but doesn't support <bold>. If you just pruned the tree you would end up with "<p>He was a man!</p>". That is clearly not what you want. The result was just a real mess. Some people demanded that you always prune. Some demanded that you only removed the tags but not the text. Some argued that you should have an attribute you would put on each element that would specify what you should do. There never was much of a resolution to the issue. Eventually I just got really pissed off and added what is now the first paragraph of section 14 of RFC 2518 to WebDAV declaring that we would prune any sub-tree whose root we didn't recognize. Man, did we ever catch hell for that! The XML guys told us that we wouldn't be compatible with their XML. That we were creating my own world that wouldn't work with the rest of the XML universe. Oh man, what a bloody mess. So to hear you say that the WebDAV ignore rule (as we called it) is a strength of XML is pretty damn ironic. As for HTTP generally appearing at a lower layer and not being available from the DOM, you may want to check out http://msdn.microsoft.com/xml/reference/scriptref/XMLHttpRequest_object.asp <http://msdn.microsoft.com/xml/reference/scriptref/XMLHttpRequest_object.asp > and http://msdn.microsoft.com/xml/reference/cvbref/IXMLHttpRequest_interface.asp <http://msdn.microsoft.com/xml/reference/cvbref/IXMLHttpRequest_interface.as p> . The links describe the XMLHTTP interface available through IE 5.0's DOM. The first link describes the interface for script programmers (JScript/ECMAScript, VBscript, Python, Perl, etc.) and the second for C/VB programmers. This interface allows you to send and receive generic HTTP messages directly through IE 5.0's DOM. What is really cool about it is that while it can handle arbitrary HTTP messages it is smart so that if you want to send or if you receive a message with an XML body it will automatically detect that and automatically parse out, lode up and pass back a DOM pointer to the contents. So actually HTTP access is as free and ready as XML access, at least in IE 5.0. BTW, massive credit goes to Alex Hopmann who nearly single handedly convinced the IE guys to ship this feature. Hats off to Alex! </Yaron> HTTP request/response parsers are not generic technology like XML parsers are <Yaron> I'm not sure what leads you to this conclusion. For example, as the author of the HTTP over UDP spec I found that HTTP request/response parsers were incredibly generic. This is what made HTTP over UDP so compelling. We could take existing parsers, do a little tweaking and bam, it just worked. In fact I would argue that there is no better proof of the generic nature of HTTP parsers then the existence of WebDAV. We didn't have to do any major work to support WebDAV in our HTTP request/response parsers. HTTP already understood the concept of methods and headers so we were able to use the existing parsers to implement WebDAV. In fact the biggest problem we ran into is that some folks had implemented checks on what methods you could send as an error detection procedure! Sigh... In WinInet we had the problem that the devs, in order to optimize performance, had built a method mapping table that turned the method names into tokens and then moved the tokens around. Unfortunately the tokens were fixed, which meant that WinInet (our HTTP client stack) couldn't handle new methods. But the problem was easily fixed so modern versions of WinInet can handle arbitrary methods. </Yaron> * It sounds like you are arguing against the general trend of making all of your data available via XML, which is counter to the general strategies most technology companies are following now, including Microsoft and Oracle. With your proposal, you are going to render all of the burgeoning XML technology base useless, which is why the WebDAV people built around XML in the first place. <Yaron> I was the one who introduced XML into WebDAV. Bonus points to anyone who remembers the original meeting when I proposed Web Collections (a precursor to XML) to WebDAV. This was the first time WebDAV was introduced to what would become XML. As for Microsoft's XML strategy, that is a whole other story. Because my boss, Thomas Reardon, lead the XML effort at MS for a long time I was actually part of creating our XML strategy. When Adam Bosworth took over XML I ended up having weekly meetings with him just so that we could synch up on Microsoft XML corporate strategy. I also worked with both Andrew Layman and Jean Paoli on XML issues. I still remember the tongue lashing I gave Andrew over fully qualified end tags. It wasn't Andrew's fault, he hated it too, but he was the messenger and I was really angry. Basically the SGML heads forced XML to adopt fully qualified end tags. In the original proposal XML markup looked like <tag>stuff</>. But the SGML heads argued that this didn't make XML readable so we should make the already mind blowingly bloated XML format even more bloated by adding fully qualified end tags, i.e. <tag>stuff</tag>. Yet another fight that they won. As such I can safely assure you that I would not do anything to "render all of the burgeoning XML technology base useless". Having helped birth XML I would certainly be reticent about killing it. After all, infanticide is a messy business. I will admit, however and Jim Whitehead will back me up, that there were plenty of times when I would have have liked to have given XML a severe spanking followed by a good amount of time in the corner. I used to joke about the "XML Jedi Mind Trick." You just wave your hand in front of someone and say "You will use XML". Their eyes loose focus and they repeat in a monotone voice "I will use XML." This helped a lot in early WebDAV adoption. If I couldn't convince someone to adopt WebDAV because of its own merits I would just pull the XML Jedi Mind Trick and they would adopt it because it used XML. After all, if it uses XML it must be cool! There is apparently something indescribably sexy about angle brackets. </Yaron> Is anyone thinking about a thin-client WebDAV implementation (HTML only) running in a browser? I should be able to do stuff like changing RSRs, manipulate directories, etc. with a web app. <Yaron> Thinking? We have already written it! Using XMLHTTP Exchange has written up an entire E-Mail client for Exchange 2000 that speaks WebDAV to their server. The whole thing is written 100% in nothing but script!!!! What is really amazing is that it uses DHTML so the UI looks almost 100% like Outlook, even down to the multiple Outlook views and the Outlook bar. It is seriously cool. I have also written, on my own, a generic WebDAV client library in JScript. Unfortunately I never finished it. Too many other things to do. </Yaron> --Eric Yaron Yaron Goland wrote: I wouldn't accept a blanket statement that HTTP has lousy performance. I have seen it repeatedly beat the pants off all competing systems. For example, we did a speed comparison of a super optimized SMB implementation and DAV in W2K. DAV won hands down. The reason is that SMB, like most protocols of its ilk, is unbelievably chatty. They are basically RPCs rather than protocols. DAV, on the other hand, is extremely optimized. So even though the SMB implementation could process some ridiculous number of messages per second DAV still had better performance because it sent a hell of a lot less messages.As for the use of properties, I assert that there is no difference between executing a GETLOCKEDNAME method and getting the lockedname property in terms of how you write your back end. However, the first is a hell of a lot easier to deal with in terms of specifying and extending the protocol than the second. So the issue isn't one of back end implementation, it is one of front end convenience.In other words, just say NO to live properties. Yaron -----Original Message----- From: Eric Sedlar [ mailto:esedlar@us.oracle.com <mailto:esedlar@us.oracle.com> ] Sent: Monday, January 03, 2000 1:09 PM To: Yaron Goland Cc: w3c-dist-auth@w3.org Subject: Re: Your proposal One problem with your qualms about properties is that we are trying to map WebDAV data to object representation systems that do not have functional semantics, like XML. We should define an interface that doesn't rely on the distinction between functional interfaces and properties for maximum implementability on various servers. (This distinction is something may programmers have trouble with--does everyone always bother to create accessor methods for everything? ...) The benefit of using live properties as a representation is that object properties are more "portable" to the other types of systems that may want to access the same data, presumably through another means than the HTTP protocol (which isn't particularly efficient). (Which brings me to another unrelated issue--should there be a functional interface to WebDAV methods for programs living in the same server as the data repository, given the performance costs of HTTP within a single process--more on that later). Yes you need a set of clear rules for how live properties are used, and unless their use is rigorously controlled, you will have compatability problems of the type you cite, but this is a problem with any loosely written standard.I think of properties in the JavaBeans sense--in an OO language binding, they would actually be functional interfaces to set and retrieve them, but could be overridden to provide customized behaviour. Any JavaBeans user has no idea whether or not this piece of data is live or not, and this model works well. --Eric ----- Original Message ----- From: Yaron Goland <mailto:yarong@Exchange.Microsoft.com> To: 'Eric <mailto:esedlar@us.oracle.com> Sedlar' Sent: Monday, January 03, 2000 11:18 AM Subject: Your proposal Eric, I read your analysis of Geoff's proposal and was really impressed by your deep grasp of both HTTP and WebDAV. I have a series of issues with your counter-proposal but I'm going to hold off on commenting until we can build up more of a common base for conversation. Please see my post on the mailing list in regards to this. I did, however, want to point out a general design issue regarding your proposal that isn't directly related to locks. In your proposal you suggest using properties to provide various bits of protocol information, such as which names are currently locked. I would caution against using properties in this way, see http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0302.html <http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0302.html> for more details. For a history of how we ended up in this mess in the first place see http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0074.html <http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0074.html> and http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0303.html <http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0303.html> . BTW, all of these posts are collected in the WebDAV Book of Why available at http://lists.w3.org/Archives/Public/w3c-dist-auth/1999JanMar/0129.html <http://lists.w3.org/Archives/Public/w3c-dist-auth/1999JanMar/0129.html> . Thanks, Yaron ------_=_NextPart_001_01BF7E9E.C2891BE2 Content-Type: text/html <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii"> <META content="MSHTML 5.00.2920.0" name=GENERATOR></HEAD> <BODY bgColor=#ffffff> <DIV><FONT face=Arial size=2><SPAN class=495440606-05012000>(Note: I found this in my drafts directory, figured I would send it out)</SPAN></FONT></DIV> <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=495440606-05012000></SPAN></FONT> </DIV> <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=495440606-05012000>See below </SPAN></FONT></DIV> <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=495440606-05012000>[WARNING: O.k. I admit it, Eric's letter sent me down memory lane. So this e-mail is seriously long. However if you are interested in some of the history behind how XML ended up the way it is, how XML ended up in WebDAV and some of the work I and others at MS did to make WebDAV actually happen, read on!]</SPAN></FONT></DIV> <BLOCKQUOTE style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px"> <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma size=2>-----Original Message-----<BR><B>From:</B> Eric Sedlar [mailto:esedlar@us.oracle.com]<BR><B>Sent:</B> Mon, January 03, 2000 4:33 PM<BR><B>To:</B> Yaron Goland<BR><B>Cc:</B> w3c-dist-auth@w3.org<BR><B>Subject:</B> Re: Your proposal<BR><BR></DIV></FONT>Now we get into our areas of disagreement. <P>* I mentioned HTTP as having lousy performance WITHIN A SINGLE PROCESS.  I guarantee you that a function call is much cheaper than formatting the request into a stream, writing into a loopback socket, reading the result back, parsing it,  and then the reverse.  Another example is SQL access to properties of a resource.  If I want to query the resource data efficiently, I need to be able to treat properties of the resource as "virtual data", not make a series of function calls on each item in the query set.  If I want to write a servlet that takes an HTML form input and changes WebDAV properties, I definitely want a functional API (in Java).  Everyone knows that SMB sucks and is incredibly chatty.  As far as HTTP performance, it mostly depends on the amount of functionality you can pack into one request.  If I have to issue a GETLOCKED name request followed by a bunch of other requests to get all of the state of a particular resource, HTTP will suck. <FONT color=#0000ff face=Arial size=2><SPAN class=495440606-05012000> </SPAN></FONT> <P>My point was that the WebDAV model is actually bigger than HTTP--other data access systems (like SQL and XML technologies) should also be able to manipulate the data easily. <FONT color=#0000ff face=Arial size=2><SPAN class=495440606-05012000> </SPAN></FONT> <P><FONT color=#0000ff face=Arial size=2><SPAN class=495440606-05012000><Yaron></SPAN></FONT></P><FONT color=#0000ff><SPAN class=495440606-05012000> <P><FONT face=Arial size=2><SPAN class=495440606-05012000>I certainly wouldn't want someone accessing a DB on their local machine to have to run their requests through DAV. What a waste, a full trip through the protocol stack just for a local request? Of course they should be able to work through SQL and other mechanisms. In fact, in fulfilling my role as the lead author of the WebDAV specification and the chief WebDAV evangelist at Microsoft I was worked hand-in-hand with the ODBC/OLE DB/ADO teams at Microsoft to ensure that the model we were putting together would be easily accessible through their APIs. That is why, for example, OLD DB 2.5 has a native WebDAV provider. This is what was used to implement the WebDAV support in Web Folders. I also worked hand-in-hand with the SMB folks at Microsoft to make sure that the WebDAV model was such that we could run WebDAV directly over the file system and at the same time access it through the Win32 file APIs and SMB without any conflicts. That is why Win 2000 is able to ship a native WebDAV implementation that works directly off the file system allowing for simultaneous access by FTP/SMB/WebDAV/Win 32. At the same time I also coordinated with the Exchange group at Microsoft to ensure that the WebDAV model was consistent with POP/IMAP/MAPI. That is why Exchange 2000 (the upcoming release of Exchange) has a full WebDAV implementation that enables you to access your e-mail box simultaneously through POP/IMAP/MAPI/WebDAV. I also coordinated with our Active Directory team to ensure that the WebDAV model was consistent with LDAP/ADSI. I also coordinated with the SQL team to ensure that WebDAV could be easily layered on top of SQL so that one could do direct SQL queries as well as normal work. There are a number of other groups that I also coordinated with but unfortunately I can't release any data about that. But look forward to some interesting uses of WebDAV coming down the line. My favorite current example is pointing Office 2000 against Exchange 2000. Office sees Exchange as just another file store while Exchange sees Office as just another WebDAV client. The result is that you can save your files in your e-mail directories thus having your files automatically replicated and backed up for you. Very cool use of DAV. </SPAN></FONT> <P><FONT size=2><FONT face=Arial><SPAN class=495440606-05012000>I think we will see even cooler uses of DAV when DASL starts to get deployed. With DAV/DASL you can control/search your E-mail store, file store, directory or database with the same protocol using the same data model. I have been working for over 3 years to bring this vision to fruition. </SPAN>S<SPAN class=495440606-05012000>o obviously I am deeply interested in the issues of enabling access to stores that support WebDAV through many APIs and protocols.. </SPAN></FONT></FONT> <P><FONT color=#0000ff><SPAN class=495440606-05012000><FONT face=Arial size=2>That having been said I disagree with your statement that having to make multiple requests to describe a resource will destroy performance. A properly implemented HTTP server will support pipelining which, as repeated experiments have demonstrated, has equivalent performance to having one big message but with much cleaner protocol semantics. So long as the connection is kept open (default in HTTP/1.1) and the process is not spun down after each request there is no difference between processing one huge message and processing a string of messages that are pipelined in. In fact, in the WebDAV Book of Why I discuss in detail how depth came about and why we used depth instead of just pipelining. It is an interesting story, you will see that while performance was involved, it had nothing to do with the cost of parsing messages. You might want to read that section entitled "<"This is another fine protocol you've gotten me into!">" available in </FONT><A href="http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0303.html"><FONT face=Arial size=2>http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0303.html</FONT></A><FONT face=Arial size=2>. Keep in mind, btw, that the server does need to be a bit smart. For example, it should wait a little bit before processing a message in order to see if the next message can be bundled into a single API call to the underlying system. There are lots of tricks but these tricks are all well known. So it isn't a big deal.</FONT></SPAN></FONT></P> <P><FONT color=#0000ff face=Arial size=2><SPAN class=495440606-05012000></Yaron></SPAN></FONT></SPAN></FONT></P> <P>* Another reason for making all information about a resource available as properties is using XSL to format an HTML page giving access to all of this data.  There is a lot of support for not requiring a lot of programming (ala JSPs or ASPs) to format data within a page. <FONT color=#0000ff face=Arial size=2><SPAN class=495440606-05012000> </SPAN></FONT> <P><FONT color=#0000ff face=Arial size=2><SPAN class=495440606-05012000><Yaron></SPAN></FONT> <P><FONT color=#0000ff face=Arial size=2><SPAN class=495440606-05012000>No one I'm aware of is arguing against making the information available through XML. The argument is simply this: Do we get the information through a PROPFIND or do we get it through multiple requests, each of which are free to return XML. My response is that we must do the later because of the need to support content negotiation. In order to keep the WebDAV property model as simple as possible it does not support any form of content negotiation. This means that I can't say "I want the name property in French" or "I want the picture you have stored in this property returned as  JPEG." The only way to get this sort of negotiation is through individual method requests. If we only provide these properties through PROPFIND then we dumb DAV down to the level of a static database table and prevent people from developing more intelligent systems. The only real counter argument I see against using multiple methods is the possible performance ramifications but as I argued in the previous paragraph the introduction of pipelining into HTTP/1.1 makes this largely a non-issue.</SPAN></FONT> <P><FONT color=#0000ff face=Arial size=2><SPAN class=495440606-05012000></Yaron></SPAN></FONT> <P>* I don't understand why you think it will be easier to handle protocol extensions on the client side by using additional HTTP methods rather than resources.  XML applications are used to ignoring elements that they don't care about--extensibility is one of the key wins of XML vs. traditional OO languages.  It allows DOM objects to be passed around multiple areas of the system better.  For example, let's say that I have some client library which implements the client side of the HTTP protocol, and allows plugins to that client to access the XML DOM for each resource.  I can install a new client plugin to handle new properties that appear in that DOM, but I won't be able to extend the HTTP protocol.  HTTP protocol implementation is typically at a lower level of the client or server than properties. <FONT color=#0000ff face=Arial size=2><SPAN class=495440606-05012000> </SPAN></FONT> <P><FONT color=#0000ff face=Arial size=2><SPAN class=495440606-05012000><Yaron></SPAN></FONT> <P><FONT color=#0000ff face=Arial size=2><SPAN class=495440606-05012000>The main reason  that I believe that adding new methods is easy is that I have implemented a number of XML/DAV systems and it has repeatedly proven simpler to support new methods than new elements. This is mostly because the HTTP model is flat so that I can access things like the method name or a head directly where as with XML I have to navigate through a tree. This is the same logic that leads people to use attributes in XML, which as I argue in the WebDAV book of why is a really stupid thing to do. But I digress.</SPAN></FONT> <P><FONT color=#0000ff face=Arial size=2><SPAN class=495440606-05012000>As for ignoring elements, it is funny to hear someone say that XML is used to ignoring elements. I first became involved with XML before it was called XML. I had helped write a proposal called Web Collections that would later be put together with a bunch of other proposals in order to become what we now know as XML. In fact, my boss at the time was Thomas Reardon who was MS's representative to the W3C and the leading proponent both at MS and the W3C for XML. Now a days only the old timers remember the work he did in making XML real but in my estimation without him XML never would have taken off. As such I have been involved in helping with the XML design since day one. One of the problems we ran into with XML when it was first introduced was the question of handling unrecognized elements. At the time the SGML heads had total control over XML much to the anger and dismay of those of us born after the turn of the last century. At the time the SGML heads were arguing hard and fast against have a definition of well formidness. What they wanted to do was to require a DTD be available for all XML documents. These were the same geniuses who argued against the introduction of namespaces. In fact it was their sheer cussedness that prevented us from being able to just name an XML element as a URL. They refused to allow in the forward slash and other characters that would have been necessary to allow URLs in the name of elements. That is where the namespace hack came from. Anyway, I'm digressing. So the SGML heads were arguing that you always had to have a DTD so therefore, naturally, if you had an "unrecognized" element it was an error and you should fail the entire XML document! Those of us from the post-Diluvium age were aghast. Unfortunately Tim Berners-Lee (TBL) was convinced that we had to keep support of the SGML community. I remember getting lectured by Andrew Layman (who hated what the SGML guys were doing as well) about the "millions" of SGML documents out there and the need to work with them. Of course now nobody knows or cares about those ***BLEEP*** SGML documents, but a lot of the really awful crap you see in XML is the result of the deals that TBL made with the SGML guys to keep their support. TBL touches on this topic a little bit in his book. Anyway, the SGML guys were finally argued into accepting the idea of "well formidness" and thus we were freed of needing a DTD. However this left open the question of what to do when you hit an element you didn't recognize. Oh man were there flame fests on that topic. People in the protocol business tend to think of XML as just a tree so for us it is natural to just prune the XML tree at an unrecognized node. But the SGML guys don't see a tree when they see XML, they see a markup language. So, for example, imagine I have the following entry in my XML document "<p>He was a <bold>grand</bold> man!</p>. Now let us imagine that your XML parser supports the <p> tag but doesn't support <bold>. If you just pruned the tree you would end up with "<p>He was a man!</p>". That is clearly not what you want. The result was just a real mess. Some people demanded that you always prune. Some demanded that you only removed the tags but not the text. Some argued that you should have an attribute you would put on each element that would specify what you should do. There never was much of a resolution to the issue. Eventually I just got really pissed off and added what is now the first paragraph of section 14 of RFC 2518 to WebDAV declaring that we would prune any sub-tree whose root we didn't recognize. Man, did we ever catch hell for that! The XML guys told us that we wouldn't be compatible with their XML. That we were creating my own world that wouldn't work with the rest of the XML universe. Oh man, what a bloody mess. So to hear you say that the WebDAV ignore rule (as we called it) is a strength of XML is pretty damn ironic.</SPAN></FONT> <P><FONT color=#0000ff face=Arial size=2><SPAN class=495440606-05012000>As for HTTP generally appearing at a lower layer and not being available from the DOM, you may want to check out <A href="http://msdn.microsoft.com/xml/reference/scriptref/XMLHttpRequest_object.asp">http://msdn.microsoft.com/xml/reference/scriptref/XMLHttpRequest_object.asp</A> and <A href="http://msdn.microsoft.com/xml/reference/cvbref/IXMLHttpRequest_interface.asp">http://msdn.microsoft.com/xml/reference/cvbref/IXMLHttpRequest_interface.asp</A>. The links describe the XMLHTTP interface available through IE 5.0's DOM. The first link describes the interface for script programmers (JScript/ECMAScript, VBscript, Python, Perl, etc.) and the second for C/VB programmers. This interface allows you to send and receive generic HTTP messages directly through IE 5.0's DOM. What is really cool about it is that while it can handle arbitrary HTTP messages it is smart so that if you want to send or if you receive a message with an XML body it will automatically detect that and automatically parse out, lode up and pass back a DOM pointer to the contents. So actually HTTP access is as free and ready as XML access, at least in IE 5.0. BTW, massive credit goes to Alex Hopmann who nearly single handedly convinced the IE guys to ship this feature. Hats off to Alex!</SPAN></FONT> <P><FONT color=#0000ff face=Arial size=2><SPAN class=495440606-05012000></Yaron></SPAN></FONT> <P>HTTP request/response parsers are not generic technology like XML parsers are <FONT color=#0000ff face=Arial size=2><SPAN class=495440606-05012000> </SPAN></FONT> <P><FONT color=#0000ff face=Arial size=2><SPAN class=495440606-05012000><Yaron></SPAN></FONT> <P><FONT color=#0000ff face=Arial size=2><SPAN class=495440606-05012000>I'm not sure what leads you to this conclusion. For example, as the author of the HTTP over UDP spec I found that HTTP request/response parsers were incredibly generic. This is what made HTTP over UDP so compelling. We could take existing parsers, do a little tweaking and bam, it just worked. In fact I would argue that there is no better proof of the generic nature of HTTP parsers then the existence of WebDAV. We didn't have to do any major work to support WebDAV in our HTTP request/response parsers. HTTP already understood the concept of methods and headers so we were able to use the existing parsers to implement WebDAV. In fact the biggest problem we ran into is that some folks had implemented checks on what methods you could send as an error detection procedure! Sigh... In WinInet we had the problem that the devs, in order to optimize performance, had built a method mapping table that turned the method names into tokens and then moved the tokens around. Unfortunately the tokens were fixed, which meant that WinInet (our HTTP client stack) couldn't handle new methods. But the problem was easily fixed so modern versions of WinInet can handle arbitrary methods.</SPAN></FONT> <P><FONT color=#0000ff face=Arial size=2><SPAN class=495440606-05012000></Yaron></SPAN></FONT> <P>* It sounds like you are arguing against the general trend of making all of your data available via XML, which is counter to the general strategies most technology companies are following now, including Microsoft and Oracle.  With your proposal, you are going to render all of the burgeoning XML technology base useless, which is why the WebDAV people built around XML in the first place. <FONT color=#0000ff face=Arial size=2><SPAN class=495440606-05012000> </SPAN></FONT> <P><FONT color=#0000ff face=Arial size=2><SPAN class=495440606-05012000><Yaron></SPAN></FONT> <P><FONT color=#0000ff face=Arial size=2><SPAN class=495440606-05012000>I was the one who introduced XML into WebDAV.</SPAN></FONT><FONT color=#0000ff face=Arial size=2><SPAN class=495440606-05012000> Bonus points to anyone who remembers the original meeting when I proposed Web Collections (a precursor to XML) to WebDAV. This was the first time WebDAV was introduced to what would become XML. </SPAN></FONT> <P><FONT color=#0000ff face=Arial size=2><SPAN class=495440606-05012000>As for Microsoft's XML strategy, that is a whole other story. Because my boss, Thomas Reardon, lead the XML effort at MS for a long time I was actually part of creating our XML strategy. When Adam Bosworth took over XML I ended up having weekly meetings with him just so that we could synch up on Microsoft XML corporate strategy. I also worked with both Andrew Layman and Jean Paoli on XML issues. I still remember the tongue lashing I gave Andrew over fully qualified end tags.  It wasn't Andrew's fault, he hated it too, but he was the messenger and I was really angry. Basically the SGML heads forced XML to adopt fully qualified end tags. In the original proposal XML markup looked like <tag>stuff</>. But the SGML heads argued that this didn't make XML readable so we should make the already mind blowingly bloated XML format even more bloated by adding fully qualified end tags, i.e. <tag>stuff</tag>. Yet another fight that they won. </SPAN></FONT> <P><FONT color=#0000ff face=Arial size=2><SPAN class=495440606-05012000>As such I can safely assure you that I would not do anything to "render all of the burgeoning XML technology base useless". Having helped birth XML I would certainly be reticent about killing it. After all, infanticide is a messy business. I will admit, however and Jim Whitehead will back me up, that there were plenty of times when I would have have liked to have given XML a severe spanking followed by a good amount of time in the corner.</SPAN></FONT> <P><FONT color=#0000ff><FONT face=Arial size=2><SPAN class=495440606-05012000>I used to joke about the "XML Jedi Mind Trick." You just wave your hand in front of someone and say "You will use XML". Their eyes loose focus and they repeat in a monotone voice "I will use XML." This helped a lot in early WebDAV adoption. If I couldn't convince someone to adopt WebDAV because of its own merits I would just pull the XML Jedi Mind Trick and they would adopt it because it used XML. After all, if it uses XML it must be cool!</SPAN></FONT> </FONT><FONT face=Arial size=2><SPAN class=495440606-05012000><FONT color=#0000ff> There is apparently something indescribably sexy about angle brackets.</FONT> </SPAN></FONT> <P><FONT color=#0000ff face=Arial size=2><SPAN class=495440606-05012000></Yaron></SPAN></FONT> <P>Is anyone thinking about a thin-client WebDAV implementation (HTML only) running in a browser?  I should be able to do stuff like changing RSRs, manipulate directories, etc. with a web app. <FONT color=#0000ff face=Arial size=2><SPAN class=495440606-05012000> </SPAN></FONT> <P><FONT color=#0000ff face=Arial size=2><SPAN class=495440606-05012000><Yaron></SPAN></FONT> <P><FONT color=#0000ff face=Arial size=2><SPAN class=495440606-05012000>Thinking? We have already written it! Using XMLHTTP Exchange has written up an entire E-Mail client for Exchange 2000 that speaks WebDAV to their server. The whole thing is written 100% in nothing but script!!!! What is really amazing is that it uses DHTML so the UI looks almost 100% like Outlook, even down to the multiple Outlook views and the Outlook bar. It is seriously cool. I have also written, on my own, a generic WebDAV client library in JScript. Unfortunately I never finished it. Too many other things to do. </SPAN></FONT> <P><FONT color=#0000ff face=Arial size=2><SPAN class=495440606-05012000></Yaron></SPAN></FONT> <P>--Eric <FONT face=Arial size=2><SPAN class=495440606-05012000> </SPAN></FONT> <P><FONT face=Arial size=2><SPAN class=495440606-05012000>        Yaron</SPAN></FONT> <P><FONT face=Arial size=2><SPAN class=495440606-05012000> </SPAN></FONT> <P>Yaron Goland wrote: <BLOCKQUOTE TYPE="CITE"> <STYLE></STYLE> <SPAN class=352403723-03012000><FONT face=Arial><FONT color=#0000ff><FONT size=-1>I wouldn't accept a blanket statement that HTTP has lousy performance. I have seen it repeatedly beat the pants off all competing systems. </FONT></FONT></FONT></SPAN><SPAN class=352403723-03012000></SPAN><SPAN class=352403723-03012000><FONT face=Arial><FONT color=#0000ff><FONT size=-1>For example, we did a speed comparison of a super optimized SMB implementation and DAV in W2K. DAV won hands down. The reason is that SMB, like most protocols of its ilk, is unbelievably chatty. They are basically RPCs rather than protocols. DAV, on the other hand, is extremely optimized. So even though the SMB implementation could process some ridiculous number of messages per second DAV still had better performance because it sent a hell of a lot less messages.</FONT></FONT></FONT></SPAN><SPAN class=352403723-03012000></SPAN><SPAN class=352403723-03012000><FONT face=Arial><FONT color=#0000ff><FONT size=-1>As for the use of properties, I assert that there is no difference between executing a GETLOCKEDNAME method and getting the lockedname property in terms of how you write your back end. However, the first is a hell of a lot easier to deal with in terms of specifying and extending the protocol than the second. So the issue isn't one of back end implementation, it is one of front end convenience.</FONT></FONT></FONT></SPAN><SPAN class=352403723-03012000></SPAN><SPAN class=352403723-03012000><FONT face=Arial><FONT color=#0000ff><FONT size=-1>In other words, just say NO to live properties.</FONT></FONT></FONT></SPAN><SPAN class=352403723-03012000></SPAN><SPAN class=352403723-03012000><FONT face=Arial><FONT color=#0000ff><FONT size=-1>            Yaron</FONT></FONT></FONT></SPAN> <BLOCKQUOTE style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px"> <DIV class=OutlookMessageHeader dir=ltr><FONT face=Tahoma><FONT size=-1>-----Original Message-----</FONT></FONT> <BR><FONT face=Tahoma><FONT size=-1><B>From:</B> Eric Sedlar [<A href="mailto:esedlar@us.oracle.com">mailto:esedlar@us.oracle.com</A>]</FONT></FONT> <BR><FONT face=Tahoma><FONT size=-1><B>Sent:</B> Monday, January 03, 2000 1:09 PM</FONT></FONT> <BR><FONT face=Tahoma><FONT size=-1><B>To:</B> Yaron Goland</FONT></FONT> <BR><FONT face=Tahoma><FONT size=-1><B>Cc:</B> w3c-dist-auth@w3.org</FONT></FONT> <BR><FONT face=Tahoma><FONT size=-1><B>Subject:</B> Re: Your proposal</FONT></FONT> <BR> </DIV><FONT face=Arial><FONT size=-1>One problem with your qualms about properties is that we are trying to map WebDAV data to object representation systems that do not have functional semantics, like XML.  We should define an interface that doesn't rely on the distinction between functional interfaces and properties for maximum implementability on various servers.  (This distinction is something may programmers have trouble with--does everyone always bother to create accessor methods for everything?  ...)  The benefit of using live properties as a representation is that object properties are more "portable" to the other types of systems that may want to access the same data, presumably through another means than the HTTP protocol (which isn't particularly efficient).  (Which brings me to another unrelated issue--should there be a functional interface to WebDAV methods for programs living in the same server as the data repository, given the performance costs of HTTP within a single process--more on that later).</FONT></FONT> <FONT face=Arial><FONT size=-1>Yes you need a set of clear rules for how live properties are used, and unless their use is rigorously controlled, you will have compatability problems of the type you cite, but this is a problem with any loosely written standard.</FONT></FONT><FONT face=Arial><FONT size=-1>I think of properties in the JavaBeans sense--in an OO language binding, they would actually be functional interfaces to set and retrieve them, but could be overridden to provide customized behaviour.  Any JavaBeans user has no idea whether or not this piece of data is live or not, and this model works well.</FONT></FONT> <FONT face=Arial><FONT size=-1>--Eric</FONT></FONT> <BLOCKQUOTE style="BORDER-LEFT: #000000 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px; PADDING-RIGHT: 0px"> <DIV style="FONT: 10pt arial">----- Original Message -----</DIV> <DIV style="BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: black"><B>From:</B> <A href="mailto:yarong@Exchange.Microsoft.com" title=yarong@Exchange.Microsoft.com>Yaron Goland</A></DIV> <DIV style="FONT: 10pt arial"><B>To:</B> <A href="mailto:esedlar@us.oracle.com" title=esedlar@us.oracle.com>'Eric Sedlar'</A></DIV> <DIV style="FONT: 10pt arial"><B>Sent:</B> Monday, January 03, 2000 11:18 AM</DIV> <DIV style="FONT: 10pt arial"><B>Subject:</B> Your proposal</DIV> <FONT face=Arial><FONT size=-1>Eric, I read your analysis of Geoff's proposal and was really impressed by your deep grasp of both HTTP and WebDAV.</FONT></FONT> <P><FONT face=Arial><FONT size=-1>I have a series of issues with your counter-proposal but I'm going to hold off on commenting until we can build up more of a common base for conversation. Please see my post on the mailing list in regards to this.</FONT></FONT> <P><FONT face=Arial><FONT size=-1>I did, however, want to point out a general design issue regarding your proposal that isn't directly related to locks. In your proposal you suggest using properties to provide various bits of protocol information, such as which names are currently locked. I would caution against using properties in this way, see <A href="http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0302.html" target=_blank>http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0302.html</A> for more details. For a history of how we ended up in this mess in the first place see <A href="http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0074.html" target=_blank>http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0074.html</A> and <A href="http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0303.html" target=_blank>http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0303.html</A>. BTW, all of these posts are collected in the WebDAV Book of Why available at <A href="http://lists.w3.org/Archives/Public/w3c-dist-auth/1999JanMar/0129.html" target=_blank>http://lists.w3.org/Archives/Public/w3c-dist-auth/1999JanMar/0129.html</A>.</FONT></FONT> <P>                <FONT face=Arial><FONT size=-1>Thanks,</FONT></FONT> <BR>                                <FONT face=Arial><FONT size=-1>Yaron</FONT></FONT></P></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML> ------_=_NextPart_001_01BF7E9E.C2891BE2-- From w3c-dist-auth-request@w3.org Thu Feb 24 05:25:09 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25269 for <webdav-archive@odin.ietf.org>; Thu, 24 Feb 2000 05:25:09 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id FAA14324; Thu, 24 Feb 2000 05:14:06 -0500 (EST) Resent-Date: Thu, 24 Feb 2000 05:14:06 -0500 (EST) Resent-Message-Id: <200002241014.FAA14324@www19.w3.org> Message-ID: <38B5042D.24E4F232@marconicomms.com> Date: Thu, 24 Feb 2000 11:13:01 +0100 From: Edgar Schwarz <Edgar.Schwarz@marconicomms.com> Organization: Marconi Communications X-Mailer: Mozilla 4.05 [en] (X11; I; SunOS 5.6 sun4u) MIME-Version: 1.0 To: w3c-dist-auth@w3.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: An analysis of the proposal to place locks on URIs rather than re sources Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/4149 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit Yaron Goland wrote: Sorry, no time for a comment to Yaron's stuff at the moment :-) > > From: Geoffrey M. Clemm [mailto:geoffrey.clemm@rational.com] > > Sent: Thu, December 30, 1999 2:33 PM > > As an addendum to Yaron's response, I'll note that there is a proposal > > that WebDAV locking is better understood as locks on URL's rather than > > on resources. I'm not sure I understand. Does that mean that you can't lock a resource anymore with WebDAV ? I wouldn't like this idea. Or do you propose another mechanism for locking a resource ? Cheers, Edgar P.S. Sorry if this topic was already solved in the meantime but I didn't have time to follow the discussions for a while. -- Edgar.Schwarz@marconicomms.com, Marconi Communications, 07191/13-3382 Privat kann jeder soviel C programmieren oder Videos ansehen wie er mag. Albert Einstein: Mach es so einfach wie moeglich, aber nicht einfacher. From w3c-dist-auth-request@w3.org Thu Feb 24 13:41:26 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08328 for <webdav-archive@odin.ietf.org>; Thu, 24 Feb 2000 13:41:24 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA29287; Thu, 24 Feb 2000 13:36:55 -0500 (EST) Resent-Date: Thu, 24 Feb 2000 13:36:55 -0500 (EST) Resent-Message-Id: <200002241836.NAA29287@www19.w3.org> Message-ID: <8E3CFBC709A8D21191A400805F15E0DB0211F973@crte147.wc.eso.mc.xerox.com> From: "Slein, Judith A" <JSlein@crt.xerox.com> To: "'Roy T. Fielding'" <fielding@kiwi.ICS.UCI.EDU> Cc: w3c-dist-auth@w3.org Date: Thu, 24 Feb 2000 13:36:29 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Qualities of URLs and resources Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/4150 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Roy, In response to your comments about the nature of resources, we plan to remove from the binding spec all language that suggests that resources are storage entities. We think that otherwise, the spec is consistent with the view that a resource is a mapping function. We will change the definition of binding to state explicitly that it is not a resource, but is rather part of the state of a collection resource. Although I think this conflicts with your position, it at least makes our position clearer. Will these changes allay your concerns, or do we need to do further work? --Judy From w3c-dist-auth-request@w3.org Thu Feb 24 14:49:06 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09246 for <webdav-archive@odin.ietf.org>; Thu, 24 Feb 2000 14:48:51 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA01369; Thu, 24 Feb 2000 14:43:25 -0500 (EST) Resent-Date: Thu, 24 Feb 2000 14:43:25 -0500 (EST) Resent-Message-Id: <200002241943.OAA01369@www19.w3.org> Message-ID: <01a701bf7eff$2c5dfaa0$9a114498@us.oracle.com> From: "Eric Sedlar" <esedlar@us.oracle.com> To: "Yaron Goland" <yarong@Exchange.Microsoft.com> Cc: <w3c-dist-auth@w3.org>, <yaron@goland.org> References: <7DE119D3D0E15543874F7561EECBDBED02619DFA@BEG.platinum.corp.microsoft.com> Date: Thu, 24 Feb 2000 11:41:40 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01A4_01BF7EBC.1DD67A90" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Subject: Re: Your proposal Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/4151 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_01A4_01BF7EBC.1DD67A90 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Yaron-- Thanks for time you put into writing this response--I'm more familiar = (due to reasons of political correctness) with the browser other than = IE, so it's good to hear about all of this technology in IE and other = Microsoft products. I've found that the XML Jedi mind trick works pretty well, second only = to the Java mind trick--"You will write all applications in Java", to = which the reply is "Yes, we must use cutting edge Web technologies like = Java". However, your mileage may vary in Redmond ;-) My response to all of this is <monotone>"Yes, I will use new HTTP = methods"</monotone>. --Eric ----- Original Message -----=20 From: Yaron Goland=20 To: 'Eric Sedlar'=20 Cc: w3c-dist-auth@w3.org ; 'yaron@goland.org'=20 Sent: Thursday, February 24, 2000 12:13 AM Subject: RE: Your proposal (Note: I found this in my drafts directory, figured I would send it = out) =20 See below=20 [WARNING: O.k. I admit it, Eric's letter sent me down memory lane. So = this e-mail is seriously long. However if you are interested in some of = the history behind how XML ended up the way it is, how XML ended up in = WebDAV and some of the work I and others at MS did to make WebDAV = actually happen, read on!] -----Original Message----- From: Eric Sedlar [mailto:esedlar@us.oracle.com] Sent: Mon, January 03, 2000 4:33 PM To: Yaron Goland Cc: w3c-dist-auth@w3.org Subject: Re: Your proposal Now we get into our areas of disagreement.=20 * I mentioned HTTP as having lousy performance WITHIN A SINGLE = PROCESS. I guarantee you that a function call is much cheaper than = formatting the request into a stream, writing into a loopback socket, = reading the result back, parsing it, and then the reverse. Another = example is SQL access to properties of a resource. If I want to query = the resource data efficiently, I need to be able to treat properties of = the resource as "virtual data", not make a series of function calls on = each item in the query set. If I want to write a servlet that takes an = HTML form input and changes WebDAV properties, I definitely want a = functional API (in Java). Everyone knows that SMB sucks and is = incredibly chatty. As far as HTTP performance, it mostly depends on the = amount of functionality you can pack into one request. If I have to = issue a GETLOCKED name request followed by a bunch of other requests to = get all of the state of a particular resource, HTTP will suck. =20 My point was that the WebDAV model is actually bigger than = HTTP--other data access systems (like SQL and XML technologies) should = also be able to manipulate the data easily. =20 <Yaron> I certainly wouldn't want someone accessing a DB on their local = machine to have to run their requests through DAV. What a waste, a full = trip through the protocol stack just for a local request? Of course they = should be able to work through SQL and other mechanisms. In fact, in = fulfilling my role as the lead author of the WebDAV specification and = the chief WebDAV evangelist at Microsoft I was worked hand-in-hand with = the ODBC/OLE DB/ADO teams at Microsoft to ensure that the model we were = putting together would be easily accessible through their APIs. That is = why, for example, OLD DB 2.5 has a native WebDAV provider. This is what = was used to implement the WebDAV support in Web Folders. I also worked = hand-in-hand with the SMB folks at Microsoft to make sure that the = WebDAV model was such that we could run WebDAV directly over the file = system and at the same time access it through the Win32 file APIs and = SMB without any conflicts. That is why Win 2000 is able to ship a native = WebDAV implementation that works directly off the file system allowing = for simultaneous access by FTP/SMB/WebDAV/Win 32. At the same time I = also coordinated with the Exchange group at Microsoft to ensure that the = WebDAV model was consistent with POP/IMAP/MAPI. That is why Exchange = 2000 (the upcoming release of Exchange) has a full WebDAV implementation = that enables you to access your e-mail box simultaneously through = POP/IMAP/MAPI/WebDAV. I also coordinated with our Active Directory team = to ensure that the WebDAV model was consistent with LDAP/ADSI. I also = coordinated with the SQL team to ensure that WebDAV could be easily = layered on top of SQL so that one could do direct SQL queries as well as = normal work. There are a number of other groups that I also coordinated = with but unfortunately I can't release any data about that. But look = forward to some interesting uses of WebDAV coming down the line. My = favorite current example is pointing Office 2000 against Exchange 2000. = Office sees Exchange as just another file store while Exchange sees = Office as just another WebDAV client. The result is that you can save = your files in your e-mail directories thus having your files = automatically replicated and backed up for you. Very cool use of DAV.=20 I think we will see even cooler uses of DAV when DASL starts to get = deployed. With DAV/DASL you can control/search your E-mail store, file = store, directory or database with the same protocol using the same data = model. I have been working for over 3 years to bring this vision to = fruition. So obviously I am deeply interested in the issues of enabling = access to stores that support WebDAV through many APIs and protocols.. =20 That having been said I disagree with your statement that having to = make multiple requests to describe a resource will destroy performance. = A properly implemented HTTP server will support pipelining which, as = repeated experiments have demonstrated, has equivalent performance to = having one big message but with much cleaner protocol semantics. So long = as the connection is kept open (default in HTTP/1.1) and the process is = not spun down after each request there is no difference between = processing one huge message and processing a string of messages that are = pipelined in. In fact, in the WebDAV Book of Why I discuss in detail how = depth came about and why we used depth instead of just pipelining. It is = an interesting story, you will see that while performance was involved, = it had nothing to do with the cost of parsing messages. You might want = to read that section entitled "<"This is another fine protocol you've = gotten me into!">" available in = http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0303.html. = Keep in mind, btw, that the server does need to be a bit smart. For = example, it should wait a little bit before processing a message in = order to see if the next message can be bundled into a single API call = to the underlying system. There are lots of tricks but these tricks are = all well known. So it isn't a big deal. </Yaron> * Another reason for making all information about a resource = available as properties is using XSL to format an HTML page giving = access to all of this data. There is a lot of support for not requiring = a lot of programming (ala JSPs or ASPs) to format data within a page. =20 <Yaron>=20 No one I'm aware of is arguing against making the information = available through XML. The argument is simply this: Do we get the = information through a PROPFIND or do we get it through multiple = requests, each of which are free to return XML. My response is that we = must do the later because of the need to support content negotiation. In = order to keep the WebDAV property model as simple as possible it does = not support any form of content negotiation. This means that I can't say = "I want the name property in French" or "I want the picture you have = stored in this property returned as JPEG." The only way to get this = sort of negotiation is through individual method requests. If we only = provide these properties through PROPFIND then we dumb DAV down to the = level of a static database table and prevent people from developing more = intelligent systems. The only real counter argument I see against using = multiple methods is the possible performance ramifications but as I = argued in the previous paragraph the introduction of pipelining into = HTTP/1.1 makes this largely a non-issue.=20 </Yaron>=20 * I don't understand why you think it will be easier to handle = protocol extensions on the client side by using additional HTTP methods = rather than resources. XML applications are used to ignoring elements = that they don't care about--extensibility is one of the key wins of XML = vs. traditional OO languages. It allows DOM objects to be passed around = multiple areas of the system better. For example, let's say that I have = some client library which implements the client side of the HTTP = protocol, and allows plugins to that client to access the XML DOM for = each resource. I can install a new client plugin to handle new = properties that appear in that DOM, but I won't be able to extend the = HTTP protocol. HTTP protocol implementation is typically at a lower = level of the client or server than properties. =20 <Yaron>=20 The main reason that I believe that adding new methods is easy is = that I have implemented a number of XML/DAV systems and it has = repeatedly proven simpler to support new methods than new elements. This = is mostly because the HTTP model is flat so that I can access things = like the method name or a head directly where as with XML I have to = navigate through a tree. This is the same logic that leads people to use = attributes in XML, which as I argue in the WebDAV book of why is a = really stupid thing to do. But I digress.=20 As for ignoring elements, it is funny to hear someone say that XML = is used to ignoring elements. I first became involved with XML before it = was called XML. I had helped write a proposal called Web Collections = that would later be put together with a bunch of other proposals in = order to become what we now know as XML. In fact, my boss at the time = was Thomas Reardon who was MS's representative to the W3C and the = leading proponent both at MS and the W3C for XML. Now a days only the = old timers remember the work he did in making XML real but in my = estimation without him XML never would have taken off. As such I have = been involved in helping with the XML design since day one. One of the = problems we ran into with XML when it was first introduced was the = question of handling unrecognized elements. At the time the SGML heads = had total control over XML much to the anger and dismay of those of us = born after the turn of the last century. At the time the SGML heads were = arguing hard and fast against have a definition of well formidness. What = they wanted to do was to require a DTD be available for all XML = documents. These were the same geniuses who argued against the = introduction of namespaces. In fact it was their sheer cussedness that = prevented us from being able to just name an XML element as a URL. They = refused to allow in the forward slash and other characters that would = have been necessary to allow URLs in the name of elements. That is where = the namespace hack came from. Anyway, I'm digressing. So the SGML heads = were arguing that you always had to have a DTD so therefore, naturally, = if you had an "unrecognized" element it was an error and you should fail = the entire XML document! Those of us from the post-Diluvium age were = aghast. Unfortunately Tim Berners-Lee (TBL) was convinced that we had to = keep support of the SGML community. I remember getting lectured by = Andrew Layman (who hated what the SGML guys were doing as well) about = the "millions" of SGML documents out there and the need to work with = them. Of course now nobody knows or cares about those ***BLEEP*** SGML = documents, but a lot of the really awful crap you see in XML is the = result of the deals that TBL made with the SGML guys to keep their = support. TBL touches on this topic a little bit in his book. Anyway, the = SGML guys were finally argued into accepting the idea of "well = formidness" and thus we were freed of needing a DTD. However this left = open the question of what to do when you hit an element you didn't = recognize. Oh man were there flame fests on that topic. People in the = protocol business tend to think of XML as just a tree so for us it is = natural to just prune the XML tree at an unrecognized node. But the SGML = guys don't see a tree when they see XML, they see a markup language. So, = for example, imagine I have the following entry in my XML document = "<p>He was a <bold>grand</bold> man!</p>. Now let us imagine that your = XML parser supports the <p> tag but doesn't support <bold>. If you just = pruned the tree you would end up with "<p>He was a man!</p>". That is = clearly not what you want. The result was just a real mess. Some people = demanded that you always prune. Some demanded that you only removed the = tags but not the text. Some argued that you should have an attribute you = would put on each element that would specify what you should do. There = never was much of a resolution to the issue. Eventually I just got = really pissed off and added what is now the first paragraph of section = 14 of RFC 2518 to WebDAV declaring that we would prune any sub-tree = whose root we didn't recognize. Man, did we ever catch hell for that! = The XML guys told us that we wouldn't be compatible with their XML. That = we were creating my own world that wouldn't work with the rest of the = XML universe. Oh man, what a bloody mess. So to hear you say that the = WebDAV ignore rule (as we called it) is a strength of XML is pretty damn = ironic.=20 As for HTTP generally appearing at a lower layer and not being = available from the DOM, you may want to check out = http://msdn.microsoft.com/xml/reference/scriptref/XMLHttpRequest_object.a= sp and = http://msdn.microsoft.com/xml/reference/cvbref/IXMLHttpRequest_interface.= asp. The links describe the XMLHTTP interface available through IE 5.0's = DOM. The first link describes the interface for script programmers = (JScript/ECMAScript, VBscript, Python, Perl, etc.) and the second for = C/VB programmers. This interface allows you to send and receive generic = HTTP messages directly through IE 5.0's DOM. What is really cool about = it is that while it can handle arbitrary HTTP messages it is smart so = that if you want to send or if you receive a message with an XML body it = will automatically detect that and automatically parse out, lode up and = pass back a DOM pointer to the contents. So actually HTTP access is as = free and ready as XML access, at least in IE 5.0. BTW, massive credit = goes to Alex Hopmann who nearly single handedly convinced the IE guys to = ship this feature. Hats off to Alex!=20 </Yaron>=20 HTTP request/response parsers are not generic technology like XML = parsers are =20 <Yaron>=20 I'm not sure what leads you to this conclusion. For example, as the = author of the HTTP over UDP spec I found that HTTP request/response = parsers were incredibly generic. This is what made HTTP over UDP so = compelling. We could take existing parsers, do a little tweaking and = bam, it just worked. In fact I would argue that there is no better proof = of the generic nature of HTTP parsers then the existence of WebDAV. We = didn't have to do any major work to support WebDAV in our HTTP = request/response parsers. HTTP already understood the concept of methods = and headers so we were able to use the existing parsers to implement = WebDAV. In fact the biggest problem we ran into is that some folks had = implemented checks on what methods you could send as an error detection = procedure! Sigh... In WinInet we had the problem that the devs, in order = to optimize performance, had built a method mapping table that turned = the method names into tokens and then moved the tokens around. = Unfortunately the tokens were fixed, which meant that WinInet (our HTTP = client stack) couldn't handle new methods. But the problem was easily = fixed so modern versions of WinInet can handle arbitrary methods.=20 </Yaron>=20 * It sounds like you are arguing against the general trend of making = all of your data available via XML, which is counter to the general = strategies most technology companies are following now, including = Microsoft and Oracle. With your proposal, you are going to render all = of the burgeoning XML technology base useless, which is why the WebDAV = people built around XML in the first place. =20 <Yaron>=20 I was the one who introduced XML into WebDAV. Bonus points to anyone = who remembers the original meeting when I proposed Web Collections (a = precursor to XML) to WebDAV. This was the first time WebDAV was = introduced to what would become XML. =20 As for Microsoft's XML strategy, that is a whole other story. = Because my boss, Thomas Reardon, lead the XML effort at MS for a long = time I was actually part of creating our XML strategy. When Adam = Bosworth took over XML I ended up having weekly meetings with him just = so that we could synch up on Microsoft XML corporate strategy. I also = worked with both Andrew Layman and Jean Paoli on XML issues. I still = remember the tongue lashing I gave Andrew over fully qualified end tags. = It wasn't Andrew's fault, he hated it too, but he was the messenger and = I was really angry. Basically the SGML heads forced XML to adopt fully = qualified end tags. In the original proposal XML markup looked like = <tag>stuff</>. But the SGML heads argued that this didn't make XML = readable so we should make the already mind blowingly bloated XML format = even more bloated by adding fully qualified end tags, i.e. = <tag>stuff</tag>. Yet another fight that they won.=20 As such I can safely assure you that I would not do anything to = "render all of the burgeoning XML technology base useless". Having = helped birth XML I would certainly be reticent about killing it. After = all, infanticide is a messy business. I will admit, however and Jim = Whitehead will back me up, that there were plenty of times when I would = have have liked to have given XML a severe spanking followed by a good = amount of time in the corner.=20 I used to joke about the "XML Jedi Mind Trick." You just wave your = hand in front of someone and say "You will use XML". Their eyes loose = focus and they repeat in a monotone voice "I will use XML." This helped = a lot in early WebDAV adoption. If I couldn't convince someone to adopt = WebDAV because of its own merits I would just pull the XML Jedi Mind = Trick and they would adopt it because it used XML. After all, if it uses = XML it must be cool! There is apparently something indescribably sexy = about angle brackets. =20 </Yaron>=20 Is anyone thinking about a thin-client WebDAV implementation (HTML = only) running in a browser? I should be able to do stuff like changing = RSRs, manipulate directories, etc. with a web app. =20 <Yaron>=20 Thinking? We have already written it! Using XMLHTTP Exchange has = written up an entire E-Mail client for Exchange 2000 that speaks WebDAV = to their server. The whole thing is written 100% in nothing but = script!!!! What is really amazing is that it uses DHTML so the UI looks = almost 100% like Outlook, even down to the multiple Outlook views and = the Outlook bar. It is seriously cool. I have also written, on my own, a = generic WebDAV client library in JScript. Unfortunately I never finished = it. Too many other things to do. =20 </Yaron>=20 --Eric =20 Yaron=20 =20 Yaron Goland wrote:=20 I wouldn't accept a blanket statement that HTTP has lousy = performance. I have seen it repeatedly beat the pants off all competing = systems. For example, we did a speed comparison of a super optimized SMB = implementation and DAV in W2K. DAV won hands down. The reason is that = SMB, like most protocols of its ilk, is unbelievably chatty. They are = basically RPCs rather than protocols. DAV, on the other hand, is = extremely optimized. So even though the SMB implementation could process = some ridiculous number of messages per second DAV still had better = performance because it sent a hell of a lot less messages.As for the use = of properties, I assert that there is no difference between executing a = GETLOCKEDNAME method and getting the lockedname property in terms of how = you write your back end. However, the first is a hell of a lot easier to = deal with in terms of specifying and extending the protocol than the = second. So the issue isn't one of back end implementation, it is one of = front end convenience.In other words, just say NO to live properties. = Yaron=20 -----Original Message-----=20 From: Eric Sedlar [mailto:esedlar@us.oracle.com]=20 Sent: Monday, January 03, 2000 1:09 PM=20 To: Yaron Goland=20 Cc: w3c-dist-auth@w3.org=20 Subject: Re: Your proposal=20 =20 One problem with your qualms about properties is that we are = trying to map WebDAV data to object representation systems that do not = have functional semantics, like XML. We should define an interface that = doesn't rely on the distinction between functional interfaces and = properties for maximum implementability on various servers. (This = distinction is something may programmers have trouble with--does = everyone always bother to create accessor methods for everything? ...) = The benefit of using live properties as a representation is that object = properties are more "portable" to the other types of systems that may = want to access the same data, presumably through another means than the = HTTP protocol (which isn't particularly efficient). (Which brings me to = another unrelated issue--should there be a functional interface to = WebDAV methods for programs living in the same server as the data = repository, given the performance costs of HTTP within a single = process--more on that later). Yes you need a set of clear rules for how = live properties are used, and unless their use is rigorously controlled, = you will have compatability problems of the type you cite, but this is a = problem with any loosely written standard.I think of properties in the = JavaBeans sense--in an OO language binding, they would actually be = functional interfaces to set and retrieve them, but could be overridden = to provide customized behaviour. Any JavaBeans user has no idea whether = or not this piece of data is live or not, and this model works well. = --Eric=20 ----- Original Message ----- From: Yaron Goland To: 'Eric Sedlar' Sent: Monday, January 03, 2000 11:18 AM Subject: Your proposal Eric, I read your analysis of Geoff's proposal and was really = impressed by your deep grasp of both HTTP and WebDAV.=20 I have a series of issues with your counter-proposal but I'm = going to hold off on commenting until we can build up more of a common = base for conversation. Please see my post on the mailing list in regards = to this.=20 I did, however, want to point out a general design issue = regarding your proposal that isn't directly related to locks. In your = proposal you suggest using properties to provide various bits of = protocol information, such as which names are currently locked. I would = caution against using properties in this way, see = http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0302.html = for more details. For a history of how we ended up in this mess in the = first place see = http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0074.html = and = http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0303.html. = BTW, all of these posts are collected in the WebDAV Book of Why = available at = http://lists.w3.org/Archives/Public/w3c-dist-auth/1999JanMar/0129.html.=20 Thanks,=20 Yaron ------=_NextPart_000_01A4_01BF7EBC.1DD67A90 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META content=3D"text/html; charset=3Diso-8859-1" = http-equiv=3DContent-Type> <META content=3D"MSHTML 5.00.2919.6307" name=3DGENERATOR></HEAD> <BODY bgColor=3D#ffffff> <DIV><FONT face=3DArial size=3D2>Yaron--</FONT></DIV> <DIV> </DIV> <DIV><FONT face=3DArial size=3D2>  Thanks for time you put into = writing this=20 response--I'm more familiar (due to reasons of political correctness) = with the=20 browser other than IE, so it's good to hear about all of this technology = in IE=20 and other Microsoft products.</FONT></DIV> <DIV> </DIV> <DIV><FONT face=3DArial size=3D2>  I've found that the XML Jedi = mind trick=20 works pretty well, second only to the Java mind trick--"You will write = all=20 applications in Java", to which the reply is "Yes, we must use cutting = edge Web=20 technologies like Java".  However, your mileage may vary in Redmond = ;-)</FONT></DIV> <DIV> </DIV> <DIV><FONT face=3DArial size=3D2>  My response to all of this = is=20 <monotone>"Yes, I will use new HTTP=20 methods"</monotone>.</FONT></DIV> <DIV> </DIV> <DIV><FONT face=3DArial size=3D2>--Eric</FONT></DIV> <DIV> </DIV> <DIV>----- Original Message ----- </DIV> <BLOCKQUOTE=20 style=3D"BORDER-LEFT: #000000 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: = 0px; PADDING-LEFT: 5px; PADDING-RIGHT: 0px"> <DIV=20 style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: = black"><B>From:</B>=20 <A href=3D"mailto:yarong@Exchange.Microsoft.com"=20 title=3Dyarong@Exchange.Microsoft.com>Yaron Goland</A> </DIV> <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A=20 href=3D"mailto:esedlar@us.oracle.com" = title=3Desedlar@us.oracle.com>'Eric=20 Sedlar'</A> </DIV> <DIV style=3D"FONT: 10pt arial"><B>Cc:</B> <A = href=3D"mailto:w3c-dist-auth@w3.org"=20 title=3Dw3c-dist-auth@w3.org>w3c-dist-auth@w3.org</A> ; <A=20 href=3D"mailto:'yaron@goland.org'" = title=3Dyaron@goland.org>'yaron@goland.org'</A>=20 </DIV> <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Thursday, February 24, = 2000 12:13=20 AM</DIV> <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> RE: Your = proposal</DIV> <DIV><BR></DIV> <DIV><FONT face=3DArial size=3D2><SPAN = class=3D495440606-05012000>(Note: I found=20 this in my drafts directory, figured I would send it = out)</SPAN></FONT></DIV> <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20 class=3D495440606-05012000></SPAN></FONT> </DIV> <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN = class=3D495440606-05012000>See=20 below </SPAN></FONT></DIV> <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20 class=3D495440606-05012000>[WARNING: O.k. I admit it, Eric's letter = sent me down=20 memory lane. So this e-mail is seriously long. However if you are = interested=20 in some of the history behind how XML ended up the way it is, how XML = ended up=20 in WebDAV and some of the work I and others at MS did to make WebDAV = actually=20 happen, read on!]</SPAN></FONT></DIV> <BLOCKQUOTE=20 style=3D"BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; = MARGIN-RIGHT: 0px; PADDING-LEFT: 5px"> <DIV align=3Dleft class=3DOutlookMessageHeader dir=3Dltr><FONT = face=3DTahoma=20 size=3D2>-----Original Message-----<BR><B>From:</B> Eric Sedlar [<A=20 = href=3D"mailto:esedlar@us.oracle.com">mailto:esedlar@us.oracle.com</A>]<B= R><B>Sent:</B>=20 Mon, January 03, 2000 4:33 PM<BR><B>To:</B> Yaron = Goland<BR><B>Cc:</B>=20 w3c-dist-auth@w3.org<BR><B>Subject:</B> Re: Your=20 proposal<BR><BR></DIV></FONT>Now we get into our areas of = disagreement.=20 <P>* I mentioned HTTP as having lousy performance=20 WITHIN A SINGLE PROCESS.  I guarantee you = that a=20 function call is much cheaper than formatting the request into a = stream,=20 writing into a loopback socket, reading the result back, parsing = it, =20 and then the reverse.  Another example is SQL access to = properties=20 of a resource.  If I want to query the resource data = efficiently,=20 I need to be able to treat properties of the resource as = "virtual=20 data", not make a series of function calls on each item in the query = set.  If I want to write a servlet that takes an = HTML form=20 input and changes WebDAV properties, I definitely want a = functional API=20 (in Java).  Everyone knows that SMB sucks and is = incredibly=20 chatty.  As far as HTTP performance, it mostly depends on = the=20 amount of functionality you can pack into one request.  If = I have=20 to issue a GETLOCKED name request followed by a bunch of other = requests=20 to get all of the state of a particular resource, HTTP will=20 suck. <FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20 class=3D495440606-05012000> </SPAN></FONT>=20 <P>My point was that the WebDAV model is actually bigger than=20 HTTP--other data access systems (like SQL and XML technologies) = should also=20 be able to manipulate the data easily. <FONT color=3D#0000ff = face=3DArial=20 size=3D2><SPAN class=3D495440606-05012000> </SPAN></FONT>=20 <P><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20 class=3D495440606-05012000><Yaron></SPAN></FONT></P><FONT=20 color=3D#0000ff><SPAN class=3D495440606-05012000> <P><FONT face=3DArial size=3D2><SPAN class=3D495440606-05012000>I = certainly=20 wouldn't want someone accessing a DB on their local machine to have = to run=20 their requests through DAV. What a waste, a full trip through the = protocol=20 stack just for a local request? Of course they should be able to = work=20 through SQL and other mechanisms. In fact, in fulfilling my role as = the lead=20 author of the WebDAV specification and the chief WebDAV evangelist = at=20 Microsoft I was worked hand-in-hand with the ODBC/OLE DB/ADO teams = at=20 Microsoft to ensure that the model we were putting together would be = easily=20 accessible through their APIs. That is why, for example, OLD DB 2.5 = has a=20 native WebDAV provider. This is what was used to implement the = WebDAV=20 support in Web Folders. I also worked hand-in-hand with the SMB = folks at=20 Microsoft to make sure that the WebDAV model was such that we could = run=20 WebDAV directly over the file system and at the same time access it = through=20 the Win32 file APIs and SMB without any conflicts. That is why Win = 2000 is=20 able to ship a native WebDAV implementation that works directly off = the file=20 system allowing for simultaneous access by FTP/SMB/WebDAV/Win 32. At = the=20 same time I also coordinated with the Exchange group at Microsoft to = ensure=20 that the WebDAV model was consistent with POP/IMAP/MAPI. That is why = Exchange 2000 (the upcoming release of Exchange) has a full = WebDAV=20 implementation that enables you to access your e-mail box = simultaneously=20 through POP/IMAP/MAPI/WebDAV. I also coordinated with our Active = Directory=20 team to ensure that the WebDAV model was consistent with LDAP/ADSI. = I also=20 coordinated with the SQL team to ensure that WebDAV could be easily = layered=20 on top of SQL so that one could do direct SQL queries as well as = normal=20 work. There are a number of other groups that I also coordinated = with but=20 unfortunately I can't release any data about that. But look forward = to some=20 interesting uses of WebDAV coming down the line. My favorite current = example=20 is pointing Office 2000 against Exchange 2000. Office sees Exchange = as just=20 another file store while Exchange sees Office as just another WebDAV = client.=20 The result is that you can save your files in your e-mail = directories thus=20 having your files automatically replicated and backed up for you. = Very cool=20 use of DAV. </SPAN></FONT> <P><FONT size=3D2><FONT face=3DArial><SPAN = class=3D495440606-05012000>I think we=20 will see even cooler uses of DAV when DASL starts to get deployed. = With=20 DAV/DASL you can control/search your E-mail store, file store, = directory or=20 database with the same protocol using the same data model. I have = been=20 working for over 3 years to bring this vision to fruition. = </SPAN>S<SPAN=20 class=3D495440606-05012000>o obviously I am deeply interested in the = issues of=20 enabling access to stores that support WebDAV through many APIs and=20 protocols.. </SPAN></FONT></FONT>=20 <P><FONT color=3D#0000ff><SPAN class=3D495440606-05012000><FONT = face=3DArial=20 size=3D2>That having been said I disagree with your statement that = having to=20 make multiple requests to describe a resource will destroy = performance. A=20 properly implemented HTTP server will support pipelining which, as = repeated=20 experiments have demonstrated, has equivalent performance to having = one big=20 message but with much cleaner protocol semantics. So long as the = connection=20 is kept open (default in HTTP/1.1) and the process is not spun down = after=20 each request there is no difference between processing one huge = message and=20 processing a string of messages that are pipelined in. In fact, in = the=20 WebDAV Book of Why I discuss in detail how depth came about and why = we used=20 depth instead of just pipelining. It is an interesting story, you = will see=20 that while performance was involved, it had nothing to do with the = cost of=20 parsing messages. You might want to read that section entitled = "<"This is=20 another fine protocol you've gotten me into!">" available in = </FONT><A=20 = href=3D"http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0303= .html"><FONT=20 face=3DArial=20 = size=3D2>http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/030= 3.html</FONT></A><FONT=20 face=3DArial size=3D2>. Keep in mind, btw, that the server does = need to be=20 a bit smart. For example, it should wait a little bit before = processing=20 a message in order to see if the next message can be bundled into a = single=20 API call to the underlying system. There are lots of tricks but = these tricks=20 are all well known. So it isn't a big deal.</FONT></SPAN></FONT></P> <P><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20 = class=3D495440606-05012000></Yaron></SPAN></FONT></SPAN></FONT></P>= <P>* Another reason for making all information about a resource = available as properties is using XSL to format an = HTML page giving=20 access to all of this data.  There is a lot of support for not=20 requiring a lot of programming (ala JSPs or ASPs) to format = data within=20 a page. <FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20 class=3D495440606-05012000> </SPAN></FONT>=20 <P><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20 class=3D495440606-05012000><Yaron></SPAN></FONT>=20 <P><FONT color=3D#0000ff face=3DArial size=3D2><SPAN = class=3D495440606-05012000>No=20 one I'm aware of is arguing against making the information = available=20 through XML. The argument is simply this: Do we get the = information=20 through a PROPFIND or do we get it through multiple requests, each = of which=20 are free to return XML. My response is that we must do the = later=20 because of the need to support content negotiation. In = order to=20 keep the WebDAV property model as simple as possible it does not = support any=20 form of content negotiation. This means that I can't say "I want the = name=20 property in French" or "I want the picture you have stored in this = property=20 returned as  JPEG." The only way to get this sort of = negotiation is=20 through individual method requests. If we only provide = these=20 properties through PROPFIND then we dumb DAV down to the level of a = static=20 database table and prevent people from developing more intelligent = systems.=20 The only real counter argument I see against using multiple methods = is the=20 possible performance ramifications but as I argued in the previous = paragraph=20 the introduction of pipelining into HTTP/1.1 makes this largely a=20 non-issue.</SPAN></FONT>=20 <P><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20 class=3D495440606-05012000></Yaron></SPAN></FONT>=20 <P>* I don't understand why you think it will be easier to = handle=20 protocol extensions on the client side by using additional = HTTP methods=20 rather than resources.  XML applications are used to = ignoring=20 elements that they don't care about--extensibility is one of the key = wins of=20 XML vs. traditional OO languages.  It allows = DOM objects=20 to be passed around multiple areas of the system better.  For = example,=20 let's say that I have some client library which implements the = client=20 side of the HTTP protocol, and allows plugins to that client to = access=20 the XML DOM for each resource.  I can install a = new=20 client plugin to handle new properties that appear in that DOM, but=20 I won't be able to extend the HTTP protocol.  HTTP = protocol=20 implementation is typically at a lower level of the client or server = than=20 properties. <FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20 class=3D495440606-05012000> </SPAN></FONT>=20 <P><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20 class=3D495440606-05012000><Yaron></SPAN></FONT>=20 <P><FONT color=3D#0000ff face=3DArial size=3D2><SPAN = class=3D495440606-05012000>The=20 main reason  that I believe that adding new methods is easy is = that I=20 have implemented a number of XML/DAV systems and it has repeatedly = proven=20 simpler to support new methods than new elements. This is mostly = because the=20 HTTP model is flat so that I can access things like the method name = or a=20 head directly where as with XML I have to navigate through a tree. = This is=20 the same logic that leads people to use attributes in XML, which as = I argue=20 in the WebDAV book of why is a really stupid thing to do. But I=20 digress.</SPAN></FONT>=20 <P><FONT color=3D#0000ff face=3DArial size=3D2><SPAN = class=3D495440606-05012000>As=20 for ignoring elements, it is funny to hear someone say that XML is = used to=20 ignoring elements. I first became involved with XML before it was = called=20 XML. I had helped write a proposal called Web Collections that would = later=20 be put together with a bunch of other proposals in order to become = what we=20 now know as XML. In fact, my boss at the time was Thomas Reardon who = was=20 MS's representative to the W3C and the leading proponent both at MS=20 and the W3C for XML. Now a days only the old timers = remember the=20 work he did in making XML real but in my estimation = without him=20 XML never would have taken off. As such I have been involved in = helping with=20 the XML design since day one. One of the problems we ran into with = XML when=20 it was first introduced was the question of handling unrecognized = elements.=20 At the time the SGML heads had total control over XML much to the = anger and=20 dismay of those of us born after the turn of the last century. At = the time=20 the SGML heads were arguing hard and fast against have a definition = of well=20 formidness. What they wanted to do was to require a DTD be available = for all=20 XML documents. These were the same geniuses who argued against the=20 introduction of namespaces. In fact it was their sheer cussedness = that=20 prevented us from being able to just name an XML element as a URL. = They=20 refused to allow in the forward slash and other characters that = would=20 have been necessary to allow URLs in the name of elements. That is = where the=20 namespace hack came from. Anyway, I'm digressing. So the SGML heads = were=20 arguing that you always had to have a DTD so therefore, naturally, = if you=20 had an "unrecognized" element it was an error and you should fail = the entire=20 XML document! Those of us from the post-Diluvium age were aghast.=20 Unfortunately Tim Berners-Lee (TBL) was convinced that we had to = keep=20 support of the SGML community. I remember getting lectured by Andrew = Layman=20 (who hated what the SGML guys were doing as well) about the = "millions" of=20 SGML documents out there and the need to work with them. Of course = now=20 nobody knows or cares about those ***BLEEP*** SGML documents, = but a lot=20 of the really awful crap you see in XML is the result of the deals = that TBL=20 made with the SGML guys to keep their support. TBL touches on this = topic a=20 little bit in his book. Anyway, the SGML guys were finally argued = into=20 accepting the idea of "well formidness" and thus we were freed of = needing a=20 DTD. However this left open the question of what to do when you hit = an=20 element you didn't recognize. Oh man were there flame fests on that = topic.=20 People in the protocol business tend to think of XML as just a tree = so for=20 us it is natural to just prune the XML tree at an unrecognized node. = But the=20 SGML guys don't see a tree when they see XML, they see a markup = language.=20 So, for example, imagine I have the following entry in my XML = document=20 "<p>He was a <bold>grand</bold> man!</p>. = Now let us=20 imagine that your XML parser supports the <p> tag but doesn't = support=20 <bold>. If you just pruned the tree you would end up with = "<p>He=20 was a man!</p>". That is clearly not what you want. The result = was=20 just a real mess. Some people demanded that you always prune. Some = demanded=20 that you only removed the tags but not the text. Some argued that = you should=20 have an attribute you would put on each element that would specify = what you=20 should do. There never was much of a resolution to the issue. = Eventually I=20 just got really pissed off and added what is now the first paragraph = of=20 section 14 of RFC 2518 to WebDAV declaring that we would prune any = sub-tree=20 whose root we didn't recognize. Man, did we ever catch hell for = that!=20 The XML guys told us that we wouldn't be compatible with their = XML.=20 That we were creating my own world that wouldn't work with the = rest of=20 the XML universe. Oh man, what a bloody mess. So to hear you say = that the=20 WebDAV ignore rule (as we called it) is a strength of XML is pretty = damn=20 ironic.</SPAN></FONT>=20 <P><FONT color=3D#0000ff face=3DArial size=3D2><SPAN = class=3D495440606-05012000>As=20 for HTTP generally appearing at a lower layer and not being = available from=20 the DOM, you may want to check out <A=20 = href=3D"http://msdn.microsoft.com/xml/reference/scriptref/XMLHttpRequest_= object.asp">http://msdn.microsoft.com/xml/reference/scriptref/XMLHttpRequ= est_object.asp</A> and=20 <A=20 = href=3D"http://msdn.microsoft.com/xml/reference/cvbref/IXMLHttpRequest_in= terface.asp">http://msdn.microsoft.com/xml/reference/cvbref/IXMLHttpReque= st_interface.asp</A>.=20 The links describe the XMLHTTP interface available through IE 5.0's = DOM. The=20 first link describes the interface for script programmers=20 (JScript/ECMAScript, VBscript, Python, Perl, etc.) and the second = for C/VB=20 programmers. This interface allows you to send and receive generic = HTTP=20 messages directly through IE 5.0's DOM. What is really cool about it = is that=20 while it can handle arbitrary HTTP messages it is smart so that if = you want=20 to send or if you receive a message with an XML body it will = automatically=20 detect that and automatically parse out, lode up and pass back a DOM = pointer=20 to the contents. So actually HTTP access is as free and ready as XML = access,=20 at least in IE 5.0. BTW, massive credit goes to Alex Hopmann who = nearly=20 single handedly convinced the IE guys to ship this feature. Hats off = to=20 Alex!</SPAN></FONT>=20 <P><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20 class=3D495440606-05012000></Yaron></SPAN></FONT>=20 <P>HTTP request/response parsers are not generic technology = like=20 XML parsers are <FONT color=3D#0000ff face=3DArial = size=3D2><SPAN=20 class=3D495440606-05012000> </SPAN></FONT>=20 <P><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20 class=3D495440606-05012000><Yaron></SPAN></FONT>=20 <P><FONT color=3D#0000ff face=3DArial size=3D2><SPAN = class=3D495440606-05012000>I'm=20 not sure what leads you to this conclusion. For example, = as the=20 author of the HTTP over UDP spec I found that = HTTP request/response=20 parsers were incredibly generic. This is what made HTTP = over UDP=20 so compelling. We could take existing parsers, do a little tweaking = and=20 bam, it just worked. In fact I would argue that there is no = better=20 proof of the generic nature of HTTP parsers then the existence = of=20 WebDAV. We didn't have to do any major work to support WebDAV in our = HTTP=20 request/response parsers. HTTP already understood the concept=20 of methods and headers so we were able to use the existing = parsers to=20 implement WebDAV. In fact the biggest problem we ran into is that = some folks=20 had implemented checks on what methods you could send as an error = detection=20 procedure! Sigh... In WinInet we had the problem that the devs, = in=20 order to optimize performance, had built a method mapping table that = turned=20 the method names into tokens and then moved the tokens around. = Unfortunately=20 the tokens were fixed, which meant that WinInet (our HTTP client = stack)=20 couldn't handle new methods. But the problem was easily fixed so = modern=20 versions of WinInet can handle arbitrary methods.</SPAN></FONT>=20 <P><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20 class=3D495440606-05012000></Yaron></SPAN></FONT>=20 <P>* It sounds like you are arguing against the general trend = of making=20 all of your data available via XML, which is counter to the general=20 strategies most technology companies are following now, including = Microsoft=20 and Oracle.  With your proposal, you are going to render all of = the=20 burgeoning XML technology base useless, which is why the WebDAV = people=20 built around XML in the first place. <FONT color=3D#0000ff = face=3DArial size=3D2><SPAN = class=3D495440606-05012000> </SPAN></FONT>=20 <P><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20 class=3D495440606-05012000><Yaron></SPAN></FONT>=20 <P><FONT color=3D#0000ff face=3DArial size=3D2><SPAN = class=3D495440606-05012000>I=20 was the one who introduced XML into WebDAV.</SPAN></FONT><FONT = color=3D#0000ff=20 face=3DArial size=3D2><SPAN class=3D495440606-05012000> Bonus = points to=20 anyone who remembers the original meeting when I proposed Web=20 Collections (a precursor to XML) to WebDAV. This was the first = time=20 WebDAV was introduced to what would become XML. </SPAN></FONT>=20 <P><FONT color=3D#0000ff face=3DArial size=3D2><SPAN = class=3D495440606-05012000>As=20 for Microsoft's XML strategy, that is a whole other = story. Because my=20 boss, Thomas Reardon, lead the XML effort at MS for a long time = I was=20 actually part of creating our XML strategy. When Adam Bosworth took = over XML=20 I ended up having weekly meetings with him just so that we could = synch up=20 on Microsoft XML corporate strategy. I also worked with both = Andrew=20 Layman and Jean Paoli on XML issues. I still remember = the=20 tongue lashing I gave Andrew over fully qualified end = tags.  It=20 wasn't Andrew's fault, he hated it too, but he was the messenger and = I was=20 really angry. Basically the SGML heads forced XML to adopt = fully=20 qualified end tags. In the original proposal XML markup looked = like=20 <tag>stuff</>. But the SGML heads argued that this = didn't make=20 XML readable so we should make the already mind blowingly = bloated=20 XML format even more bloated by adding fully qualified end = tags, i.e.=20 <tag>stuff</tag>. Yet another fight that they won.=20 </SPAN></FONT> <P><FONT color=3D#0000ff face=3DArial size=3D2><SPAN = class=3D495440606-05012000>As=20 such I can safely assure you that I would not do anything to "render = all of=20 the burgeoning XML technology base useless". Having helped birth XML = I would=20 certainly be reticent about killing it. After all, infanticide is a = messy=20 business. I will admit, however and Jim Whitehead will back me up, = that=20 there were plenty of times when I would have have liked to have = given XML a=20 severe spanking followed by a good amount of time in the=20 corner.</SPAN></FONT>=20 <P><FONT color=3D#0000ff><FONT face=3DArial size=3D2><SPAN=20 class=3D495440606-05012000>I used to joke about the "XML Jedi Mind = Trick." You=20 just wave your hand in front of someone and say "You will use XML". = Their=20 eyes loose focus and they repeat in a monotone voice "I will use = XML." This=20 helped a lot in early WebDAV adoption. If I couldn't convince = someone to=20 adopt WebDAV because of its own merits I would just pull the XML = Jedi Mind=20 Trick and they would adopt it because it used XML. After all, if it = uses XML=20 it must be cool!</SPAN></FONT> </FONT><FONT face=3DArial = size=3D2><SPAN=20 class=3D495440606-05012000><FONT color=3D#0000ff> There is = apparently=20 something indescribably sexy about angle=20 brackets.</FONT> </SPAN></FONT>=20 <P><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20 class=3D495440606-05012000></Yaron></SPAN></FONT>=20 <P>Is anyone thinking about a thin-client WebDAV implementation = (HTML only) running in a browser?  I should be able = to do=20 stuff like changing RSRs, manipulate directories, etc. with a web=20 app. <FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20 class=3D495440606-05012000> </SPAN></FONT>=20 <P><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20 class=3D495440606-05012000><Yaron></SPAN></FONT>=20 <P><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20 class=3D495440606-05012000>Thinking? We have already written it! = Using XMLHTTP=20 Exchange has written up an entire E-Mail client for = Exchange 2000 that=20 speaks WebDAV to their server. The whole thing is written 100% in = nothing=20 but script!!!! What is really amazing is that it uses DHTML so the = UI looks=20 almost 100% like Outlook, even down to the multiple Outlook views = and the=20 Outlook bar. It is seriously cool. I have also written, on my own, a = generic=20 WebDAV client library in JScript. Unfortunately I never = finished it.=20 Too many other things to do. </SPAN></FONT>=20 <P><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20 class=3D495440606-05012000></Yaron></SPAN></FONT>=20 <P>--Eric <FONT face=3DArial size=3D2><SPAN=20 class=3D495440606-05012000> </SPAN></FONT>=20 <P><FONT face=3DArial size=3D2><SPAN=20 = class=3D495440606-05012000>       =20 Yaron</SPAN></FONT>=20 <P><FONT face=3DArial size=3D2><SPAN=20 class=3D495440606-05012000> </SPAN></FONT>=20 <P>Yaron Goland wrote:=20 <BLOCKQUOTE TYPE=3D"CITE"> <STYLE></STYLE> <SPAN class=3D352403723-03012000><FONT face=3DArial><FONT = color=3D#0000ff><FONT=20 size=3D-1>I wouldn't accept a blanket statement that HTTP has = lousy=20 performance. I have seen it repeatedly beat the pants off all = competing=20 systems. </FONT></FONT></FONT></SPAN><SPAN=20 class=3D352403723-03012000></SPAN><SPAN = class=3D352403723-03012000><FONT=20 face=3DArial><FONT color=3D#0000ff><FONT size=3D-1>For example, we = did a speed=20 comparison of a super optimized SMB implementation and DAV in W2K. = DAV won=20 hands down. The reason is that SMB, like most protocols of its = ilk, is=20 unbelievably chatty. They are basically RPCs rather than = protocols. DAV,=20 on the other hand, is extremely optimized. So even though the SMB=20 implementation could process some ridiculous number of messages = per second=20 DAV still had better performance because it sent a hell of a lot = less=20 messages.</FONT></FONT></FONT></SPAN><SPAN=20 class=3D352403723-03012000></SPAN><SPAN = class=3D352403723-03012000><FONT=20 face=3DArial><FONT color=3D#0000ff><FONT size=3D-1>As for the use = of properties,=20 I assert that there is no difference between executing a = GETLOCKEDNAME=20 method and getting the lockedname property in terms of how you = write your=20 back end. However, the first is a hell of a lot easier to deal = with in=20 terms of specifying and extending the protocol than the second. So = the=20 issue isn't one of back end implementation, it is one of front end = convenience.</FONT></FONT></FONT></SPAN><SPAN=20 class=3D352403723-03012000></SPAN><SPAN = class=3D352403723-03012000><FONT=20 face=3DArial><FONT color=3D#0000ff><FONT size=3D-1>In other words, = just say NO=20 to live properties.</FONT></FONT></FONT></SPAN><SPAN=20 class=3D352403723-03012000></SPAN><SPAN = class=3D352403723-03012000><FONT=20 face=3DArial><FONT color=3D#0000ff><FONT=20 = size=3D-1>          &nb= sp;=20 Yaron</FONT></FONT></FONT></SPAN>=20 <BLOCKQUOTE=20 style=3D"BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; = MARGIN-RIGHT: 0px; PADDING-LEFT: 5px"> <DIV class=3DOutlookMessageHeader dir=3Dltr><FONT = face=3DTahoma><FONT=20 size=3D-1>-----Original Message-----</FONT></FONT> <BR><FONT=20 face=3DTahoma><FONT size=3D-1><B>From:</B> Eric Sedlar [<A=20 = href=3D"mailto:esedlar@us.oracle.com">mailto:esedlar@us.oracle.com</A>]</= FONT></FONT>=20 <BR><FONT face=3DTahoma><FONT size=3D-1><B>Sent:</B> Monday, = January 03,=20 2000 1:09 PM</FONT></FONT> <BR><FONT face=3DTahoma><FONT=20 size=3D-1><B>To:</B> Yaron Goland</FONT></FONT> <BR><FONT=20 face=3DTahoma><FONT size=3D-1><B>Cc:</B> = w3c-dist-auth@w3.org</FONT></FONT>=20 <BR><FONT face=3DTahoma><FONT size=3D-1><B>Subject:</B> Re: Your = proposal</FONT></FONT> <BR> </DIV><FONT face=3DArial><FONT=20 size=3D-1>One problem with your qualms about properties is that = we are=20 trying to map WebDAV data to object representation systems that = do not=20 have functional semantics, like XML.  We should define an = interface=20 that doesn't rely on the distinction between functional = interfaces and=20 properties for maximum implementability on various = servers.  (This=20 distinction is something may programmers have trouble with--does = everyone always bother to create accessor methods for = everything? =20 ...)  The benefit of using live properties as a = representation is=20 that object properties are more "portable" to the other types of = systems=20 that may want to access the same data, presumably through = another means=20 than the HTTP protocol (which isn't particularly = efficient). =20 (Which brings me to another unrelated issue--should there be a=20 functional interface to WebDAV methods for programs living in = the same=20 server as the data repository, given the performance costs of = HTTP=20 within a single process--more on that = later).</FONT></FONT> <FONT=20 face=3DArial><FONT size=3D-1>Yes you need a set of clear rules = for how live=20 properties are used, and unless their use is rigorously = controlled, you=20 will have compatability problems of the type you cite, but this = is a=20 problem with any loosely written standard.</FONT></FONT><FONT=20 face=3DArial><FONT size=3D-1>I think of properties in the = JavaBeans=20 sense--in an OO language binding, they would actually be = functional=20 interfaces to set and retrieve them, but could be overridden to = provide=20 customized behaviour.  Any JavaBeans user has no idea = whether or=20 not this piece of data is live or not, and this model works=20 well.</FONT></FONT> <FONT face=3DArial><FONT=20 size=3D-1>--Eric</FONT></FONT>=20 <BLOCKQUOTE=20 style=3D"BORDER-LEFT: #000000 2px solid; MARGIN-LEFT: 5px; = MARGIN-RIGHT: 0px; PADDING-LEFT: 5px; PADDING-RIGHT: 0px"> <DIV style=3D"FONT: 10pt arial">----- Original Message = -----</DIV> <DIV=20 style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: = black"><B>From:</B>=20 <A href=3D"mailto:yarong@Exchange.Microsoft.com"=20 title=3Dyarong@Exchange.Microsoft.com>Yaron Goland</A></DIV> <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A=20 href=3D"mailto:esedlar@us.oracle.com" = title=3Desedlar@us.oracle.com>'Eric=20 Sedlar'</A></DIV> <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Monday, January = 03, 2000=20 11:18 AM</DIV> <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> Your=20 proposal</DIV> <FONT face=3DArial><FONT size=3D-1>Eric, I = read your=20 analysis of Geoff's proposal and was really impressed by your = deep=20 grasp of both HTTP and WebDAV.</FONT></FONT>=20 <P><FONT face=3DArial><FONT size=3D-1>I have a series of = issues with your=20 counter-proposal but I'm going to hold off on commenting until = we can=20 build up more of a common base for conversation. Please see my = post on=20 the mailing list in regards to this.</FONT></FONT>=20 <P><FONT face=3DArial><FONT size=3D-1>I did, however, want to = point out a=20 general design issue regarding your proposal that isn't = directly=20 related to locks. In your proposal you suggest using = properties to=20 provide various bits of protocol information, such as which = names are=20 currently locked. I would caution against using properties in = this=20 way, see <A=20 = href=3D"http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0302= .html"=20 = target=3D_blank>http://lists.w3.org/Archives/Public/w3c-dist-auth/1998Oct= Dec/0302.html</A>=20 for more details. For a history of how we ended up in this = mess in the=20 first place see <A=20 = href=3D"http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0074= .html"=20 = target=3D_blank>http://lists.w3.org/Archives/Public/w3c-dist-auth/1998Oct= Dec/0074.html</A>=20 and <A=20 = href=3D"http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0303= .html"=20 = target=3D_blank>http://lists.w3.org/Archives/Public/w3c-dist-auth/1998Oct= Dec/0303.html</A>.=20 BTW, all of these posts are collected in the WebDAV Book of = Why=20 available at <A=20 = href=3D"http://lists.w3.org/Archives/Public/w3c-dist-auth/1999JanMar/0129= .html"=20 = target=3D_blank>http://lists.w3.org/Archives/Public/w3c-dist-auth/1999Jan= Mar/0129.html</A>.</FONT></FONT>=20 = <P>           &nbs= p;   =20 <FONT face=3DArial><FONT size=3D-1>Thanks,</FONT></FONT>=20 = <BR>           &nb= sp;           &nbs= p;       =20 <FONT face=3DArial><FONT=20 = size=3D-1>Yaron</FONT></FONT></P></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE><= /BLOCKQUOTE></BLOCKQUOTE></BODY></HTML> ------=_NextPart_000_01A4_01BF7EBC.1DD67A90-- From w3c-dist-auth-request@w3.org Thu Feb 24 16:56:46 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11383 for <webdav-archive@odin.ietf.org>; Thu, 24 Feb 2000 16:56:46 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA05664; Thu, 24 Feb 2000 16:51:59 -0500 (EST) Resent-Date: Thu, 24 Feb 2000 16:51:59 -0500 (EST) Resent-Message-Id: <200002242151.QAA05664@www19.w3.org> To: "Slein, Judith A" <JSlein@crt.xerox.com> cc: w3c-dist-auth@w3.org In-reply-to: Your message of "Thu, 24 Feb 2000 13:36:29 EST." <8E3CFBC709A8D21191A400805F15E0DB0211F973@crte147.wc.eso.mc.xerox.com> Date: Thu, 24 Feb 2000 13:51:02 -0800 From: "Roy T. Fielding" <fielding@kiwi.ICS.UCI.EDU> Message-ID: <200002241351.aa07005@gremlin-relay.ics.uci.edu> Subject: Re: Qualities of URLs and resources Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/4152 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list >In response to your comments about the nature of resources, we plan to >remove from the binding spec all language that suggests that resources are >storage entities. We think that otherwise, the spec is consistent with the >view that a resource is a mapping function. > >We will change the definition of binding to state explicitly that it is not >a resource, but is rather part of the state of a collection resource. >Although I think this conflicts with your position, it at least makes our >position clearer. Almost. Anything that is identifiable by a URI is a resource, which pretty much covers everything that can be identified as a concept. So, you are better off not explicitly saying that a binding is not a resource. What you want to say is simply that the target of the bind requests is the collection resource, and the bindings are considered to be part of the state of that collection for the purposes of those requests. Whether or not those bindings identify a resource, or are resources in themselves, is not relevent during the scope of the client/server conversation. ....Roy From w3c-dist-auth-request@w3.org Thu Feb 24 17:55:54 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12288 for <webdav-archive@odin.ietf.org>; Thu, 24 Feb 2000 17:55:53 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA07650; Thu, 24 Feb 2000 17:51:22 -0500 (EST) Resent-Date: Thu, 24 Feb 2000 17:51:22 -0500 (EST) Resent-Message-Id: <200002242251.RAA07650@www19.w3.org> Message-ID: <65B141FB11CCD211825700A0C9D609BC01D4D71E@chef.lex.rational.com> From: "Clemm, Geoff" <gclemm@Rational.Com> To: "'Roy T. Fielding'" <fielding@kiwi.ICS.UCI.EDU>, "Slein, Judith A" <JSlein@crt.xerox.com> Cc: w3c-dist-auth@w3.org Date: Thu, 24 Feb 2000 17:38:20 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Qualities of URLs and resources Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/4153 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list There are some concepts that explicitly are not resources, e.g. the concept of a "URI" or the concept of a "property". Like URI's and properties, a binding is not something that is identified by a URI, and is not something to which you can apply requests. Instead, a binding is just a term we use to talk about how a collection resource behaves, e.g. if at time T, a collection resource has a binding named "foo" to a resource with DAV:resourceid "xxx", then this is just a shorthand for saying that a depth:1 PROPFIND at time T on any URL that is mapped to that collection will return a DAV:response with a DAV:href whose value is "<that URL>/foo" and with a DAV:resourceid whose value is "xxx". In other words, all URI's that are mapped to that collection at time T will have a member named foo, and the DAV:resourceid of that member will be "xxx". Cheers, Geoff -----Original Message----- From: Roy T. Fielding [mailto:fielding@kiwi.ICS.UCI.EDU] Sent: Thursday, February 24, 2000 4:51 PM To: Slein, Judith A Cc: w3c-dist-auth@w3.org Subject: Re: Qualities of URLs and resources >In response to your comments about the nature of resources, we plan to >remove from the binding spec all language that suggests that resources are >storage entities. We think that otherwise, the spec is consistent with the >view that a resource is a mapping function. > >We will change the definition of binding to state explicitly that it is not >a resource, but is rather part of the state of a collection resource. >Although I think this conflicts with your position, it at least makes our >position clearer. Almost. Anything that is identifiable by a URI is a resource, which pretty much covers everything that can be identified as a concept. So, you are better off not explicitly saying that a binding is not a resource. What you want to say is simply that the target of the bind requests is the collection resource, and the bindings are considered to be part of the state of that collection for the purposes of those requests. Whether or not those bindings identify a resource, or are resources in themselves, is not relevent during the scope of the client/server conversation. ....Roy From w3c-dist-auth-request@w3.org Thu Feb 24 23:54:14 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18915 for <webdav-archive@odin.ietf.org>; Thu, 24 Feb 2000 23:54:13 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id XAA14874; Thu, 24 Feb 2000 23:44:47 -0500 (EST) Resent-Date: Thu, 24 Feb 2000 23:44:47 -0500 (EST) Resent-Message-Id: <200002250444.XAA14874@www19.w3.org> Message-ID: <65B141FB11CCD211825700A0C9D609BC0205B024@chef.lex.rational.com> From: "Clemm, Geoff" <gclemm@Rational.Com> To: w3c-dist-auth@w3.org Date: Thu, 24 Feb 2000 23:32:09 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Yaron.Redirect.ClientUpdate Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/4156 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list I don't think that the "method for each variant of each operation" scales. I can think of 4 or 5 groups that would like to pick SUBSCRIBE to mean something slightly different. One of the advantages of live properties is that they have a built-in namespace mechanism. I agree that this will mean that servers will need two extra dispatch points (i.e. in PROPFIND and PROPPATCH), but I believe that is a small price to pay in order to avoid name collisions as more extensions to WebDAV are developed. Note: there currently are few enough WebDAV extensions, that I could get the names I want for bindings, redirect references, and even versioning, but I can already the cursing of subsequent protocol developers as they discover that all the meaningful method names in their domain have been used by the first wave of protocol developers. Cheers, Geoff > -----Original Message----- > From: Yaron Goland [mailto:yarong@Exchange.Microsoft.com] > Sent: Thursday, February 24, 2000 1:55 AM > To: 'Slein, Judith A'; w3c-dist-auth@w3.org; 'yarong@goland.org' > Subject: RE: Yaron.Redirect.ClientUpdate > > > We can either let them use MKREF to update it or we can introduce a > UPDATEREFTARGET method. Lately I have been leaning to introducing new > methods in order to simplify the standard text. Re-using > existing methods > for related functionality has proven to make specs harder to read. For > example, in my GENA spec I specified that SUBSCRIBE can be > used with a NT > header to create a subscription and with a Subscription-ID > header but no NT > header to renew a subscription. The result is that I had to > put in some > fairly confusing language to explain what to do if a request > has both a NT > and a Subscription-ID header. After that experience I just introduce a > RESUBSCRIBE method to simplify things. Of course, this isn't a perfect > solution since the more methods you have the more things > people have to put > on their slides when they explain WebDAV. =) > > > -----Original Message----- > > From: Slein, Judith A [mailto:JSlein@crt.xerox.com] > > Sent: Mon, February 21, 2000 12:52 PM > > To: Yaron Goland; w3c-dist-auth@w3.org > > Subject: RE: Yaron.Redirect.ClientUpdate > > > > > > As long as we have the DAV:reftarget property, the obvious > > thing to do is > > allow clients to update its value. If you want to get rid of > > that property, > > as it seems you do from NoWebDAV#3, then I suppose we would > > need something > > like an UPDATEREFTARGET method. > > > > --Judy > > > > -----Original Message----- > > From: Yaron Goland [mailto:yarong@Exchange.Microsoft.com] > > Sent: Friday, February 11, 2000 2:57 AM > > To: 'w3c-dist-auth@w3.org' > > Subject: Yaron.Redirect.ClientUpdate > > > > > > > > Maybe I just missed it but there doesn't seem to be any way > > to update the > > target of a redirection resource without deleting it. I move that a > > mechanism be provided that enables the target of a > > redirection resource to > > be updated without having to delete the resource. > > > From w3c-dist-auth-request@w3.org Thu Feb 24 23:54:16 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18926 for <webdav-archive@odin.ietf.org>; Thu, 24 Feb 2000 23:54:15 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id XAA14824; Thu, 24 Feb 2000 23:44:34 -0500 (EST) Resent-Date: Thu, 24 Feb 2000 23:44:34 -0500 (EST) Resent-Message-Id: <200002250444.XAA14824@www19.w3.org> Message-ID: <65B141FB11CCD211825700A0C9D609BC0205B023@chef.lex.rational.com> From: "Clemm, Geoff" <gclemm@Rational.Com> To: w3c-dist-auth@w3.org Date: Thu, 24 Feb 2000 23:32:07 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Yaron.Redirect.S10 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/4154 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list I disagree that an O(N) cost on error should cause us to eliminate behavior that is both useful and expected by clients (at least, by clients used to file-system implementations of redirect references, such as sym-links on Unix). First, the "N" here is very small (5, 10, not 1000). Second, it is likely that servers will have to do this anyway when ACL's are introduced (you will have to check if you have a READ ACL to each collection in the path). And finally, the cost of doing this lookup is likely to have been so optimized by the underlying system that the total cost will be minimal in any case. Cheers, Geoff > -----Original Message----- > From: Yaron Goland [mailto:yarong@Exchange.Microsoft.com] > Sent: Thursday, February 24, 2000 1:53 AM > To: 'Slein, Judith A'; w3c-dist-auth@w3.org; 'yaron@goland.org' > Subject: RE: Yaron.Redirect.S10 > > > The main contention in Judy's comments is that implementing > the section 10 > rules isn't that bad because you can always do a hash look up > first on a > name and if you don't get a hit then you can begin the > segment by segment > walk. I disagree with the assessment that the cost is > trivial. Every single > time a URL mis-hits the server will be forced to spend time > walking all of > its segments in order to figure out if the URL may point to a redirect > resource. The cost of processing a bogus URL has gone from > O(1) to O(N). > That makes it very easy to use bogus URLs as a denial of > service attack. > > This all begs the issue, BTW, of the fact that the design means that > processing URLs correctly pointing to redirect resources will > cost O(N). > > All this having been said, as I indicate below, I understand > why the authors > want to make redirect resources behave as they have specified and I am > sympathetic to their goals. I think the best compromise is > for us to create > two types of redirect resources (created by two different > methods). One type > is a simple HTTP redirect resource. No fancy namespace rules. > No section 10 > behavior. All it does is blindly return a 302 to a certain > value, that is > it. It doesn't matter if it is in a WebDAV namespace or not. > It just returns > a 302. Then we create a complex HTTP redirect resource with section 10 > behavior. People who want to take on the O(N) costs > associated with it are > free to do so. But let's not penalize WebDAV implementers who > just want a > simple 302 by forcing a O(N) solution on them. > > As for my comment regarding paragraph 3 of section 10, I > agree with Judy's > comment that my analysis is flawed and so remove my comment. > > Yaron > > > > -----Original Message----- > > From: Slein, Judith A [mailto:JSlein@crt.xerox.com] > > Sent: Mon, February 21, 2000 12:25 PM > > To: Yaron Goland; w3c-dist-auth@w3.org > > Subject: RE: Yaron.Redirect.S10 > > > > > > Comments interspersed in <js></js> tags. > > > > -----Original Message----- > > From: Yaron Goland [mailto:yarong@Exchange.Microsoft.com] > > Sent: Friday, February 11, 2000 2:54 AM > > To: 'w3c-dist-auth@w3.org' > > Subject: Yaron.Redirect.S10 > > > > > > > > Section 10 of the redirect spec requires that given a HTTP URL > > http://foo/bar/blah <http://foo/bar/blah> as the request-URI > > of a method if > > http://foo/ <http://foo/> or http://foo/bar/ <http://foo/bar/> are > > redirect resources then the request must be redirected to the > > locations > > specified by those redirect resources with the remaining part of the > > request-URI appended to the redirection location. This means > > that when a > > HTTP URL is submitted the server must examine each segment of > > the URL and > > determine if any of those segments point to a redirect > > resource. This means > > that every time a URL is submitted a minimum of N lookups > > must occur where N > > equals the number of segments of the URL. This has a > > devastating effect on > > efficiency. > > > > <js> I don't think it's quite that bad. The server would > > probably first > > check whether it has a mapping for the whole URI. Only if it > > doesn't would > > the server have to start checking subpaths. So it's more > > complicated code, > > but not a dramatic effect on efficiency. </js> > > > > In the current HTTP system one can implement a HTTP URL to > > resource mapping > > mechanism in two steps. > > > > Step 1 - Look up the name and get back the internal pointer > > to the resource. > > > > Step 2 - Use internal point to submit method to resource. > > > > Section 10 changes this, for all HTTP URL namespaces that > > have redirect > > support, to be: > > > > For (segment 1 to segment N) { > > If (typeof(segment) == redirect) { > > Issue 300 > > } > > } > > Segment(Method) > > > > The section 10 requirement would be the first time we ever > > required that the > > processing of a URL to resource mapping was dependent on the > > state of any > > resource other than the target. This seems like a really bad > > precedent to > > set as it significantly increases the complexity and cost of > > handling HTTP. > > > > In addition this requirement makes it very difficult and extremely > > inefficient to distribute one's namespace. If one wants to > > put http://foo/ > > <http://foo/> on one server, http://foo/bar <http://foo/bar> > > on another > > server and http://foo/bar/blah <http://foo/bar/blah> on a > > third server then > > any requests to http://foo/bar/blah <http://foo/bar/blah> > > MUST be sent to > > the two others servers in order to figure out if any of them > > is a redirect > > resources. This is an enormous burden to put on implementers > > wishing to > > distribute their namespace. (Note that in a WebDAV consistent > > namespace > > there would be a similar requirement but it would only apply to the > > immediate parent and so at most one other system, not N other > > systems as the > > redirect draft requires.) > > > > <js> Again, you would first attempt to resolve the URL in the > > usual way, and > > only if that fails would you have to start checking sub-paths > > instead of > > rejecting the request out of hand. </js> > > > > This all having been said, the motive behind introducing the > > section 10 > > behavior is clear and reasonable. The desire is to enable > > redirect resources > > to create the same experience for the end user as a bind > > resource. However > > here we run into an issue that is peculiar to HTTP. HTTP's resource > > namespace is not consistent. Even the WebDAV namespace, if > non-WebDAV > > resources are included, is not required to be consistent. Namespace > > consistency brings with it too high a cost in terms of > > coordination and > > complexity to be mandatory. > > > > Therefore, at minimum, we require a type of redirect resource > > that does not > > have the section 10 behavior. This resource would expose the > > behavior we see > > today in various HTTP servers that allow their users to create 300 > > resources. Therefore I move that a type of redirect resource > > be specified in > > the redirect spec that does not have section 10 behavior. > > > > That having been said I am sympathetic to the desire to have > > the section 10 > > rules. They certainly replicate the behavior seen today in > > many systems. As > > such I will not object to the inclusion of a redirect > > resource with section > > 10 behavior in the redirect spec. However I do move that the > > authors must > > address the issue of what happens when the redirection > > location isn't a HTTP > > URL. How do we handle a request for http://foo/bar/blah > > <http://foo/bar/blah> when http://foo/bar <http://foo/bar> > > is a redirect > > resource to ftp://itsy/bitsy <ftp://itsy/bitsy> ? > > > > <js> We haven't really discussed this type of case, and you > > are right that > > we have to address it somehow. In the particular example you > > give, we could > > just have the server follow the rules in section 10, and > > respond with a 302 > > and Location: ftp://itsy/bitsy/blah <ftp://itsy/bitsy/blah> . > > The client > > would then have to figure out whether there is anything in > > ftp corresponding > > to the method in its original request. </js> > > > > Paragraph 3 of section 10 reads: > > > > Note: If the DAV:reftarget property ends with a "/" and the > > remainder of > > the Request-URI is non-empty (and therefore must begin with a > > "/"), the > > final "/" in the DAV:reftarget property is dropped before the > > remainder > > of the Request-URI is appended. > > > > This behavior is in contradiction to both RFC 2518 and RFC > > 2616. Resources > > that end with a "/" are currently considered different > > resources from those > > that do not end with a "/". This is exactly the same issue > > brought up in > > Yaron.NoSlash ( > > > http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/0069.html > > <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/ > 0069.html> ) > and I would love to see option 2 as listed there adopted. > Failing that the > authors must adopt option 1 and change the draft. Either way, > I move that > the authors must address this issue based on the requirements > placed in > Yaron.NoSlash. > > <js> I don't think this does raise the same issue. All we > are doing here is > making sure that you don't end up with a URL that has 2 > consecutive slashes > in the middle somewhere. </js> > From w3c-dist-auth-request@w3.org Thu Feb 24 23:54:23 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18937 for <webdav-archive@odin.ietf.org>; Thu, 24 Feb 2000 23:54:21 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id XAA14845; Thu, 24 Feb 2000 23:44:40 -0500 (EST) Resent-Date: Thu, 24 Feb 2000 23:44:40 -0500 (EST) Resent-Message-Id: <200002250444.XAA14845@www19.w3.org> Message-ID: <65B141FB11CCD211825700A0C9D609BC0205B025@chef.lex.rational.com> From: "Clemm, Geoff" <gclemm@Rational.Com> To: w3c-dist-auth@w3.org Date: Thu, 24 Feb 2000 23:32:11 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: An analysis of the proposal to place locks on URIs rather tha n re sources Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/4155 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list I'll answer Edgar's question immediately, since it is nice and short ... I will respond to Yaron's post later since it is nice and long (:-). But my answer to Edgar and my response to Yaron have the same basis, namely that when I said "a lock is on a URL", I was really saying a lock "acts" like it is on a URL. The fact that a lock is *really* on a resource is detailed in the GULP (Grand Unified Locking Proposal). In particular, it is really on the first WebDAV collection encountered on the path. It is then just inherited by resources below. But before this goes too much farther, I should state that GULP was a somewhat academic exercise to develop a complete model that would provide consistent answers to all the depth locking, null resource locking, and URL protection issues that have arisen on the mailing list. My conclusion is that we just have to simplify. In particular, I believe we have to keep URL protection, but that depth locking and null resources must go in order to have a locking model that will be be implementable and understandable in conjunction with protocol extensions such as bindings and versioning. And in a Simple LOcking Proposal (SLOP :-), locks will be back to being on resources, which Yaron will like, until he hears that this means that a lock should move with a resource when that resource is MOVE'd, which he will vigorously protest against (if he has time to do so :-). Cheers, Geoff > -----Original Message----- > From: Edgar Schwarz [mailto:Edgar.Schwarz@marconicomms.com] > Sent: Thursday, February 24, 2000 5:13 AM > To: w3c-dist-auth@w3.org > Subject: Re: An analysis of the proposal to place locks on URIs rather > than re sources > > > Yaron Goland wrote: > > Sorry, no time for a comment to Yaron's stuff at the moment :-) > > > > From: Geoffrey M. Clemm [mailto:geoffrey.clemm@rational.com] > > > Sent: Thu, December 30, 1999 2:33 PM > > > > As an addendum to Yaron's response, I'll note that there > is a proposal > > > that WebDAV locking is better understood as locks on > URL's rather than > > > on resources. > I'm not sure I understand. Does that mean that you can't lock > a resource > anymore with WebDAV ? > I wouldn't like this idea. Or do you propose another mechanism for > locking a resource ? > > Cheers, Edgar > > P.S. Sorry if this topic was already solved in the meantime > but I didn't > have time to follow the discussions for a while. > > -- > Edgar.Schwarz@marconicomms.com, Marconi Communications, > 07191/13-3382 > Privat kann jeder soviel C programmieren oder Videos ansehen > wie er mag. > Albert Einstein: Mach es so einfach wie moeglich, aber nicht > einfacher. > From w3c-dist-auth-request@w3.org Fri Feb 25 00:27:57 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19926 for <webdav-archive@odin.ietf.org>; Fri, 25 Feb 2000 00:27:55 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id AAA15961; Fri, 25 Feb 2000 00:17:37 -0500 (EST) Resent-Date: Fri, 25 Feb 2000 00:17:37 -0500 (EST) Resent-Message-Id: <200002250517.AAA15961@www19.w3.org> To: "Clemm, Geoff" <gclemm@rational.com> cc: "Slein, Judith A" <JSlein@crt.xerox.com>, w3c-dist-auth@w3.org In-reply-to: Your message of "Thu, 24 Feb 2000 17:38:20 EST." <65B141FB11CCD211825700A0C9D609BC01D4D71E@chef.lex.rational.com> Date: Thu, 24 Feb 2000 21:17:09 -0800 From: "Roy T. Fielding" <fielding@kiwi.ICS.UCI.EDU> Message-ID: <200002242117.aa08003@gremlin-relay.ics.uci.edu> Subject: Re: Qualities of URLs and resources Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/4157 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list >There are some concepts that explicitly are not resources, >e.g. the concept of a "URI" or the concept of a "property". Nope. If the concept is referenceable, it is a resource. If you ask me for the URL that I was using to represent my home page in 1994, you are referring to a URI as a resource in itself. All properties are resources -- DAV just defines a different way of accessing them than the old HTTP interface. The only reason it did so is because some people felt that adding direct access to properties was better than paying for one round trip. >Like URI's and properties, a binding is not >something that is identified by a URI, and is not something >to which you can apply requests. Instead, a binding >is just a term we use to talk about how a collection >resource behaves, e.g. if at time T, a collection resource has a >binding named "foo" to a resource with DAV:resourceid "xxx", then >this is just a shorthand for saying that a >depth:1 PROPFIND at time T on any URL that is mapped to that collection >will return a DAV:response with a DAV:href whose value is >"<that URL>/foo" and with a DAV:resourceid whose value is "xxx". > >In other words, all URI's that are mapped to that collection at time >T will have a member named foo, and the DAV:resourceid of that member >will be "xxx". For any concept X, it is possible to create an identifier namespace obeying the requirements of RFC 2396 such that concept X is unambiguously identified within the scope of the namespace's usage. It is therefore possible to identify any concept with a URI, which makes it a resource. BTW, DAV:resourceid is an abomination. It breaks the implementation abstraction that is at the core of the Web interface. Telling server implementors to reveal that information is wrong and is completely unnecessary to define the protocol. ....Roy From w3c-dist-auth-request@w3.org Fri Feb 25 02:06:16 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01145 for <webdav-archive@odin.ietf.org>; Fri, 25 Feb 2000 02:06:16 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id BAA18263; Fri, 25 Feb 2000 01:57:00 -0500 (EST) Resent-Date: Fri, 25 Feb 2000 01:57:00 -0500 (EST) Resent-Message-Id: <200002250657.BAA18263@www19.w3.org> Message-ID: <7DE119D3D0E15543874F7561EECBDBED030B541D@BEG.platinum.corp.microsoft.com> From: Yaron Goland <yarong@Exchange.Microsoft.com> To: "'Clemm, Geoff'" <gclemm@Rational.Com>, w3c-dist-auth@w3.org Date: Thu, 24 Feb 2000 22:35:27 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Yaron.Redirect.ClientUpdate Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/4158 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Geoff, I hope you aren't seriously expecting me to engage in a debate with you whose foundation is the need to preserve pretty method names. It really doesn't matter if the name is SUBSCRIBE or S#*&!@. Other than the later will probably cause more typo-s. If using multiple names will help interoperability and my experience leads me to believe that this is so, then we should use multiple names. To hell with conserving pretty names. > -----Original Message----- > From: Clemm, Geoff [mailto:gclemm@Rational.Com] > Sent: Thu, February 24, 2000 8:32 PM > To: w3c-dist-auth@w3.org > Subject: RE: Yaron.Redirect.ClientUpdate > > > I don't think that the "method for each variant of each operation" > scales. I can think of 4 or 5 groups that would like to pick > SUBSCRIBE > to mean something slightly different. One of the advantages of live > properties is that they have a built-in namespace mechanism. I agree > that this will mean that servers will need two extra dispatch points > (i.e. in PROPFIND and PROPPATCH), but I believe that is a small price > to pay in order to avoid name collisions as more extensions to WebDAV > are developed. > > Note: there currently are few enough WebDAV extensions, that > I could get > the names I want for bindings, redirect references, and even > versioning, > but I can already the cursing of subsequent protocol developers > as they discover that all the meaningful method names in their domain > have been used by the first wave of protocol developers. > > Cheers, > Geoff > > > -----Original Message----- > > From: Yaron Goland [mailto:yarong@Exchange.Microsoft.com] > > Sent: Thursday, February 24, 2000 1:55 AM > > To: 'Slein, Judith A'; w3c-dist-auth@w3.org; 'yarong@goland.org' > > Subject: RE: Yaron.Redirect.ClientUpdate > > > > > > We can either let them use MKREF to update it or we can introduce a > > UPDATEREFTARGET method. Lately I have been leaning to > introducing new > > methods in order to simplify the standard text. Re-using > > existing methods > > for related functionality has proven to make specs harder > to read. For > > example, in my GENA spec I specified that SUBSCRIBE can be > > used with a NT > > header to create a subscription and with a Subscription-ID > > header but no NT > > header to renew a subscription. The result is that I had to > > put in some > > fairly confusing language to explain what to do if a request > > has both a NT > > and a Subscription-ID header. After that experience I just > introduce a > > RESUBSCRIBE method to simplify things. Of course, this > isn't a perfect > > solution since the more methods you have the more things > > people have to put > > on their slides when they explain WebDAV. =) > > > > > -----Original Message----- > > > From: Slein, Judith A [mailto:JSlein@crt.xerox.com] > > > Sent: Mon, February 21, 2000 12:52 PM > > > To: Yaron Goland; w3c-dist-auth@w3.org > > > Subject: RE: Yaron.Redirect.ClientUpdate > > > > > > > > > As long as we have the DAV:reftarget property, the obvious > > > thing to do is > > > allow clients to update its value. If you want to get rid of > > > that property, > > > as it seems you do from NoWebDAV#3, then I suppose we would > > > need something > > > like an UPDATEREFTARGET method. > > > > > > --Judy > > > > > > -----Original Message----- > > > From: Yaron Goland [mailto:yarong@Exchange.Microsoft.com] > > > Sent: Friday, February 11, 2000 2:57 AM > > > To: 'w3c-dist-auth@w3.org' > > > Subject: Yaron.Redirect.ClientUpdate > > > > > > > > > > > > Maybe I just missed it but there doesn't seem to be any way > > > to update the > > > target of a redirection resource without deleting it. I > move that a > > > mechanism be provided that enables the target of a > > > redirection resource to > > > be updated without having to delete the resource. > > > > > > From w3c-dist-auth-request@w3.org Fri Feb 25 02:06:17 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01157 for <webdav-archive@odin.ietf.org>; Fri, 25 Feb 2000 02:06:17 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id BAA18299; Fri, 25 Feb 2000 01:57:06 -0500 (EST) Resent-Date: Fri, 25 Feb 2000 01:57:06 -0500 (EST) Resent-Message-Id: <200002250657.BAA18299@www19.w3.org> Message-ID: <7DE119D3D0E15543874F7561EECBDBED030B541C@BEG.platinum.corp.microsoft.com> From: Yaron Goland <yarong@Exchange.Microsoft.com> To: "'Clemm, Geoff'" <gclemm@Rational.Com>, w3c-dist-auth@w3.org, "'yaron@goland.org'" <yaron@goland.org> Date: Thu, 24 Feb 2000 22:28:21 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: An analysis of the proposal to place locks on URIs rather tha n re sources Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/4159 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list The only reason I don't like moving locks on resources is that many existing systems CAN NOT do it. So if you define it then the Windows world will ignore WebDAV and implement what it's system can actually support. In the purely theoretical sense I have no problem with locks moving with a resource, so long as the lock owner is the one who did the move. BTW, I bet you still end up with a NULL resource or the moral equivalent. > -----Original Message----- > From: Clemm, Geoff [mailto:gclemm@Rational.Com] > Sent: Thu, February 24, 2000 8:32 PM > To: w3c-dist-auth@w3.org > Subject: RE: An analysis of the proposal to place locks on URIs rather > tha n re sources > > > > I'll answer Edgar's question immediately, since it is nice > and short ... > I will respond to Yaron's post later since it is nice and long (:-). > But my answer to Edgar and my response to Yaron have the same basis, > namely that when I said "a lock is on a URL", I was really > saying a lock > "acts" like it is on a URL. The fact that a lock is *really* on a > resource is detailed in the GULP (Grand Unified Locking Proposal). > In particular, it is really on the first WebDAV collection encountered > on the path. It is then just inherited by resources below. > > But before this goes too much farther, I should state that GULP was > a somewhat academic exercise to develop a complete model that would > provide consistent answers to all the depth locking, null resource > locking, and URL protection issues that have arisen on the mailing > list. > > My conclusion is that we just have to simplify. In > particular, I believe > we have to keep URL protection, but that depth locking and > null resources > must go in order to have a locking model that will be be implementable > and understandable in conjunction with protocol extensions > such as bindings > and versioning. > > And in a Simple LOcking Proposal (SLOP :-), locks will be > back to being > on resources, which Yaron will like, until he hears that this > means that > a lock should move with a resource when that resource is MOVE'd, which > he will vigorously protest against (if he has time to do so :-). > > Cheers, > Geoff > > > > -----Original Message----- > > From: Edgar Schwarz [mailto:Edgar.Schwarz@marconicomms.com] > > Sent: Thursday, February 24, 2000 5:13 AM > > To: w3c-dist-auth@w3.org > > Subject: Re: An analysis of the proposal to place locks on > URIs rather > > than re sources > > > > > > Yaron Goland wrote: > > > > Sorry, no time for a comment to Yaron's stuff at the moment :-) > > > > > > From: Geoffrey M. Clemm [mailto:geoffrey.clemm@rational.com] > > > > Sent: Thu, December 30, 1999 2:33 PM > > > > > > As an addendum to Yaron's response, I'll note that there > > is a proposal > > > > that WebDAV locking is better understood as locks on > > URL's rather than > > > > on resources. > > I'm not sure I understand. Does that mean that you can't lock > > a resource > > anymore with WebDAV ? > > I wouldn't like this idea. Or do you propose another mechanism for > > locking a resource ? > > > > Cheers, Edgar > > > > P.S. Sorry if this topic was already solved in the meantime > > but I didn't > > have time to follow the discussions for a while. > > > > -- > > Edgar.Schwarz@marconicomms.com, Marconi Communications, > > 07191/13-3382 > > Privat kann jeder soviel C programmieren oder Videos ansehen > > wie er mag. > > Albert Einstein: Mach es so einfach wie moeglich, aber nicht > > einfacher. > > > From w3c-dist-auth-request@w3.org Fri Feb 25 02:11:38 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01622 for <webdav-archive@odin.ietf.org>; Fri, 25 Feb 2000 02:11:37 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id CAA18542; Fri, 25 Feb 2000 02:02:24 -0500 (EST) Resent-Date: Fri, 25 Feb 2000 02:02:24 -0500 (EST) Resent-Message-Id: <200002250702.CAA18542@www19.w3.org> Message-ID: <7DE119D3D0E15543874F7561EECBDBED02619E68@BEG.platinum.corp.microsoft.com> From: Yaron Goland <yarong@Exchange.Microsoft.com> To: "'Clemm, Geoff'" <gclemm@Rational.Com>, w3c-dist-auth@w3.org Date: Thu, 24 Feb 2000 22:44:46 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Yaron.Redirect.S10 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/4160 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Point #1 - I agree that we need a redirect resource with the full path behavior. However, we also need a type of redirect resource that does NOT have the path behavior. In other words, I am asking that we have two types of redirect resource. Point #2 - Your ACL analysis is inconsistent with at least Windows design. In Windows when you set an ACL on a collection inheritance is done at the time the ACL is set. This means that when doing a look up you only need to check the individual file, not its parents, since any settings from the parents that would affect the child would already have been propagated. This behavior is typical for systems with high read rates. They put the onus on non-read commands to leave the system in such a state as reads will be very fast. This usually means that non-read commands are responsible for updating the state of all resources such that when a read is executed it can be implemented without having to refer to any resource but the target. This, of course, slows down the performance of non-read commands but in most systems there are many more reads than just about any command but write and write is usually so super localized in its effect that this isn't a problem. > -----Original Message----- > From: Clemm, Geoff [mailto:gclemm@Rational.Com] > Sent: Thu, February 24, 2000 8:32 PM > To: w3c-dist-auth@w3.org > Subject: RE: Yaron.Redirect.S10 > > > I disagree that an O(N) cost on error should cause us to eliminate > behavior that is both useful and expected by clients (at least, by > clients used to file-system implementations of redirect references, > such as sym-links on Unix). > > First, the "N" here is very small (5, 10, not 1000). Second, it is > likely that servers will have to do this anyway when ACL's are > introduced (you will have to check if you have a READ ACL to each > collection in the path). And finally, the cost of doing this lookup > is likely to have been so optimized by the underlying system > that the total cost will be minimal in any case. > > Cheers, > Geoff > > > -----Original Message----- > > From: Yaron Goland [mailto:yarong@Exchange.Microsoft.com] > > Sent: Thursday, February 24, 2000 1:53 AM > > To: 'Slein, Judith A'; w3c-dist-auth@w3.org; 'yaron@goland.org' > > Subject: RE: Yaron.Redirect.S10 > > > > > > The main contention in Judy's comments is that implementing > > the section 10 > > rules isn't that bad because you can always do a hash look up > > first on a > > name and if you don't get a hit then you can begin the > > segment by segment > > walk. I disagree with the assessment that the cost is > > trivial. Every single > > time a URL mis-hits the server will be forced to spend time > > walking all of > > its segments in order to figure out if the URL may point to > a redirect > > resource. The cost of processing a bogus URL has gone from > > O(1) to O(N). > > That makes it very easy to use bogus URLs as a denial of > > service attack. > > > > This all begs the issue, BTW, of the fact that the design means that > > processing URLs correctly pointing to redirect resources will > > cost O(N). > > > > All this having been said, as I indicate below, I understand > > why the authors > > want to make redirect resources behave as they have > specified and I am > > sympathetic to their goals. I think the best compromise is > > for us to create > > two types of redirect resources (created by two different > > methods). One type > > is a simple HTTP redirect resource. No fancy namespace rules. > > No section 10 > > behavior. All it does is blindly return a 302 to a certain > > value, that is > > it. It doesn't matter if it is in a WebDAV namespace or not. > > It just returns > > a 302. Then we create a complex HTTP redirect resource with > section 10 > > behavior. People who want to take on the O(N) costs > > associated with it are > > free to do so. But let's not penalize WebDAV implementers who > > just want a > > simple 302 by forcing a O(N) solution on them. > > > > As for my comment regarding paragraph 3 of section 10, I > > agree with Judy's > > comment that my analysis is flawed and so remove my comment. > > > > Yaron > > > > > > > -----Original Message----- > > > From: Slein, Judith A [mailto:JSlein@crt.xerox.com] > > > Sent: Mon, February 21, 2000 12:25 PM > > > To: Yaron Goland; w3c-dist-auth@w3.org > > > Subject: RE: Yaron.Redirect.S10 > > > > > > > > > Comments interspersed in <js></js> tags. > > > > > > -----Original Message----- > > > From: Yaron Goland [mailto:yarong@Exchange.Microsoft.com] > > > Sent: Friday, February 11, 2000 2:54 AM > > > To: 'w3c-dist-auth@w3.org' > > > Subject: Yaron.Redirect.S10 > > > > > > > > > > > > Section 10 of the redirect spec requires that given a HTTP URL > > > http://foo/bar/blah <http://foo/bar/blah> as the request-URI > > > of a method if > > > http://foo/ <http://foo/> or http://foo/bar/ > <http://foo/bar/> are > > > redirect resources then the request must be redirected to the > > > locations > > > specified by those redirect resources with the remaining > part of the > > > request-URI appended to the redirection location. This means > > > that when a > > > HTTP URL is submitted the server must examine each segment of > > > the URL and > > > determine if any of those segments point to a redirect > > > resource. This means > > > that every time a URL is submitted a minimum of N lookups > > > must occur where N > > > equals the number of segments of the URL. This has a > > > devastating effect on > > > efficiency. > > > > > > <js> I don't think it's quite that bad. The server would > > > probably first > > > check whether it has a mapping for the whole URI. Only if it > > > doesn't would > > > the server have to start checking subpaths. So it's more > > > complicated code, > > > but not a dramatic effect on efficiency. </js> > > > > > > In the current HTTP system one can implement a HTTP URL to > > > resource mapping > > > mechanism in two steps. > > > > > > Step 1 - Look up the name and get back the internal pointer > > > to the resource. > > > > > > Step 2 - Use internal point to submit method to resource. > > > > > > Section 10 changes this, for all HTTP URL namespaces that > > > have redirect > > > support, to be: > > > > > > For (segment 1 to segment N) { > > > If (typeof(segment) == redirect) { > > > Issue 300 > > > } > > > } > > > Segment(Method) > > > > > > The section 10 requirement would be the first time we ever > > > required that the > > > processing of a URL to resource mapping was dependent on the > > > state of any > > > resource other than the target. This seems like a really bad > > > precedent to > > > set as it significantly increases the complexity and cost of > > > handling HTTP. > > > > > > In addition this requirement makes it very difficult and extremely > > > inefficient to distribute one's namespace. If one wants to > > > put http://foo/ > > > <http://foo/> on one server, http://foo/bar <http://foo/bar> > > > on another > > > server and http://foo/bar/blah <http://foo/bar/blah> on a > > > third server then > > > any requests to http://foo/bar/blah <http://foo/bar/blah> > > > MUST be sent to > > > the two others servers in order to figure out if any of them > > > is a redirect > > > resources. This is an enormous burden to put on implementers > > > wishing to > > > distribute their namespace. (Note that in a WebDAV consistent > > > namespace > > > there would be a similar requirement but it would only > apply to the > > > immediate parent and so at most one other system, not N other > > > systems as the > > > redirect draft requires.) > > > > > > <js> Again, you would first attempt to resolve the URL in the > > > usual way, and > > > only if that fails would you have to start checking sub-paths > > > instead of > > > rejecting the request out of hand. </js> > > > > > > This all having been said, the motive behind introducing the > > > section 10 > > > behavior is clear and reasonable. The desire is to enable > > > redirect resources > > > to create the same experience for the end user as a bind > > > resource. However > > > here we run into an issue that is peculiar to HTTP. > HTTP's resource > > > namespace is not consistent. Even the WebDAV namespace, if > > non-WebDAV > > > resources are included, is not required to be consistent. > Namespace > > > consistency brings with it too high a cost in terms of > > > coordination and > > > complexity to be mandatory. > > > > > > Therefore, at minimum, we require a type of redirect resource > > > that does not > > > have the section 10 behavior. This resource would expose the > > > behavior we see > > > today in various HTTP servers that allow their users to create 300 > > > resources. Therefore I move that a type of redirect resource > > > be specified in > > > the redirect spec that does not have section 10 behavior. > > > > > > That having been said I am sympathetic to the desire to have > > > the section 10 > > > rules. They certainly replicate the behavior seen today in > > > many systems. As > > > such I will not object to the inclusion of a redirect > > > resource with section > > > 10 behavior in the redirect spec. However I do move that the > > > authors must > > > address the issue of what happens when the redirection > > > location isn't a HTTP > > > URL. How do we handle a request for http://foo/bar/blah > > > <http://foo/bar/blah> when http://foo/bar <http://foo/bar> > > > is a redirect > > > resource to ftp://itsy/bitsy <ftp://itsy/bitsy> ? > > > > > > <js> We haven't really discussed this type of case, and you > > > are right that > > > we have to address it somehow. In the particular example you > > > give, we could > > > just have the server follow the rules in section 10, and > > > respond with a 302 > > > and Location: ftp://itsy/bitsy/blah <ftp://itsy/bitsy/blah> . > > > The client > > > would then have to figure out whether there is anything in > > > ftp corresponding > > > to the method in its original request. </js> > > > > > > Paragraph 3 of section 10 reads: > > > > > > Note: If the DAV:reftarget property ends with a "/" and the > > > remainder of > > > the Request-URI is non-empty (and therefore must begin with a > > > "/"), the > > > final "/" in the DAV:reftarget property is dropped before the > > > remainder > > > of the Request-URI is appended. > > > > > > This behavior is in contradiction to both RFC 2518 and RFC > > > 2616. Resources > > > that end with a "/" are currently considered different > > > resources from those > > > that do not end with a "/". This is exactly the same issue > > > brought up in > > > Yaron.NoSlash ( > > > > > > http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/0069.html > > > <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/ > > 0069.html> ) > > and I would love to see option 2 as listed there adopted. > > Failing that the > > authors must adopt option 1 and change the draft. Either way, > > I move that > > the authors must address this issue based on the requirements > > placed in > > Yaron.NoSlash. > > > > <js> I don't think this does raise the same issue. All we > > are doing here is > > making sure that you don't end up with a URL that has 2 > > consecutive slashes > > in the middle somewhere. </js> > > > From w3c-dist-auth-request@w3.org Fri Feb 25 02:57:25 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03310 for <webdav-archive@odin.ietf.org>; Fri, 25 Feb 2000 02:57:25 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id CAA19416; Fri, 25 Feb 2000 02:53:11 -0500 (EST) Resent-Date: Fri, 25 Feb 2000 02:53:11 -0500 (EST) Resent-Message-Id: <200002250753.CAA19416@www19.w3.org> Message-Id: <4.1.20000224224738.00af4e80(null)> X-Sender: contact@pop.lanminds.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Thu, 24 Feb 2000 22:59:58 -0800 To: w3c-dist-auth@w3.org From: Jim Davis <jrd3@alum.mit.edu> In-Reply-To: <200002242117.aa08003@gremlin-relay.ics.uci.edu> References: <Your message of "Thu, 24 Feb 2000 17:38:20 EST." <65B141FB11CCD211825700A0C9D609BC01D4D71E@chef.lex.rational.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: Re: Qualities of URLs and resources Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/4161 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list At 09:17 PM 2/24/00 -0800, Roy T. Fielding wrote: > If [a] concept is referenceable, it is a resource. If you ask >me for the URL that I was using to represent my home page in 1994, >you are referring to a URI as a resource in itself. All properties >are resources -- DAV just defines a different way of accessing them >than the old HTTP interface. Hmm, do you mean referenceable by humans in daily discourse, or referenceable via the HTTP protocol? Humans are able to talk about many things, including "the current President of the United States", "the first human to walk on Mars", and "unicorns", but none of these "references" are references that HTTP could use. I don't think any of them count as URLs, and thus none of those referenda are resources, in the technical sense of HTTP. I apologize for my poor understanding of your ideas, since I have so often benefited from them in the past From w3c-dist-auth-request@w3.org Fri Feb 25 09:38:37 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09136 for <webdav-archive@odin.ietf.org>; Fri, 25 Feb 2000 09:38:36 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id JAA06560; Fri, 25 Feb 2000 09:29:31 -0500 (EST) Resent-Date: Fri, 25 Feb 2000 09:29:31 -0500 (EST) Resent-Message-Id: <200002251429.JAA06560@www19.w3.org> Message-ID: <65B141FB11CCD211825700A0C9D609BC0205B0B4@chef.lex.rational.com> From: "Clemm, Geoff" <gclemm@Rational.Com> To: w3c-dist-auth@w3.org Date: Fri, 25 Feb 2000 09:16:51 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Qualities of URLs and resources Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/4163 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Every concept is referenceable, so your definition would make the term "resource" a synonym for the term "concept". This makes the term "resource" useless, since the term "concept" is well defined, and adding a synonym for it does not buy us anything. An alternative definition is that a resource is a function that can be associated with a URI, where the input to this function is a method name, a request URI, a list of headers, and a request body, and the output is a list of headers and a response body. (I pretty much copied this definition from one of your earlier posts, so I make no claim of originality here). In this alternative definition, all sorts of concepts are not resources ... in particular, a method name is not a resource, a header is not a resource, a request or response body is not a resource, and a URI is not a resource. I believe this alternative definition is far more useful for defining a binding protocol. I'm willing to use some other term for this alternative concept, if it is important to reserve "resource" as a synonym for "concept", but my impression is that this alternative definition is the more commonly accepted one. Cheers, Geoff > -----Original Message----- > From: Roy T. Fielding [mailto:fielding@kiwi.ICS.UCI.EDU] > Sent: Friday, February 25, 2000 12:17 AM > To: Clemm, Geoff > Cc: Slein, Judith A; w3c-dist-auth@w3.org > Subject: Re: Qualities of URLs and resources > > > >There are some concepts that explicitly are not resources, > >e.g. the concept of a "URI" or the concept of a "property". > > Nope. If the concept is referenceable, it is a resource. If you ask > me for the URL that I was using to represent my home page in 1994, > you are referring to a URI as a resource in itself. All properties > are resources -- DAV just defines a different way of accessing them > than the old HTTP interface. The only reason it did so is because > some people felt that adding direct access to properties was better > than paying for one round trip. > > >Like URI's and properties, a binding is not > >something that is identified by a URI, and is not something > >to which you can apply requests. Instead, a binding > >is just a term we use to talk about how a collection > >resource behaves, e.g. if at time T, a collection resource has a > >binding named "foo" to a resource with DAV:resourceid "xxx", then > >this is just a shorthand for saying that a > >depth:1 PROPFIND at time T on any URL that is mapped to that > collection > >will return a DAV:response with a DAV:href whose value is > >"<that URL>/foo" and with a DAV:resourceid whose value is "xxx". > > > >In other words, all URI's that are mapped to that collection at time > >T will have a member named foo, and the DAV:resourceid of that member > >will be "xxx". > > For any concept X, it is possible to create an identifier namespace > obeying the requirements of RFC 2396 such that concept X is > unambiguously > identified within the scope of the namespace's usage. It is therefore > possible to identify any concept with a URI, which makes it a > resource. > > BTW, DAV:resourceid is an abomination. It breaks the implementation > abstraction that is at the core of the Web interface. Telling server > implementors to reveal that information is wrong and is completely > unnecessary to define the protocol. > > ....Roy > From w3c-dist-auth-request@w3.org Fri Feb 25 09:53:31 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09137 for <webdav-archive@odin.ietf.org>; Fri, 25 Feb 2000 09:38:36 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id JAA06539; Fri, 25 Feb 2000 09:29:25 -0500 (EST) Resent-Date: Fri, 25 Feb 2000 09:29:25 -0500 (EST) Resent-Message-Id: <200002251429.JAA06539@www19.w3.org> Message-ID: <65B141FB11CCD211825700A0C9D609BC0205B0B2@chef.lex.rational.com> From: "Clemm, Geoff" <gclemm@Rational.Com> To: w3c-dist-auth@w3.org Date: Fri, 25 Feb 2000 09:16:44 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Yaron.Redirect.ClientUpdate Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/4162 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list OK, I'll admit that was weak. I will defer to your implementation experience here, and like Eric, I will start saying "use a METHOD" in a monotone voice until some stronger argument occurs to me or someone else (:-). In particular, I will make a pass through the versioning protocol and see what impact this would have. Cheers, Geoff > -----Original Message----- > From: Yaron Goland [mailto:yarong@Exchange.Microsoft.com] > Sent: Friday, February 25, 2000 1:35 AM > To: 'Clemm, Geoff'; w3c-dist-auth@w3.org > Subject: RE: Yaron.Redirect.ClientUpdate > > > Geoff, I hope you aren't seriously expecting me to engage in > a debate with > you whose foundation is the need to preserve pretty method > names. It really > doesn't matter if the name is SUBSCRIBE or S#*&!@. Other than > the later will > probably cause more typo-s. > > If using multiple names will help interoperability and my > experience leads > me to believe that this is so, then we should use multiple > names. To hell > with conserving pretty names. > > > -----Original Message----- > > From: Clemm, Geoff [mailto:gclemm@Rational.Com] > > Sent: Thu, February 24, 2000 8:32 PM > > To: w3c-dist-auth@w3.org > > Subject: RE: Yaron.Redirect.ClientUpdate > > > > > > I don't think that the "method for each variant of each operation" > > scales. I can think of 4 or 5 groups that would like to pick > > SUBSCRIBE > > to mean something slightly different. One of the advantages of live > > properties is that they have a built-in namespace > mechanism. I agree > > that this will mean that servers will need two extra dispatch points > > (i.e. in PROPFIND and PROPPATCH), but I believe that is a > small price > > to pay in order to avoid name collisions as more extensions > to WebDAV > > are developed. > > > > Note: there currently are few enough WebDAV extensions, that > > I could get > > the names I want for bindings, redirect references, and even > > versioning, > > but I can already the cursing of subsequent protocol developers > > as they discover that all the meaningful method names in > their domain > > have been used by the first wave of protocol developers. > > > > Cheers, > > Geoff > > > > > -----Original Message----- > > > From: Yaron Goland [mailto:yarong@Exchange.Microsoft.com] > > > Sent: Thursday, February 24, 2000 1:55 AM > > > To: 'Slein, Judith A'; w3c-dist-auth@w3.org; 'yarong@goland.org' > > > Subject: RE: Yaron.Redirect.ClientUpdate > > > > > > > > > We can either let them use MKREF to update it or we can > introduce a > > > UPDATEREFTARGET method. Lately I have been leaning to > > introducing new > > > methods in order to simplify the standard text. Re-using > > > existing methods > > > for related functionality has proven to make specs harder > > to read. For > > > example, in my GENA spec I specified that SUBSCRIBE can be > > > used with a NT > > > header to create a subscription and with a Subscription-ID > > > header but no NT > > > header to renew a subscription. The result is that I had to > > > put in some > > > fairly confusing language to explain what to do if a request > > > has both a NT > > > and a Subscription-ID header. After that experience I just > > introduce a > > > RESUBSCRIBE method to simplify things. Of course, this > > isn't a perfect > > > solution since the more methods you have the more things > > > people have to put > > > on their slides when they explain WebDAV. =) > > > > > > > -----Original Message----- > > > > From: Slein, Judith A [mailto:JSlein@crt.xerox.com] > > > > Sent: Mon, February 21, 2000 12:52 PM > > > > To: Yaron Goland; w3c-dist-auth@w3.org > > > > Subject: RE: Yaron.Redirect.ClientUpdate > > > > > > > > > > > > As long as we have the DAV:reftarget property, the obvious > > > > thing to do is > > > > allow clients to update its value. If you want to get rid of > > > > that property, > > > > as it seems you do from NoWebDAV#3, then I suppose we would > > > > need something > > > > like an UPDATEREFTARGET method. > > > > > > > > --Judy > > > > > > > > -----Original Message----- > > > > From: Yaron Goland [mailto:yarong@Exchange.Microsoft.com] > > > > Sent: Friday, February 11, 2000 2:57 AM > > > > To: 'w3c-dist-auth@w3.org' > > > > Subject: Yaron.Redirect.ClientUpdate > > > > > > > > > > > > > > > > Maybe I just missed it but there doesn't seem to be any way > > > > to update the > > > > target of a redirection resource without deleting it. I > > move that a > > > > mechanism be provided that enables the target of a > > > > redirection resource to > > > > be updated without having to delete the resource. > > > > > > > > > > From w3c-dist-auth-request@w3.org Fri Feb 25 10:15:39 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10675 for <webdav-archive@odin.ietf.org>; Fri, 25 Feb 2000 10:15:38 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id KAA08243; Fri, 25 Feb 2000 10:11:19 -0500 (EST) Resent-Date: Fri, 25 Feb 2000 10:11:19 -0500 (EST) Resent-Message-Id: <200002251511.KAA08243@www19.w3.org> Message-ID: <65B141FB11CCD211825700A0C9D609BC0205B10D@chef.lex.rational.com> From: "Clemm, Geoff" <gclemm@Rational.Com> To: w3c-dist-auth@w3.org Date: Fri, 25 Feb 2000 09:58:50 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Yaron.Redirect.S10 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/4164 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list > -----Original Message----- > From: Yaron Goland [mailto:yarong@Exchange.Microsoft.com] > Sent: Friday, February 25, 2000 1:45 AM > To: 'Clemm, Geoff'; w3c-dist-auth@w3.org > Subject: RE: Yaron.Redirect.S10 > > > Point #1 - I agree that we need a redirect resource with the full path > behavior. However, we also need a type of redirect resource > that does NOT > have the path behavior. In other words, I am asking that we > have two types > of redirect resource. Fair enough. BTW, did you have an idea what to call these two kinds of redirect references? > Point #2 - > In Windows when you set an ACL on a collection inheritance is > done at the > time the ACL is set. In this case, I don't see that the BIND operation will ever be implemented by the Windows file system, since it would be incorrect to make a resource unreadable by a principal just because *one* of the collections that contains it is unreadable by that principal. One reason that Unix does do the ACL search through each directory is that it does support the BIND operation to files (although not to directories). Note: The fact that BIND is unlikely to be implemented on the Windows file system does not lead me to believe that we should not standardize a BIND operation in the protocol, although it does mean that we should keep it optional (:-). Cheers, Geoff From w3c-dist-auth-request@w3.org Fri Feb 25 10:15:45 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10686 for <webdav-archive@odin.ietf.org>; Fri, 25 Feb 2000 10:15:44 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id KAA08271; Fri, 25 Feb 2000 10:11:30 -0500 (EST) Resent-Date: Fri, 25 Feb 2000 10:11:30 -0500 (EST) Resent-Message-Id: <200002251511.KAA08271@www19.w3.org> Message-ID: <65B141FB11CCD211825700A0C9D609BC0205B10E@chef.lex.rational.com> From: "Clemm, Geoff" <gclemm@Rational.Com> To: w3c-dist-auth@w3.org Date: Fri, 25 Feb 2000 09:58:51 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: An analysis of the proposal to place locks on URIs rather tha n re sources Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/4165 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list > -----Original Message----- > From: Yaron Goland [mailto:yarong@Exchange.Microsoft.com] > > The only reason I don't like moving locks on resources is > that many existing > systems CAN NOT do it. So if you define it then the Windows world will > ignore WebDAV and implement what it's system can actually support. Is this really "cannot" or just "currently do not". I understand that the underlying file system lock has whatever semantics it has, and is unlikely to change, but could not the HTTP MOVE method be defined to re-establish the lock following the move? > In the purely theoretical sense I have no problem with locks > moving with a > resource, so long as the lock owner is the one who did the move. Yes, I agree that the lock token must be included in the request in order for the MOVE to succeed. The question of whether only the "lock owner" can use the lock token is a separate one that is the topic of a different thread. > BTW, I bet you still end up with a NULL resource or the moral > equivalent. I'll take that bet ... loser buys dinner at the next IETF meeting (:-). Cheers, Geoff > > > -----Original Message----- > > From: Clemm, Geoff [mailto:gclemm@Rational.Com] > > Sent: Thu, February 24, 2000 8:32 PM > > To: w3c-dist-auth@w3.org > > Subject: RE: An analysis of the proposal to place locks on > URIs rather > > tha n re sources > > > > > > > > I'll answer Edgar's question immediately, since it is nice > > and short ... > > I will respond to Yaron's post later since it is nice and long (:-). > > But my answer to Edgar and my response to Yaron have the same basis, > > namely that when I said "a lock is on a URL", I was really > > saying a lock > > "acts" like it is on a URL. The fact that a lock is *really* on a > > resource is detailed in the GULP (Grand Unified Locking Proposal). > > In particular, it is really on the first WebDAV collection > encountered > > on the path. It is then just inherited by resources below. > > > > But before this goes too much farther, I should state that GULP was > > a somewhat academic exercise to develop a complete model that would > > provide consistent answers to all the depth locking, null resource > > locking, and URL protection issues that have arisen on the mailing > > list. > > > > My conclusion is that we just have to simplify. In > > particular, I believe > > we have to keep URL protection, but that depth locking and > > null resources > > must go in order to have a locking model that will be be > implementable > > and understandable in conjunction with protocol extensions > > such as bindings > > and versioning. > > > > And in a Simple LOcking Proposal (SLOP :-), locks will be > > back to being > > on resources, which Yaron will like, until he hears that this > > means that > > a lock should move with a resource when that resource is > MOVE'd, which > > he will vigorously protest against (if he has time to do so :-). > > > > Cheers, > > Geoff > > > > > > > -----Original Message----- > > > From: Edgar Schwarz [mailto:Edgar.Schwarz@marconicomms.com] > > > Sent: Thursday, February 24, 2000 5:13 AM > > > To: w3c-dist-auth@w3.org > > > Subject: Re: An analysis of the proposal to place locks on > > URIs rather > > > than re sources > > > > > > > > > Yaron Goland wrote: > > > > > > Sorry, no time for a comment to Yaron's stuff at the moment :-) > > > > > > > > From: Geoffrey M. Clemm [mailto:geoffrey.clemm@rational.com] > > > > > Sent: Thu, December 30, 1999 2:33 PM > > > > > > > > As an addendum to Yaron's response, I'll note that there > > > is a proposal > > > > > that WebDAV locking is better understood as locks on > > > URL's rather than > > > > > on resources. > > > I'm not sure I understand. Does that mean that you can't lock > > > a resource > > > anymore with WebDAV ? > > > I wouldn't like this idea. Or do you propose another mechanism for > > > locking a resource ? > > > > > > Cheers, Edgar > > > > > > P.S. Sorry if this topic was already solved in the meantime > > > but I didn't > > > have time to follow the discussions for a while. > > > > > > -- > > > Edgar.Schwarz@marconicomms.com, Marconi Communications, > > > 07191/13-3382 > > > Privat kann jeder soviel C programmieren oder Videos ansehen > > > wie er mag. > > > Albert Einstein: Mach es so einfach wie moeglich, aber nicht > > > einfacher. > > > > > > From w3c-dist-auth-request@w3.org Fri Feb 25 17:46:12 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22765 for <webdav-archive@odin.ietf.org>; Fri, 25 Feb 2000 17:46:11 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA25465; Fri, 25 Feb 2000 17:41:26 -0500 (EST) Resent-Date: Fri, 25 Feb 2000 17:41:26 -0500 (EST) Resent-Message-Id: <200002252241.RAA25465@www19.w3.org> Message-ID: <65B141FB11CCD211825700A0C9D609BC01D4D72A@chef.lex.rational.com> From: "Clemm, Geoff" <gclemm@Rational.Com> To: "'w3c-dist-auth@w3.org'" <w3c-dist-auth@w3.org> Date: Fri, 25 Feb 2000 17:14:33 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: WebDAV Bindings - Issue Yaron.5.3Huh? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/4166 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list How about the following: Suppose: - C is a collection - R is a resource - C-MAP is the set of URI's mapped to C - a BIND request causes a binding from "Binding-Name" to resource R to be added to collection C Then immediately following the BIND request, for each "C-URI" in C-MAP, the URI "C-URI/Binding-Name" is mapped to resource R. Then using a facsimile of Yaron's example, if I have a collection whose C-Map is the set {<http://icky/bop>, <http://zizbang/rocky>} (i.e. those two URL's map to this collection), and I perform a BIND that successfully adds to this collection a binding from "blah" to resource R, then following this BIND, the URL <http://icky/bop/blah> maps to R and the URL <http://zizbang/rocky> also maps to R. Cheers, Geoff -----Original Message----- From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Yaron Goland Sent: Sunday, January 16, 2000 8:52 PM To: w3c-dist-auth@w3.org Subject: WebDAV Bindings - Issue Yaron.5.3Huh? The first paragraph of section 5.3 reads "Suppose a BIND request causes a binding from "Binding-Name" to resource R to be added to a collection, C. Then if C-MAP is the set of URI's that were mapped to C before the BIND request, then for each URI "C-URI" in C-MAP, the URI "C-URI/Binding-Name" is mapped to resource R following the BIND request." I have a B.S. in CS & EE and got A's in my classes on set theory and I still can't read this paragraph. I tried over and over again and I just couldn't figure it out. If you are going to try to write set theory in English you should at least translate it faithfully using the appropriate terms such as "for all" and "there is an instance of". Personally I would recommend just using an ASCII version of set code notation. Whatever you do, the current paragraph MUST go. It is unfathomable. In fact here is the best translation I have been able to come up with: Imagine I have a collection http://icky/bop which contains http://icky/bop/blah. Imagine I now want to map http://zizbang/rocky to http://icky/bop/rack. According to this language it would seem I would have to create a bind to http://icky/bop/blah/rack. I know this makes no sense but I swear that is what the sentence seemed to mean when I tried to read it four or five times. As such I move that the paragraph be rewritten. From w3c-dist-auth-request@w3.org Fri Feb 25 17:48:46 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22783 for <webdav-archive@odin.ietf.org>; Fri, 25 Feb 2000 17:48:46 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA25546; Fri, 25 Feb 2000 17:44:39 -0500 (EST) Resent-Date: Fri, 25 Feb 2000 17:44:39 -0500 (EST) Resent-Message-Id: <200002252244.RAA25546@www19.w3.org> Message-ID: <65B141FB11CCD211825700A0C9D609BC01D4D729@chef.lex.rational.com> From: "Clemm, Geoff" <gclemm@Rational.Com> To: "'w3c-dist-auth@w3.org'" <w3c-dist-auth@w3.org> Date: Fri, 25 Feb 2000 16:55:41 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: Please check this on your WebDAV server! (was: WebDAV Bindings - Issue Yaron.NoSlash) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/4167 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list In section 5.2 of RFC 2518, it is stated that: if a client invokes a method on http://foo.bar/blah (no trailing slash), the resource http://foo.bar/blah/ (trailing slash) may respond as if the operation were invoked on it The authors of the Bindings proposal are proposing to strengthen this statement to say that a server MUST ignore the trailing slash, i.e. the URL http://xxx and the URL http://xxx/ MUST identify the same resource. This note is intended to verify that this will not cause an unacceptable interoperation problem for current WebDAV implementations (or more simply, is this change OK). I personally have confirmed that the Microsoft IIS WebDAV server, the Apache mod_dav WebDAV server, and the Sharemation WebDAV server all ignore the trailing slash. I would appreciate if the authors or users of any other WebDAV server could let me know whether: - their server already acts this way - whether it would be acceptable to them to change their server to act this way - whether they would object to this change. Thankyou! Geoff -----Original Message----- From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Yaron Goland ... Option 2 - Keep the current language but add a note specifically stating that you are violating RFC 2518 and, on the mailing list, provide a listing of existing WebDAV client/server implementations and see if any of them actually differentiate resources based on the trailing slash. If the answer (as I suspect) is that no one differentiates based on the trailing "/" then I think we have the basis for declaring consensus on the change. However, if the authors fail to perform this analysis then I believe the chair MUST strike down the BIND draft by declaring that in the absence of such an analysis it is impossible to declare a consensus on the issue of upgrading the SHOULD to a MUST. We can't use silence as a sign of assent on such a serious change. I move that we force the authors with threats of jeering and paying for every IETF dinner from here to eternity to adopt Option 2 and free us from the nonsense of the trailing slash. Yaron P.S. The requirement that http://foo/blah/ and http://foo/blah point to the same resource would ONLY apply to WebDAV compliant resources. So we are not changing 2616. We are only saying "If you voluntarily choose to support WebDAV THEN you must follow this rule." That way the only spec that needs to change is 2518, NOT 2616. That having been said, I would LOVE to get 2616 changed to say this as well but I don't have enough free time on my hands to push for this change to 2616. From w3c-dist-auth-request@w3.org Fri Feb 25 18:10:05 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22994 for <webdav-archive@odin.ietf.org>; Fri, 25 Feb 2000 18:10:05 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAA26655; Fri, 25 Feb 2000 18:05:57 -0500 (EST) Resent-Date: Fri, 25 Feb 2000 18:05:57 -0500 (EST) Resent-Message-Id: <200002252305.SAA26655@www19.w3.org> Message-ID: <C3AF5E329E21D2119C4C00805F6FF58F0389D2BD@hq-expo2.filenet.com> From: "Fay, Chuck" <CFay@filenet.com> To: "Clemm, Geoff" <gclemm@Rational.Com>, "'w3c-dist-auth@w3.org'" <w3c-dist-auth@w3.org> Date: Fri, 25 Feb 2000 15:04:00 -0800 X-Mailer: Internet Mail Service (5.5.2650.10) Subject: RE: WebDAV Bindings - Issue Yaron.5.3Huh? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/4168 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Geoff, Shouldn't that be <http://zizbang/rocky/blah> in the last sentence? --Chuck Fay FileNET Corporation, 3565 Harbor Blvd., Costa Mesa, CA 92626 phone: (714) 327-3513, fax: (714) 327-5076, email: cfay@filenet.com > -----Original Message----- > From: Clemm, Geoff [mailto:gclemm@Rational.Com] > Sent: Friday, February 25, 2000 2:15 PM > To: 'w3c-dist-auth@w3.org' > Subject: RE: WebDAV Bindings - Issue Yaron.5.3Huh? > > > How about the following: > > Suppose: > - C is a collection > - R is a resource > - C-MAP is the set of URI's mapped to C > - a BIND request causes a binding from "Binding-Name" to > resource R to be > added to collection C > Then immediately following the BIND request, for each "C-URI" > in C-MAP, > the URI "C-URI/Binding-Name" is mapped to resource R. > > Then using a facsimile of Yaron's example, if I have a > collection whose > C-Map is the set {<http://icky/bop>, <http://zizbang/rocky>} > (i.e. those > two URL's map to this collection), and I perform a BIND that > successfully > adds to this collection a binding from "blah" to resource R, then > following this BIND, the URL <http://icky/bop/blah> maps to R and > the URL <http://zizbang/rocky> also maps to R. > > Cheers, > Geoff > > > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On > Behalf Of Yaron Goland > Sent: Sunday, January 16, 2000 8:52 PM > To: w3c-dist-auth@w3.org > Subject: WebDAV Bindings - Issue Yaron.5.3Huh? > > > The first paragraph of section 5.3 reads "Suppose a BIND > request causes a > binding from "Binding-Name" to resource R to be added to a > collection, C. > Then if C-MAP is the set of URI's that were mapped to C > before the BIND > request, then for each URI "C-URI" in C-MAP, the URI > "C-URI/Binding-Name" is > mapped to resource R following the BIND request." > I have a B.S. in CS & EE and got A's in my classes on > set theory and > I still can't read this paragraph. I tried over and over > again and I just > couldn't figure it out. If you are going to try to write set theory in > English you should at least translate it faithfully using the > appropriate > terms such as "for all" and "there is an instance of". > Personally I would > recommend just using an ASCII version of set code notation. > Whatever you do, > the current paragraph MUST go. It is unfathomable. In fact > here is the best > translation I have been able to come up with: Imagine I have > a collection > http://icky/bop which contains http://icky/bop/blah. Imagine > I now want to > map http://zizbang/rocky to http://icky/bop/rack. According > to this language > it would seem I would have to create a bind to http://icky/bop/blah/rack. I know this makes no sense but I swear that is what the sentence seemed to mean when I tried to read it four or five times. As such I move that the paragraph be rewritten. From w3c-dist-auth-request@w3.org Fri Feb 25 18:12:49 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23030 for <webdav-archive@odin.ietf.org>; Fri, 25 Feb 2000 18:12:49 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAA26801; Fri, 25 Feb 2000 18:08:41 -0500 (EST) Resent-Date: Fri, 25 Feb 2000 18:08:41 -0500 (EST) Resent-Message-Id: <200002252308.SAA26801@www19.w3.org> Message-ID: <65B141FB11CCD211825700A0C9D609BC01D4D72F@chef.lex.rational.com> From: "Clemm, Geoff" <gclemm@Rational.Com> To: "'w3c-dist-auth@w3.org'" <w3c-dist-auth@w3.org> Date: Fri, 25 Feb 2000 17:56:16 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: WebDAV Bindings - Issue Yaron.5.3Huh? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/4169 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Oops! Chuck is of course correct. Sorry about that! Cheers, Geoff -----Original Message----- From: Fay, Chuck [mailto:CFay@filenet.com] Sent: Friday, February 25, 2000 6:04 PM To: Clemm, Geoff; 'w3c-dist-auth@w3.org' Subject: RE: WebDAV Bindings - Issue Yaron.5.3Huh? Geoff, Shouldn't that be <http://zizbang/rocky/blah> in the last sentence? --Chuck Fay FileNET Corporation, 3565 Harbor Blvd., Costa Mesa, CA 92626 phone: (714) 327-3513, fax: (714) 327-5076, email: cfay@filenet.com > -----Original Message----- > From: Clemm, Geoff [mailto:gclemm@Rational.Com] > Sent: Friday, February 25, 2000 2:15 PM > To: 'w3c-dist-auth@w3.org' > Subject: RE: WebDAV Bindings - Issue Yaron.5.3Huh? > > > How about the following: > > Suppose: > - C is a collection > - R is a resource > - C-MAP is the set of URI's mapped to C > - a BIND request causes a binding from "Binding-Name" to > resource R to be > added to collection C > Then immediately following the BIND request, for each "C-URI" > in C-MAP, > the URI "C-URI/Binding-Name" is mapped to resource R. > > Then using a facsimile of Yaron's example, if I have a > collection whose > C-Map is the set {<http://icky/bop>, <http://zizbang/rocky>} > (i.e. those > two URL's map to this collection), and I perform a BIND that > successfully > adds to this collection a binding from "blah" to resource R, then > following this BIND, the URL <http://icky/bop/blah> maps to R and > the URL <http://zizbang/rocky> also maps to R. > > Cheers, > Geoff > > > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On > Behalf Of Yaron Goland > Sent: Sunday, January 16, 2000 8:52 PM > To: w3c-dist-auth@w3.org > Subject: WebDAV Bindings - Issue Yaron.5.3Huh? > > > The first paragraph of section 5.3 reads "Suppose a BIND > request causes a > binding from "Binding-Name" to resource R to be added to a > collection, C. > Then if C-MAP is the set of URI's that were mapped to C > before the BIND > request, then for each URI "C-URI" in C-MAP, the URI > "C-URI/Binding-Name" is > mapped to resource R following the BIND request." > I have a B.S. in CS & EE and got A's in my classes on > set theory and > I still can't read this paragraph. I tried over and over > again and I just > couldn't figure it out. If you are going to try to write set theory in > English you should at least translate it faithfully using the > appropriate > terms such as "for all" and "there is an instance of". > Personally I would > recommend just using an ASCII version of set code notation. > Whatever you do, > the current paragraph MUST go. It is unfathomable. In fact > here is the best > translation I have been able to come up with: Imagine I have > a collection > http://icky/bop which contains http://icky/bop/blah. Imagine > I now want to > map http://zizbang/rocky to http://icky/bop/rack. According > to this language > it would seem I would have to create a bind to http://icky/bop/blah/rack. I know this makes no sense but I swear that is what the sentence seemed to mean when I tried to read it four or five times. As such I move that the paragraph be rewritten. From w3c-dist-auth-request@w3.org Fri Feb 25 19:14:28 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23508 for <webdav-archive@odin.ietf.org>; Fri, 25 Feb 2000 19:14:27 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id TAA28247; Fri, 25 Feb 2000 19:10:10 -0500 (EST) Resent-Date: Fri, 25 Feb 2000 19:10:10 -0500 (EST) Resent-Message-Id: <200002260010.TAA28247@www19.w3.org> To: Jim Davis <jrd3@alum.mit.edu> cc: w3c-dist-auth@w3.org In-reply-to: Your message of "Thu, 24 Feb 2000 22:59:58 PST." <4.1.20000224224738.00af4e80(null)> Date: Fri, 25 Feb 2000 16:09:55 -0800 From: "Roy T. Fielding" <fielding@kiwi.ICS.UCI.EDU> Message-ID: <200002251609.aa12298@gremlin-relay.ics.uci.edu> Subject: Re: Qualities of URLs and resources Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/4170 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list >Hmm, do you mean referenceable by humans in daily discourse, or >referenceable via the HTTP protocol? I mean anything that can be represented. Mostly nouns (is a color a noun or an adjective, or both -- I can't remember, but I do know it can be represented as a resource). >Humans are able to talk about many things, including "the current President >of the United States", "the first human to walk on Mars", and "unicorns", >but none of these "references" are references that HTTP could use. I don't >think any of them count as URLs, and thus none of those referenda are >resources, in the technical sense of HTTP. What makes you think that those can't be identified as URLs and used by HTTP? Keep in mind that HTTP is a gateway protocol that is capable of infinite redirections. If I define whoswho:/people/leaders/USA/federal/President/now to mean the current President of the United States, then I can define an HTTP service that accepts requests for that namespace and responds with a representation of the current President. Remember: 1) HTTP transfers representations, not resources; 2) The resource defines the semantic mapping between requests and representations; 3) The implementation of this mapping has nothing whatsoever to do with the semantics of the resource UNLESS the specific URI in question identifies an implementation itself as a resource; 4) Many resources can only be manipulated by a subset of HTTP methods. ....Roy From w3c-dist-auth-request@w3.org Fri Feb 25 19:53:22 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23799 for <webdav-archive@odin.ietf.org>; Fri, 25 Feb 2000 19:53:22 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id TAA29561; Fri, 25 Feb 2000 19:48:55 -0500 (EST) Resent-Date: Fri, 25 Feb 2000 19:48:55 -0500 (EST) Resent-Message-Id: <200002260048.TAA29561@www19.w3.org> To: "Clemm, Geoff" <gclemm@rational.com> cc: w3c-dist-auth@w3.org In-reply-to: Your message of "Fri, 25 Feb 2000 09:16:51 EST." <65B141FB11CCD211825700A0C9D609BC0205B0B4@chef.lex.rational.com> Date: Fri, 25 Feb 2000 16:48:40 -0800 From: "Roy T. Fielding" <fielding@kiwi.ICS.UCI.EDU> Message-ID: <200002251648.aa15384@gremlin-relay.ics.uci.edu> Subject: Re: Qualities of URLs and resources Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/4171 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list >Every concept is referenceable, so your definition would >make the term "resource" a synonym for the term "concept". >This makes the term "resource" useless, since >the term "concept" is well defined, and adding a synonym >for it does not buy us anything. A resource is what you get when you give a concept an identifier and allow authors to reference it. Not all concepts are given resource identifiers. I'm not trying to sell you anything -- I am stating a fact. URIs identify resources. Resources are defined in RFC 2396. WebDAV is chartered to define an authoring interface to resources. It is not chartered to define a remote document management interface that only uses HTTP to get through firewalls. That means WebDAV needs to deal with an interface where only a subset of the identified resources are directly authorable. There are lots of ways to deal with that issue. Just about the only one that is completely unacceptable is what the bindings and references specs currently do: redefine the term "resource" to mean something else that is easier to interpret as an authoring widget. >An alternative definition is that a resource is a function >that can be associated with a URI, where the input to this >function is a method name, a request URI, a list of headers, >and a request body, and the output is a list of headers and >a response body. (I pretty much copied this definition from >one of your earlier posts, so I make no claim of originality >here). The resource is a semantic mapping. The function is how that mapping is implemented on the server at the time of the request. The function changes, the values in response to the function change, but the resource hopefully does not. (Of course, the resource does change at times, resulting in one of the forms of "broken" links described in my 1994 paper on MOMspider, but the goal here is to provide identifiers that change as little as humanly possible). >In this alternative definition, all sorts of concepts are not >resources ... in particular, a method name is not a resource, >a header is not a resource, a request or response body is not >a resource, and a URI is not a resource. On the contrary, all of those can be resources -- they are just referenced by some other URI and accessed in some other request and representable in some other responses. That is why I said that you can't explicitly say that they are not resources, even though they are not *the* resource that is the target of *that* request. >I believe this alternative definition is far more useful for >defining a binding protocol. I'm willing to use some other >term for this alternative concept, if it is important to reserve >"resource" as a synonym for "concept", but my impression is >that this alternative definition is the more commonly accepted >one. None of this is necessary for defining the protocol. The reason why the specs have so many errors in this regard is because they overspecify the protocol to the point where it limits implementations to something far less than Web resources. Just delete those parts and define it in terms of the collection namespace. ....Roy From w3c-dist-auth-request@w3.org Fri Feb 25 21:46:02 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25210 for <webdav-archive@odin.ietf.org>; Fri, 25 Feb 2000 21:46:01 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id VAA01904; Fri, 25 Feb 2000 21:41:33 -0500 (EST) Resent-Date: Fri, 25 Feb 2000 21:41:33 -0500 (EST) Resent-Message-Id: <200002260241.VAA01904@www19.w3.org> Date: Fri, 25 Feb 2000 18:43:38 -0800 (PST) From: Greg Stein <gstein@lyra.org> To: w3c-dist-auth@w3.org cc: "'Slein, Judith A'" <JSlein@crt.xerox.com>, "'yaron@goland.org'" <yaron@goland.org> In-Reply-To: <7DE119D3D0E15543874F7561EECBDBED030B53D5@BEG.platinum.corp.microsoft.com> Message-ID: <Pine.LNX.4.10.10002251840130.10607-100000@nebula.lyra.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: RE: Yaron.Redirect.NoWebDAV#1 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/4172 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list I'm not sure what the total outcome of the "NoWebDAV" posts are, but here is my opinion on the matter... * I agree with Yaron in that we should not require WebDAV to implement the redirects. * if the redirect resources *are* WebDAV aware, then I want to see the information in a property. Therefore, the reftarget can be queried/set using PROPFIND and PROPPATCH (with the Apply-To-Redirect-Ref header present) * I would expect that DAV:resourcetype is set appropriately (during a PROPFIND) This implies that the Redirect spec should be written in terms of NOT requiring anything more than HTTP/1.1 (i.e. does not require WebDAV). BUT: it should also have a section specifying the behavior if the resources are WebDAV aware. Cheers, -g On Wed, 23 Feb 2000, Yaron Goland wrote: > See below > > > -----Original Message----- > > From: Slein, Judith A [mailto:JSlein@crt.xerox.com] > > Sent: Wed, February 16, 2000 9:12 AM > > To: Yaron Goland; w3c-dist-auth@w3.org > > Subject: RE: Yaron.Redirect.NoWebDAV#1 > > > > > > The idea of trying to specify redirect references in such a > > way that they do > > not depend on implementation of any other parts of WebDAV is > > very appealing. > > As you point out in this and the following 2 comments, we > > would need to go > > back to using MKREF (which doesn't have an XML body) instead > > of the more > > generic MKRESOURCE and get rid of the DAV:reftarget property > > in order to > > make this possible. > > > > I would be willing to do both. > > > > I just want to be sure that, even though it's not required > > for a redirect > > reference to support any other parts of WebDAV, it's > > permissible for it to > > do so. If it's also a WebDAV class 1 resource, I would assume its > > DAV:resourcetype property would have a value DAV:redirectref. > > It would be > > possible to set properties on the redirect reference and view > > properties on > > the redirect reference using the Apply-To-Redirect-Ref header. > > > > Agreed. > > > Also it is possible to create a redirect reference in a > > WebDAV-compliant > > collection, as discussed in Section 7 of the spec. > > > > What would we lose by getting rid of DAV:reftarget? > > > > 1. Efficiency in certain scenarios, where you are operating > > on a collection > > populated with redirect references. You would have to do 2 > > round trips for > > each member of the collection instead of getting > > DAV:reftarget with PROPFIND > > for all members and addressing requests to the target. > > > > Maybe I'm missing something but wouldn't the results for a PROPFIND on all > the redirect resources be a 300 and wouldn't that 300 contain the redirect > target? Isn't that the same information that would have been contained in > the DAV:reftarget element? Doesn't that therefore mean that there is no loss > of efficiency? > > > 2. Can't search on DAV:reftarget to find all references to a > > given resource. > > > > Actually, there is no reason why you can't define a DAV:reftarget token for > use with DASL. As I discuss in one of my points DASL can search on anything > with a name, what is being searched does NOT have to be something > retrievable through a PROPFIND. > > > 3. No relative URIs (the Location header always has absolute > > URI), so in an > > environment where references are within a hierarchy that is > > likely to move, > > redirects may get broken where they would survive in the current spec. > > > > I admit to not understanding this one. How does the use of relative or > absolute URIs in the protocol effect how information is stored at either the > client or the server? Perhaps an example would help. > > > In my view these considerations are outweighed by the possibility of > > creating and managing redirect references without > > implementing any other > > parts of WebDAV. So I'm with you here. Thanks for the great > > suggestion! > > > > Always a pleasure. > > > --Judy > > > > Yaron > > > -----Original Message----- > > From: Yaron Goland [mailto:yarong@Exchange.Microsoft.com] > > Sent: Friday, February 11, 2000 2:44 AM > > To: 'w3c-dist-auth@w3.org' > > Subject: Yaron.Redirect.NoWebDAV#1 > > > > > > > > The redirect spec requires the use of WebDAV in order to > > create and query > > redirect resources as it makes use of the WebDAV property > > mechanism. However > > I am having trouble finding a compelling reason to require > > WebDAV just to > > implement redirect resources. A redirect resource is, in my > > opinion, just an > > enhancement to HTTP/1.1. > > > > HTTP/1.1 introduced the concept of a 302 response but did not > > concurrently > > introduce the administrative tools necessary in order to > > specify when a 302 > > response should be returned. > > > > The redirect draft helps to address this deficiency but > > unless there is a > > compelling reason to do so, it should address this deficiency in the > > simplest manner possible, preferably only using the tools provided by > > HTTP/1.1. > > > > The argument has been made that the tools introduced in the > > redirect draft > > constitute the first step in a series of additional > > extensions that will be > > made in the future. For example, the Delta-V group has > > certain ideas about > > how to use MKRESOURCE. While HTTP has a rich tradition of > > enabling future > > extensions it has always wisely chosen in the short term to > > limit itself to > > immediate needs only while ensuring that future expansion is possible. > > > > Hence the test for the redirect draft's success should be > > only how well it > > addresses the immediate needs of redirect resources and not > > how well it > > addresses the shifting needs of various future proposals. > > > > The current functionality of the redirect resource is very > > simple, specify a > > resource that, by default, will return a 302 (found) response > > to a specified > > target resource. > > > > There does not appear to be any compelling reason why the > > creation of a > > redirect resource should require anything beyond a single > > header on the > > creation request to specify the URI of the target resource. > > The use of a > > body to create a redirect resource is clearly unnecessary. > > This is not to > > say that it may not prove to be necessary in the future. > > However WebDAV, in > > particular, has set a precedent for how to deal with this > > sort of situation > > that I believe would well serve the redirect spec. > > > > In the COPY/MOVE methods we use a single destination header, > > rather than a > > body, to specify where the results of the method are to > > appear. One can > > imagine a number of reasons why one would want to have a more > > powerful way > > to specify the destination of the method. For example, one > > might want to > > specify multiple destination URIs in order to use a single > > round trip to > > cause multiple COPY/MOVE's. HTTP's header format is not well > > suited for this > > sort of extension and WebDAV's definition of the destination > > header wisely > > does not allow for it. Rather WebDAV specifies that a body > > MAY be included > > in a COPY/MOVE method but is to be ignored if not understood. > > This provide > > for a very powerful extension mechanism. For example, imagine > > one wanted to > > issue the COPY/MOVE to multiple destinations but one wasn't > > sure if the > > source supported this feature. Rather than wasting a round > > trip finding out > > if the source supports the feature one could put a single > > destination in the > > destination header and then use the body to specify the rest of the > > destinations. If the resource supports the extension then all > > destinations > > will be COPY/MOVE'd to. If the resource doesn't support the > > extension then > > at least one copy will be issued and the client will realize > > that the rest > > didn't occur (because the resource ignored the body) through the 207 > > response. If, on the other hand, one only wanted the > > COPY/MOVE to proceed if > > the resource understood the multiple destination extension then the > > COPY/MOVE could be issued without a destination header, just > > with a body. > > Resources that didn't support the extension would fail the > > request due to > > the absence of the destination header thus ensuring that only > > resources that > > understood the extension will actually execute the method. > > > > One could rightfully argue that this is an unnecessary > > complication. Why not > > start with a body that allows extension in the first place? > > The counter > > argument is that one should always start with as minimal > > functionality as > > possibly and only expand, grudgingly, as required. A header > > is much easier > > to process than a body and so clearly is the simplest > > mechanism available. > > > > This line of reasoning is especially compelling in the > > context of redirect > > resources. Given the obvious utility of redirect resources to all HTTP > > systems, not just WebDAV, it is incumbent upon the redirect > > spec to cleave > > as closely as possible to the base HTTP system and require as > > few extensions > > from it as possible. > > > > Therefore I believe that the current proposal, which requires the > > introduction of a full XML processing system just to handle a simple > > redirect resource is unsupportable. As such I move that > > whatever design is > > chosen for creating a redirect resource it MUST NOT include > > the use of a > > request body. > > > -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Sun Feb 27 10:44:30 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09079 for <webdav-archive@odin.ietf.org>; Sun, 27 Feb 2000 10:44:29 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id KAA00460; Sun, 27 Feb 2000 10:37:57 -0500 (EST) Resent-Date: Sun, 27 Feb 2000 10:37:57 -0500 (EST) Resent-Message-Id: <200002271537.KAA00460@www19.w3.org> Message-Id: <4.1.20000227011300.00af18f0(null)> X-Sender: contact@pop.lanminds.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Sun, 27 Feb 2000 01:14:24 -0800 To: "'w3c-dist-auth@w3.org'" <w3c-dist-auth@w3.org> From: Jim Davis <jrd3@alum.mit.edu> In-Reply-To: <65B141FB11CCD211825700A0C9D609BC01D4D729@chef.lex.rational .com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: Re: Please check this on your WebDAV server! (was: WebDAV Bindings - Issue Yaron.NoSlash) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/4173 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list At 04:55 PM 2/25/00 -0500, Clemm, Geoff wrote: >I would appreciate if the authors or users of any other WebDAV server >could let me know whether: >- their server already acts this way >- whether it would be acceptable to them to change their server to act this >way >- whether they would object to this change. It either would not affect the pydav server (the one I did at Xerox, not the one from germany) or I'd make the change.