From w3c-dist-auth-request@w3.org Tue Apr 3 20:59:26 2001 Received: from www19.w3.org ([18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA21293 for ; Tue, 3 Apr 2001 20:59:25 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id TAA06770; Tue, 3 Apr 2001 19:06:26 -0400 (EDT) Resent-Date: Tue, 3 Apr 2001 19:06:26 -0400 (EDT) Resent-Message-Id: <200104032306.TAA06770@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id TAA06750 for ; Tue, 3 Apr 2001 19:06:22 -0400 (EDT) Received: from cats.ucsc.edu (rumpleteazer.ucsc.edu [128.114.129.45]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id TAA26633 for ; Tue, 3 Apr 2001 19:06:20 -0400 Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177]) by cats.ucsc.edu (8.9.3/8.8.4.cats-athena) with SMTP id QAA15028; Tue, 3 Apr 2001 16:06:25 -0700 (PDT) From: "Jim Whitehead" To: "WebDAV WG" , Date: Tue, 3 Apr 2001 16:04:58 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: FW: [Moderator Action] RE: Web Folders interoperability with Authentication? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4740 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Accidentally caught by the spam filter. I've added rmago@semandex.net to the accept2 list, so future emails will go through to the list. - Jim -----Original Message----- From: Rajeev Mago [mailto:rmago@semandex.net] Sent: Friday, March 30, 2001 12:34 PM To: w3c-dist-auth@w3.org Subject: [Moderator Action] RE: Web Folders interoperability with Authentication? Can any of you guys enlighten me on how to generate the "nonce" string for the WWW-Authenticate header?? We are trying to use the WebDAV interface of Exchange2000 and getting authentication failed messages (access denied). I donot know how to correctly use the User/Passwd/Domain information to generate info for the WWW-Authenticate header. Please help! -Rajeev rmago@semandex.com From: Yaron Goland To: "'Max Rible'" Date: Tue, 6 Apr 1999 15:24:55 -0700 Subject: RE: Web Folders interoperability with Authentication? Unless I'm misreading the BNF, your WWW-Authenticate header is incorrectly formatted. There must be a "," between the Basic and Digest challenges. > -----Original Message----- > From: Max Rible Subject: RE: Web Folders interoperability with Authentication? > > > At 12:42 4/6/99 -0700, Jim Whitehead wrote: > >I have used Web folders with Basic authentication, but have > not yet used > >them with Digest authentication, and hence I cannot say > anything about Web > >folders with Digest auth. > > As far as I can tell, Web Folders will have nothing to do with Digest > authentication. In one mode, my server will send back challenges on > the order of > > WWW-Authenticate: Basic realm="quux" Digest realm="quux" > nonce="b806c84912cb622b25ffa4d6ec8dd98f" algorithm=MD5 qop="auth" > > and it promptly identifies the realm as 'quux" Digest realm="quux"' > when prompting the user. :-P If I set my server to accept > only Digest > authentication, Web Folders will send Basic anyway and be rejected. > > -- > %% Max Rible %% From w3c-dist-auth-request@w3.org Fri Apr 6 23:58:20 2001 Received: from www19.w3.org ([18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA27511 for ; Fri, 6 Apr 2001 23:58:20 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id XAA03208; Fri, 6 Apr 2001 23:50:55 -0400 (EDT) Resent-Date: Fri, 6 Apr 2001 23:50:55 -0400 (EDT) Resent-Message-Id: <200104070350.XAA03208@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id XAA03188 for ; Fri, 6 Apr 2001 23:50:50 -0400 (EDT) Received: from smtp.snet.net (smtp.snet.net [204.60.6.55]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id XAA07469 for ; Fri, 6 Apr 2001 23:50:46 -0400 Received: from gmg600x.celsus.net (244.1.252.64.snet.net [64.252.1.244]) by smtp.snet.net (8.11.1/8.11.1/SNET-mx-1.4/D-1.10/O-1.7) with ESMTP id f373ofL29295 for ; Fri, 6 Apr 2001 23:50:41 -0400 (EDT) Message-Id: <5.0.0.25.2.20010406220005.03135058@pop3.norton.antivirus> X-Sender: ggershon/pop.snet.net@pop3.norton.antivirus X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Fri, 06 Apr 2001 23:49:01 -0400 To: WebDAV Working Group From: Gary Gershon Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Flavors of DELETE Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4741 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: I didn't see anything in RFC2518 or earlier in my archives of this list regarding discussions of the semantics of the DELETE method. I'd welcome the group's thoughts on the following: A number of file systems and document management systems provide safety nets such as a "Recycle Bin" or "Trash Folder" where deleted documents are sent (moved). This may not always be desirable for technical and business reasons. Windows, for example, recognizes this and provides a keyboard shortcut (shift-delete) to indicate that a document should not be sent to the Recycle Bin. Additionally, some systems are implemented to also allow documents to be securely deleted by overwriting the file on the disk media to ensure the content of the deleted documents cannot be inadvertently or intentionally discovered from unallocated or reallocated media blocks. I would like to propose an optional header for the DELETE , PUT, MOVE, and COPY methods (the latter three can have implicit deletes) which would allow specification of these semantics for implementations in which they are supported by the underlying system. As a starter, I was envisioning a header like "Disposition" with a single parameter: 0 (or omitted) = Default server processing, 1 = Move deleted file to a recovery folder (e.g. Trash), 2 = Do NOT move deleted file to a recovery folder, and, 3 = Do NOT move deleted file to a recovery folder AND overwrite its media blocks. If the implementation provided simple automated versioning (short of DeltaV), I would suggest extending the semantics of PUT with this header in a similar way: 0 (or omitted) = Default server processing, 1 = Store as a new version, even if the default may not be to create versions for this resource, 2 = Store as a replacement version, and do NOT retain the most recent previous instance as a version, and, 3 = Store as a replacement version and do NOT retain the most recent previous instance as a version AND overwrite its media blocks. If these have merit, then there should also be options to "Do NOT retain ANY previous instances..." etc. This would be equivalent to finalizing or publishing the document and disposing of the historical artifacts. Gary From w3c-dist-auth-request@w3.org Sat Apr 7 13:05:14 2001 Received: from www19.w3.org ([18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA16245 for ; Sat, 7 Apr 2001 13:05:13 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA17934; Sat, 7 Apr 2001 12:59:17 -0400 (EDT) Resent-Date: Sat, 7 Apr 2001 12:59:17 -0400 (EDT) Resent-Message-Id: <200104071659.MAA17934@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id MAA17809 for ; Sat, 7 Apr 2001 12:59:04 -0400 (EDT) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id MAA20611 for ; Sat, 7 Apr 2001 12:59:04 -0400 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id MAA57494 for ; Sat, 7 Apr 2001 12:57:41 -0400 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.117.200.72]) by northrelay02.pok.ibm.com (8.8.8m3/NCO v4.95) with ESMTP id MAA122626 for ; Sat, 7 Apr 2001 12:54:30 -0400 Importance: Normal To: w3c-dist-auth@w3.org X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "Jason Crawford" Date: Sat, 7 Apr 2001 12:41:15 -0400 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 5.0.7 |March 21, 2001) at 04/07/2001 12:59:01 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: Re: Flavors of DELETE Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4742 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: My tendency would be to recommend that we finish clarifying the current semantics of rfc2518 before we add additional concepts. Of course we can do this with an eye to what you've proposed so as not to preclude it as an extension later. ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com From w3c-dist-auth-request@w3.org Mon Apr 9 11:44:53 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA09739 for ; Mon, 9 Apr 2001 11:44:52 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id LAA21515; Mon, 9 Apr 2001 11:29:35 -0400 (EDT) Resent-Date: Mon, 9 Apr 2001 11:29:35 -0400 (EDT) Resent-Message-Id: <200104091529.LAA21515@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id LAA21461 for ; Mon, 9 Apr 2001 11:29:28 -0400 (EDT) Received: from cissco.hq.caci.com (cissco.caci.com [209.117.168.111]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id LAA21488 for ; Mon, 9 Apr 2001 11:29:28 -0400 Received: by cissco.hq.caci.com; id LAA24622; Mon, 9 Apr 2001 11:31:59 -0400 (EDT) Received: from cacimta.hq.caci.com(198.135.9.108) by cissco.hq.caci.com via smap (V5.0) id xma024601; Mon, 9 Apr 01 11:31:49 -0400 To: "Jim Amsden" Cc: w3c-dist-auth@w3c.org, w3c-dist-auth-request@w3.org X-Mailer: Lotus Notes Release 5.0.4 June 8, 2000 Message-ID: From: "Ying Dang" Date: Mon, 9 Apr 2001 11:28:19 -0400 X-MIMETrack: Serialize by Router on CACIMTA/CACI(Release 5.0.4 |June 8, 2000) at 04/09/2001 11:29:04 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: Locked resource Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4743 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: I have a question about the LOCK method. If a resource on a server is locked by a user and after that the server is crashed, what will happen to the resource? How can I back it up? Thanks. -Ying From w3c-dist-auth-request@w3.org Mon Apr 9 11:57:51 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA10082 for ; Mon, 9 Apr 2001 11:57:51 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id LAA23002; Mon, 9 Apr 2001 11:52:21 -0400 (EDT) Resent-Date: Mon, 9 Apr 2001 11:52:21 -0400 (EDT) Resent-Message-Id: <200104091552.LAA23002@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id LAA22976 for ; Mon, 9 Apr 2001 11:52:17 -0400 (EDT) Received: from e24.nc.us.ibm.com (e24.nc.us.ibm.com [32.97.136.230]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id LAA23860 for ; Mon, 9 Apr 2001 11:52:17 -0400 Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e24.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id LAA41366 for ; Mon, 9 Apr 2001 11:52:41 -0500 Received: from d04nm303.raleigh.ibm.com (d04nm303.raleigh.ibm.com [9.67.228.168]) by southrelay02.raleigh.ibm.com (8.11.1/NCO v4.95) with ESMTP id f39FqAG35502 for ; Mon, 9 Apr 2001 11:52:11 -0400 To: w3c-dist-auth@w3c.org X-Mailer: Lotus Notes Release 5.0.6a January 17, 2001 Message-ID: From: "Jim Amsden" Date: Mon, 9 Apr 2001 11:47:25 -0400 X-MIMETrack: Serialize by Router on D04NM303/04/M/IBM(Release 5.0.6 |December 14, 2000) at 04/09/2001 11:52:10 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: Re: Locked resource Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4744 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Ying, Such behavior is completely up to the server. It would be hard to predict all the possible implementations. It will probably be difficult to know what an individual server might do. The implementors might not be able to predict the behavior either as it probably delpends on how the server crashed, and what it was doing when it crashed. Backups don't have anything to do with locking. How backups are done is not specified by the WebDAV protocol. If you want to "backup" the resource yourself, do a GET and store the resource in some other space. Servers do need to provide some way to unlock resources when the lock owner is not available to do so. How this is done is also server dependent. I have a question about the LOCK method. If a resource on a server is locked by a user and after that the server is crashed, what will happen to the resource? How can I back it up? Thanks. -Ying From w3c-dist-auth-request@w3.org Tue Apr 10 01:11:05 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA25598 for ; Tue, 10 Apr 2001 01:11:05 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id VAA28570; Mon, 9 Apr 2001 21:17:16 -0400 (EDT) Resent-Date: Mon, 9 Apr 2001 21:17:16 -0400 (EDT) Resent-Message-Id: <200104100117.VAA28570@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id VAA28550 for ; Mon, 9 Apr 2001 21:17:11 -0400 (EDT) Received: from cats.ucsc.edu (rumpleteazer.ucsc.edu [128.114.129.45]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id VAA16546 for ; Mon, 9 Apr 2001 21:17:11 -0400 Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177]) by cats.ucsc.edu (8.9.3/8.8.4.cats-athena) with SMTP id SAA05536 for ; Mon, 9 Apr 2001 18:17:13 -0700 (PDT) From: "Jim Whitehead" To: "WebDAV WG" Date: Mon, 9 Apr 2001 18:15:41 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Subject: Minneapolis IETF minutes (preliminary) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4745 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit These are the minutes recorded at the WebDAV WG meeting at IETF-50. Please note any errors you find in the minutes -- I need to submit the final version by this Friday. An HTML version of these minutes can be found at: http://www.ics.uci.edu/pub/ietf/webdav/minneapolis01/minutes.html Big thanks are due John Stracke, who took some *very* detailed minutes of the WebDAV meeting! - Jim WEBDAV WORKING GROUP Meeting Minutes IETF-50, Minneapolis, MN March 22, 2001 The WebDAV WG met on Thursday, March 22, 2001, from 0900-1130, with approximately 25 people in attendance. The meeting was chaired by Jim Whitehead, and meeting notes were recorded by John Stracke. Final minutes were prepared by Jim Whitehead. Note that throughout the meeting, brief notes and observations on the sense of the room on various issues were recorded in a slide presentation that was on-screen during the entire meeting. The final state of these slides can be found at URL: http://www.ics.uci.edu/pub/ietf/webdav/minneapolis01/meeting.htm The meeting began with a brief discussion of the agenda: * Open issues in the ACL specification * Reviving DASL * Improved status reporting * Moving 2518 to Draft status o Process for moving forward o Discussion of issues list items ACL Spec open issues Does a null resource have an ACL? Geoff Clemm: does this mean null or lock-null (two separate questions). He pointed out that, if null resources exist and can be PROPFOUND, then Depth: infinity becomes ridiculous. He also believes that, for lock-null, it's cheap to add ACLs, but not necessarily useful. John Stracke pointed out that it would be nice to be able to take out a lock, set the ACL for non-world-readable, then create, so that there's no window where the resource may be world-writable. Geoff noted that her concerned about the complexity tradeoff. John pointed out that, in his scenario, one could lock, create with an empty body, set ACL, then write the real content. At this point, Geoff, Jim Whitehead, and Eric Sedlar started talking about eliminating lock-null resources altogether at Draft Standard; nobody objects. The consensus of the room was that lock-null resources do not have an ACL. Can an ldap: scheme URL be used for principal identifiers? In past revisions of the ACL specification, principal identifiers have always been http: scheme URLs; in San Diego, it was suggested that ldap: scheme URLs could make sense, since they refer to people. Jim Whitehead stated that this is a tradeoff between functionality on client and on server; the current system requires the DAV server to sync with LDAP server (if using LDAP), while the ldap: scheme URLs require the client to access the LDAP server directly. A compromise suggested on the list was to define the ldap-URL property, which points to the principal's LDAP entry. Larry Masinter asked: are we permitting https:? Why are we using URLs, but not permitting all schemes? Lisa Dusseault: if we don't support ldap: at all, are we going to need to duplicate LDAP functionality in DAV? Geoff: by having the DAV server do the mapping, we're exposing what we need (not much) without requiring the client to know LDAP. Lisa: "what we need" will probably grow, so we should support ldap-URL, to make sure we have an escape hatch. Larry: what are these URLs actually used for? Eric: accessing data about principals via PROPFIND; e.g., making a picklist for composing an ACL. Larry: OK, and you can't do PROPFIND on an ldap: URL, so clients would have to support LDAP. Geoff: all we want from the principal is grouping, display name, and username (for, e.g., Digest-Auth). John: can we require the DAV server to proxy for the ldap: URLs? Geoff: but then we get about the same functionality as the ldap-URL property. Eric: we should get some implementation experience first; nobody's done this yet. Larry: maybe implementations should make it a config option? Different people will care differently about LDAP integration. Geoff: the person who proposed the ldap: property has agreed that the ldap-URL property would meet his needs. Larry: This sounds odd -- what about other URL schemes with similar uses? Eric: I don't really see other such schemes being commonly used; there's no good way to map between them. Babu S*: two issues; one is permitting LDAP integration, and the other is permitting everything-under-the-sun integration. Jim Whitehead stated that he doesn't like the property idea; permitting ldap: URLs would be good enough. John: but what about LDAP schemas? Larry: so require that the schema contain certain properties. John: but, if we want to integrate with existing directories, that won't work. Warren: tarpit. [missed some bits] Geoff: ldap: URLs have interop problems (require clients to implement too much); the ldap-URL property lets clients get at LDAP data, but does not require them to do so. JimW: so that would let the DAV server be a gateway for just the DAV properties, but not block the other information. How about alt-URL, with an alternate URL, which may be ldap:? Geoff: OK; but how about a list? Eric: does 2518 permit non-http: URLs? Geoff: yes, but we should strike that. Eric: Why do we want to limit it like that? Geoff: for interop; we put constraints on the protocol to improve interop by keeping it simpler. Eric: but the client treats the principal URL as non-dereferenceable; why does it care what the scheme is? Warren: what are we trying to answer here? JimW put up two questions: "should the URIs identifying principals be limited to just http(s)?" and "should principal resources have an optional property 'alternateURL' that can point off to, e.g., an LDAP accessible network resource?". Larry: wait a minute; 2518 says that the principal must be an HTTP resource. So, OK, the "any scheme" bit is a hole. Geoff: server-side, non-HTTP resources is more expensive. Eric: client-side, exposing it as an HTTP resource is supposed to make it easier for the client; but it doesn't, because it requires the client to use the DAV server as an LDAP gateway. Geoff: if we support non-HTTP, then the client may well not be able to get those principals' data. Eric: but the server isn't required to make the principal resources respond to PROPFIND at all. Geoff: but, if it does expose the data, it's supposed to do it via PROPFIND. JimW: The worst-case with HTTP-only is not worse than the worst-case without; but the best-case with is significantly better than best-case without. [dropped some bits] Eric: we should note this as an open issue. Geoff: at a minimum, we need to fix the inconsistency in 2518 ("it's an HTTP resource" and "it may be any scheme"). JimW next tries to get a sense of the room on these two questions. Larry says the first one strongly depends on context, on how the spec gets written. JimW rewrites the question for clarity: "What URI schemes should be allowed for identifying principals?" Options listed: * http(s) only, or a URL that identifies a WebDAV principal resource * limited set (http(s), ldap(s)) * http(s) and others explicitly defined by additional specs (the first option was eventually merged into this one, since additional specs can always be written) * anything Chris Kaler: how about making it an opaque URL, and publishing Informational RFCs for how to work with different schemes? John: but we should really have some minimal set, that clients can use. Lisa: There must be some base level of capability that clients can rely on, without having to implement various approaches for various servers. Eric: how about this: use anything, but servers SHOULD use http(s), which is a privileged scheme that points to resources that SHOULD have additional properties (JimW added this to the list of options for the current question). Eric states that he does not want to make the DAV server replicate data from the LDAP server. John: but, if you're using LDAP for authentication, then you're doing that to some extent anyway. Larry: what if you're using mailto: for principal URLs? Eric: why would you do that? Lisa: mailto: URLs are commonly used for Web services, so that you have a single, verifiable, user ID across services. Chris: what about privacy issues of exposing the user's real name? Geoff: well, but you can use access control (or just not expose the data). Eric: if you don't have the properties, then there's not much point in making it an http: URL. Geoff: agreed, so the second SHOULD is OK. Larry: so what are these properties used for, anyway? Geoff: well, they're used for display in the GUI; they might be useful. Larry: what about auth ID, though? How is it tied to auth schemes? Nobody can really remember a good reason to have it. JimW: OK, so it seems like we have provisional sentiment to strike it. Eric: but what harm does it do? Nice for something like Unix's ls -l. Geoff: it's a potential security weakness (makes it easier to mount a dictionary attack), recorded as such in our security considerations; removing it would solve that. John: maybe we did want it for something like ls -l, where the username is the only way to find a user in the directory; if we have the alternateURL property, then we've got that. Geoff and JimW: agree. Larry: doesn't want to reach conclusion yet; we should go back and look at how clients actually use this stuff. JimW recording: provisionally (subject to the consensus of the list), we can eliminate the authentication-id property. The alternateURL property can cover many of the use cases envisioned for authentication-id, and is safer. However, we should look for more use cases. JimW recording: provisionally, the answer to the "what URL schemes are permitted" is "use anything, but servers SHOULD use http(s), which is a privileged scheme that points to resources that SHOULD have additional properties". JimW recording: sense of the room: we should have an alternateURL property. Babu: we seem to be using the terms interoperability and dependencies, and they're probably interchangeable (inversely). Larry raised a general plea: he was sent with the mission to ask that WebDAV and DeltaV and other specs do a better job than they do now of dealing with interactions and failure cases. There are too many cases where there are options whose purposes aren't well specified, and people who guess differently run into trouble. The alternateURL property is an example; what alternate information does it point to? Eric replied that we could put in better use cases; some were removed to keep the text pure, but the result is less clarity. Maybe there should be a companion document describing these use cases. Geoff added that there were problems with use cases in 2518, with people reading use-case text as normative. Putting it in a clearly non-normative companion document would help with this problem. Larry stated that explanatory text is not as good as making the normative text more precise, and Geoff agreed. JimW recorded the need to provide information in the specification on how a client might use the alternateURL, and what kind of schemes might be used. MAY/SHOULD/MUST ACL properties be returned by an allprop PROPIND? (None, some, all?) The view on list is that PROPFIND allprop MUST NOT return any ACL properties, since PROPFIND allprop is already too expensive, since the server has to compute all the live properties, and "current user privs" is very expensive to compute. No one in the room disagreed. Chris asked, how about striking allprop altogether? Lisa replied that it is too late, since there is at least one client that depends on it. Eric noted that it is useful for copying resources from server to server. Geoff replied that a client can use propname to list all the names, then retrieve all properties explicitly by name. JimW noted that it might be possible to deprecate it in going to Draft Standard, then strike it when going from Draft Standard to Standard; but we need to look into it better. Didn't someone on the list give a rousing defense of allprop? Geoff replied, yes, but it was because he used it, not because it was the only way; a slow transition wouldn't be so hard on him. At a minimum, we can make sure that new specifications state that their new live properties do not come back from allprop. Larry warned the group to be wary about transitions. Geoff added that, maybe, when deprecated, it can go down to "all dead properties". There was some discussion on performance reasons not to have PROPFIND return live properties. Larry notes that the performance hit only occurs when PROPFIND allprop is used, and, if it's used, it's because people want the functionality, and workarounds may be less efficient. Room seems tentatively pleased with limiting PROPFIND allprop to return only dead properties. What is the purpose of the DAV:isprincipal property? This issue was raised by Larry Masinter. JimW noted that this is a workaround for the preferred way of expressing this information, which is in the DAV:resourcetype property. However, one early implementation (MS WebFolders) considers anything with a non-empty resourcetype to be a collection, and displays them as collections in the Web Folders UI. Geoff Clemm noted that a principal collection (a group?) is both a collection and a principal. Larry then noted that WebFolders won't display the correct icon anyway, since at present it will make a principal look like a document. Geoff replied that if a principal looks like a folder in the UI users will think they can add members to it. There was a brief discussion over what a GET to a principal URL returns; conclusion seems to be that we don't have any particular reason to define it. There was agreement to explicitly note in the ACL specification that GET on a principal resource is intentionally undefined. Eric: since we have different types that can be mixed together (e.g., collection, principal, versioned), maybe we should be using properties like DAV:isprincipal. These types aren't unitary types; they're interfaces implemented by the resources. Discussion on which way is best. Larry stated that it's a moral argument; either punish the bad implementation or write the specification around it. Geoff noted that what they did wasn't so terrible, after all. JimW recorded the (weak) sense of the room to leave the DAV:isprincipal property in place. Reviving DASL There was a brief discussion on reviving the DAV Searching and Locating (DASL) protocol specification, which currently is in Internet-Draft form, and is not currently being worked on. JimW asked: * Who is interested in seeing it completed? Couple of people raised hands. * When should it be completed? Larry noted that the people who want it are some of the same people who are working on ACLs and improved status reporting; let's not delay those. Eric added that there might be synergy with XML Query (XML Query does searching; DASL would limit it to particular directories, for example), so we should at least let XML Query people know DASL is coming. Lisa stated that XML Query isn't so great for searching properties (as DASL was focused on). Xythos has implemented it; what were the problems that held back the spec? JimW said that the biggest one was I18N (e.g., sorting, string matching); somebody needs to look at it in that light. Might be able to refer to Unicode docs. Larry suggested that one path forward is to publish the existing DASL protocol specification as Experimental (with the added note that Xythos has implemented), so that people can try it; when we get time to work on it, then there'll be more experience with it. The sense of the room agreed that this was a good approach. * Who is willing to work on it? This question was not asked after all. Moving 2518 to Draft status Four-part process: * Resolve issue list items on mailing list o Goal: handle 2/week o Document solutions with pros/cons * Hold face-to-face interoperability b*ke-off o Flush out new issues o Develop test plan doc on mailing list o Aim for late May/early June. * Develop an online form to gather initial implementation and testing data o Used successfully for HTTP/1.1 o Can be done before the b*ke-off * Create a farm of significant server implementations for ongoing interop testing o JimW can host and administer machines at UC Santa Cruz, but cannot afford the machines/software. (Easier to put machines on open Internet at university than in most companies.) Probably not beta software, though. o Donations needed. Warren asked whether it would it be useful for potential customers to get the results of this testing? Larry noted that there are two types of interop events. The first kind is closed, usually with prerelease products, to get the products enhanced to be interoperable; the second is interoperability demos at trade shows, once the vendors know the results are good. We need the first before we can do the second. Survey of the room: 4-5 people interested in attending the b*ke-off. Advanced Status Reporting (ASR) Lisa Dusseault next led a discussion on advanced status reporting within WebDAV. Lisa asked who has read the advanced status reporting I-D? No hand raised. Lisa then stated, "Don't worry about it; it hasn't changed significantly from the proposal, which people liked." Larry noted (looking at the draft on his laptop) that the Accept-Error: header looks like a general HTTP extension, and Lisa agreed. Larry then stated that "Accept-Error: text/xml" isn't actually generic XML; it implies this specification's XML DTD. Maybe it should be text/xml-rfcXXXX, or some such, so that some future Even More Advanced Status Reporting can define its own format. Lisa replied that, really, the spec is open, it just has to have a particular root element. Geoff added that it would be pretty nasty to wind up creating a new namespace of error type specs. Eric suggested that we define an XML namespace URI for this version. JimW: why not just always send the ASR? John: but then the existing clients don't have HTML to show to the user. JimW: how about putting it in a header? Lisa: not enough information. JimW: what is the goal? Improve the message to the user, or enable better machine-comprehensible error handling? He says it's more for the user; e.g., 423 Locked can give more information on what was locked and how. Geoff: machine-comprehensible error handling does improve the message to the user. Lisa: the server could already send a more detailed HTML message to the user; structuring it makes it possible for the UI to assist the user in dealing with the error. Larry: how about embedding XML in HTML? Lisa: lots of people said that was too messy. Larry: how about multipart/alternative? Lisa: was considered, but bandwidth costs. Larry: servers also have to worry about CPU cost of computing the response. Lisa: but servers aren't likely to implement ASR at all unless they know the clients are asking for it. More discussion. JimW: Accept-Error: means bandwidth costs, too, on every request. Larry: investigate: can browsers accept multipart/alternative anyway? JimW: maybe we should narrow this down; add it to base WebDAV (for better interoperability), but not expose it for general HTTP. Or even just improve the specification of error cases, not necessarily bundle up all the data into XML. *** Meeting adjourned *** From w3c-dist-auth-request@w3.org Tue Apr 10 10:48:49 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA17072 for ; Tue, 10 Apr 2001 10:48:48 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id KAA07697; Tue, 10 Apr 2001 10:40:59 -0400 (EDT) Resent-Date: Tue, 10 Apr 2001 10:40:59 -0400 (EDT) Resent-Message-Id: <200104101440.KAA07697@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id KAA07675 for ; Tue, 10 Apr 2001 10:40:55 -0400 (EDT) Received: from sus-ma1it00.rational.com (ext-37140.rational.com [192.229.37.140]) by tux.w3.org (8.9.3/8.9.3) with SMTP id KAA25678 for ; Tue, 10 Apr 2001 10:40:54 -0400 Received: from 192.168.215.70 by sus-ma1it00.rational.com (InterScan E-Mail VirusWall NT); Tue, 10 Apr 2001 10:41:29 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Tue, 10 Apr 2001 10:41:29 -0400 Message-ID: <3906C56A7BD1F54593344C05BD1374B1018E233D@SUS-MA1IT01> From: "Clemm, Geoff" To: "'Gary Gershon'" , Bruce Williams Cc: WebDAV Working Group Date: Tue, 10 Apr 2001 10:41:30 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: RE: [offlist] WebDAV Delete post (Flavors of DELETE) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4747 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: On the issue of trash folders: HTTP headers are a poor way of marshalling method specific information. A header exists in a global namespace, and should be reserved for things that proxies need to look at. So if you want to extend DELETE, I would suggest following the standard WebDAV approach and add an XML request body to the DELETE method. In the specific case of trash folders, I would suggest a different approach. In particular, I would add an OPTIONS parameter that would let you find out "where is the trash collection for this resource". Then the client could either issue a DELETE or a MOVE to that trash collection, depending on what the user wants to do. Cheers, Geoff From: Gary Gershon [mailto:gershon@celsus.net] ... I think a bit of background on my suggestion that we have an additional WebDAV HTTP header for delete processing would clarify its goals: I've been working on enterprise WebDAV implementations for the last year, primarily using the Xythos server. Xythos provides a very handy option to allow deleted files to be automatically stored in a trash folder associated with the particular root directory. This is great for the "oops" factor where one wants to recover a deleted file, and complements their automatic versioning facility. Other implementations, of course, have different schemes, and this is why it would be good to be able to express the original DELETE request more fully in WebDAV. We have four use cases where we do not want this trash-foldering to happen: 1. The user wrote something (perhaps in haste, or perhaps something that was confidential) that he/she does not want to be subsequently read by others either within the organization, or through the legal discovery process. 2. The document was being added by a program within a long-running unit-of-work and we want to do a rollback, rather than a commit, after it has already been stored and committed to the document server. Here we want to avoid wasting space. 3. Documents are being moved to long-term archive storage and deleted from the operational system to free space. This is done by a records retention application on a recurring (perhaps yearly) basis. By definition, we want to delete it completely from the operational system. 4. The user was using the file system to hold documents (and versions) temporarily as work-in-process. When the document is deemed finished ("Published") the temporary work products should not be retained. We like having the trash folder, so our current "work-around" to permanently delete a document is to issue two deletes. First for the document, and then for the trash folder copy. This requires the client (human or application) to know about the trash folder and have permission to delete stuff from it. It would be better if a single DELETE could communicate the entire request. This avoids having the client know the structure of the repository, have access to the trash folder, and avoids unit-of-work problems when multiple requests are required to fulfill the delete process. ... By adding a new delete header, the goal would be to have WebDAV fully communicate the client's intent in a single HTTP request. How the server honors the request depends on the implementation. If the installation is using a programmable server then they can customize this behavior to satisfy their business requirements. I think an environment of appropriate security can thus be built using WebDAV. I don't view the 'trash' folder as an OS flaw, but as a capability that serves to benefit the user community. It needs to be implemented and managed to meet business document retention requirements, and also eliminate the potentially wasteful accumulation of truly dead documents. Bruce, I think you are quite correct, if we are to have a secure environment, it will indeed take a overt effort to this end, and this requires a thoughtful technical implementation of WebDAV clients and servers. Gary At 11:12 PM 4/8/2001 -0700, you wrote: Gary, The delete, delete from trash, clear sectors on disk options you made reference to brings up something I have always been unclear about - what is the 'security' level required/provided by WebDAV? As the range of options you mentoned show, this is a classic "slippery slope". Where does it end? I believe many activities delete and leave items in the 'trash'. This can in some ways be viewed as a design flaw in the OS, or at least a flaw at some level of desired security. And this is the point - - if the desired level of security is above that provided, in general, by the OS - are we to attempt to make up for this? If we are to produce a 'secure' enviroment, ( not a bad thing! ), I believe it will take a overt effort to this end. Otherwise, we will just introduce complications here and there as we "see problems" to no real overall gain. But what do I know? :-) From w3c-dist-auth-request@w3.org Tue Apr 10 11:51:45 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA19048 for ; Tue, 10 Apr 2001 11:51:43 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id JAA03783; Tue, 10 Apr 2001 09:56:59 -0400 (EDT) Resent-Date: Tue, 10 Apr 2001 09:56:59 -0400 (EDT) Resent-Message-Id: <200104101356.JAA03783@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id JAA03761 for ; Tue, 10 Apr 2001 09:56:52 -0400 (EDT) Received: from smtp.snet.net (smtp.snet.net [204.60.6.55]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id JAA16459 for ; Tue, 10 Apr 2001 09:56:49 -0400 Received: from gmg600x.celsus.net (107.4.252.64.snet.net [64.252.4.107]) by smtp.snet.net (8.11.1/8.11.1/SNET-mx-1.4/D-1.10/O-1.7) with ESMTP id f3ADuYL24045; Tue, 10 Apr 2001 09:56:34 -0400 (EDT) Message-Id: <5.0.0.25.2.20010410081128.02e40dd8@pop3.norton.antivirus> X-Sender: ggershon/pop.snet.net@pop3.norton.antivirus X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Tue, 10 Apr 2001 09:54:53 -0400 To: Bruce Williams From: Gary Gershon Cc: WebDAV Working Group In-Reply-To: <001a01c0c0bc$05f06880$a302fea9@midnightwork> Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" Subject: Re: [offlist] WebDAV Delete post (Flavors of DELETE) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4746 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Bruce,

Security in WebDAV is a good topic.  It could actually be discussed on the forum, and I'm moving your security question (at the end of this post) back "on-list."  I trust you won't object.

WebDAV security is derived from the underlying system, and what is permitted would depend on the capabilities of that system.  WebDAV is just the protocol to communicate the message.  ("Don't kill the messenger!" :) ) 

Bruce, WebDAV, itself, cannot fix flaws in the underlying operating system, but it should allow us to effectively use the operating system features that are present.  Over time, useful features tend to be adopted by more systems, and flaws tend to be either rectified, or these systems fall into disuse.

I think a bit of background on my suggestion that we have an additional WebDAV HTTP header for delete processing would clarify its goals:

I've been working on enterprise WebDAV implementations for the last year, primarily using the Xythos server.  Xythos provides a very handy option to allow deleted files to be automatically stored in a trash folder associated with the particular root directory.  This is great for the "oops" factor where one wants to recover a deleted file, and complements their automatic versioning facility.

Other implementations, of course, have different schemes, and this is why it would be good to be able to express the original DELETE request more fully in WebDAV.

We have four use cases where we do not want this trash-foldering to happen:

1.  The user wrote something (perhaps in haste, or perhaps something that was confidential) that he/she does not want to be subsequently read by others either within the organization, or through the legal discovery process.

2.  The document was being added by a program within a long-running unit-of-work and we want to do a rollback, rather than a commit, after it has already been stored and committed to the document server.  Here we want to avoid wasting space.

3.  Documents are being moved to long-term archive storage and deleted from the operational system to free space.  This is done by a records retention application on a recurring (perhaps yearly) basis.  By definition, we want to delete it completely from the operational system.

4.  The user was using the file system to hold documents (and versions) temporarily as work-in-process.  When the document is deemed finished ("Published") the temporary work products should not be retained.

We like having the trash folder, so our current "work-around" to permanently delete a document is to issue two deletes.  First for the document, and then for the trash folder copy.  This requires the client (human or application) to know about the trash folder and have permission to delete stuff from it.

It would be better if a single DELETE could communicate the entire request.  This avoids having the client know the structure of the repository, have access to the trash folder, and avoids unit-of-work problems when multiple requests are required to fulfill the delete process.

As for security permissions, the Access Control List mechanism is quite appropriate to determine if the user should be allowed to issue a permanent delete request.  This would require a degree of granularity in the ACL permission structure to differentiate between a simple delete and a more complex one.  The WebDAV ACL group has been doing great work in this area.

Additionally, we use the HTTP User-Agent" header to further "lock-down" permissions.  We grant out-of-the-box clients, such as Microsoft Office, a reduced set of functions, than our programmed clients.  Thus a long-running-unit-of-work client program and an archiving client program would have unique User-Agent strings that are allowed to do things that the same userid/ACL could not do using their desktop clients. 

Of course, another of the nice things about WebDAV is that it uses HTTP, which allows the use of SSL -- if transmission interception of these headers was an issue.

By adding a new delete header, the goal would be to have WebDAV fully communicate the client's intent in a single HTTP request.  How the server honors the request depends on the implementation.  If the installation is using a programmable server then they can customize this behavior to satisfy their business requirements.

I think an environment of appropriate security can thus be built using WebDAV.  I don't view the 'trash' folder as an OS flaw, but as a capability that serves to benefit the user community.  It needs to be implemented and managed to meet business document retention requirements, and also eliminate the potentially wasteful accumulation of truly dead documents.  Bruce, I think you are quite correct, if we are to have a secure environment, it will indeed take a overt effort to this end, and this requires a thoughtful technical implementation of WebDAV clients and servers.

Gary

At 11:12 PM 4/8/2001 -0700, you wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Gary,

The delete, delete from trash, clear sectors on disk options you made
reference to brings up something I have always been unclear about -
what is the 'security' level required/provided by WebDAV? As the
range of options you mentoned show, this is a classic "slippery
slope".  Where does it end?

I believe many activities delete and leave items in the 'trash'.
This can in some ways be viewed as a design flaw in the OS, or at
least a flaw at some level of desired security. And this is the point
- - if the desired level of security is above that provided, in
general, by the OS - are we to attempt to make up for this?

If we are to produce a 'secure' enviroment, ( not a bad thing! ), I
believe it will take a overt effort to this end. Otherwise, we will
just introduce complications here and there as we "see problems" to
no real overall gain.

But what do I know? :-)

Bruce Williams            brucewms@pacbell.net
- -----------------------------------------------
Hic locus est ubi mors gaudet succurrere vitae



-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.5.3 for non-commercial use <http://www.pgp.com>

iQA/AwUBOtFSsHuDB3/hEB6MEQIX/gCfRzHEjpNzYJh2L3mHlK/v0QQhkIQAnRmU
VoF15I5xT4MlxmqEuDBvaY7l
=dgfy
-----END PGP SIGNATURE-----
From w3c-dist-auth-request@w3.org Tue Apr 10 12:49:15 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA20558 for ; Tue, 10 Apr 2001 12:49:14 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA21493; Tue, 10 Apr 2001 12:42:53 -0400 (EDT) Resent-Date: Tue, 10 Apr 2001 12:42:53 -0400 (EDT) Resent-Message-Id: <200104101642.MAA21493@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id MAA21467 for ; Tue, 10 Apr 2001 12:42:49 -0400 (EDT) Received: from megapathdsl.net (snowbird.megapath.net [216.200.176.7]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id MAA08886 for ; Tue, 10 Apr 2001 12:42:48 -0400 Received: from [216.36.75.57] (HELO beaver) by megapathdsl.net (CommuniGate Pro SMTP 3.4.3) with SMTP id 19042344; Tue, 10 Apr 2001 09:42:26 -0700 From: "Lisa Dusseault" To: "Clemm, Geoff" , "WebDAV Working Group" Date: Tue, 10 Apr 2001 09:41:35 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: <3906C56A7BD1F54593344C05BD1374B1018E2340@SUS-MA1IT01> Subject: RE: [offlist] WebDAV Delete post (Flavors of DELETE) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4750 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Perhaps this would be a good candidate to solve with status-reporting. THe server can do whatever it's configured to do, and send a slightly different success response depending on whether it truly, really, deleted the file, or whether it moved it (and can specify location). This allows the client to potentially delete the trash version. I also just realized, Gary, that we can't guarantee that clients will always be able to force a true delete. It might be against the wishes of the administrators of the system. So a system-wide trash bin might be set up to not allow stuff to be removed from it. Useful if auditing is required, no? lisa > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff > Sent: Tuesday, April 10, 2001 9:27 AM > To: WebDAV Working Group > Subject: RE: [offlist] WebDAV Delete post (Flavors of DELETE) > > > Good points. I agree that a client that wants to provide the advanced > behavior to a downlevel client would have to provide an override > capability (e.g. some method arguments) for an advanced client > that wants "the other" functionality. > > There remains the question of whether (in this particular case) > the benefit > of providing advanced behavior to downlevel clients is worth the cost > of adding these parameters to the DELETE method (protocol bloat, and all > that ...). > > Cheers, > Geoff > > -----Original Message----- > From: Lisa Dusseault [mailto:lisa@xythos.com] > > Geoff, > > Good suggestion about marshalling in the body rather than the > headers. But > the DELETE/MOVE choice won't work. > > The problem is that choosing the default behaviour means working with > clients that are minimally DAV compatible, and that means that > one maps the > request that those clients are going to make (DELETE) to the default > behaviour. One puts the onus on clients that understand the difference to > make the special request (DELETE + I-mean-it-really-blow-it-away). > > Ugly, but that's the kind of compromise one has to make when designing a > protocol piece by piece. It's the price we pay for having been able to > finish DAV when we did rather than 10 yrs from now :) > > lisa > > > -----Original Message----- > > From: w3c-dist-auth-request@w3.org > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff > > Sent: Tuesday, April 10, 2001 7:42 AM > > To: 'Gary Gershon'; Bruce Williams > > Cc: WebDAV Working Group > > Subject: RE: [offlist] WebDAV Delete post (Flavors of DELETE) > > > > > > On the issue of trash folders: > > > > HTTP headers are a poor way of marshalling method specific > > information. A header exists in a global namespace, and should be > > reserved for things that proxies need to look at. > > > > So if you want to extend DELETE, I would suggest following the > > standard WebDAV approach and add an XML request body to the DELETE > > method. > > > > In the specific case of trash folders, I would suggest a different > > approach. In particular, I would add an OPTIONS parameter that would > > let you find out "where is the trash collection for this resource". > > Then the client could either issue a DELETE or a MOVE to that trash > > collection, depending on what the user wants to do. > > > > Cheers, > > Geoff > > > > > > From: Gary Gershon [mailto:gershon@celsus.net] > > > > ... > > I think a bit of background on my suggestion that we have an > > additional WebDAV HTTP header for delete processing would clarify > > its goals: > > > > I've been working on enterprise WebDAV implementations for the last > > year, primarily using the Xythos server. Xythos provides a very > > handy option to allow deleted files to be automatically stored in a > > trash folder associated with the particular root directory. This > > is great for the "oops" factor where one wants to recover a deleted > > file, and complements their automatic versioning facility. > > > > Other implementations, of course, have different schemes, and this > > is why it would be good to be able to express the original DELETE > > request more fully in WebDAV. > > > > We have four use cases where we do not want this trash-foldering to > > happen: > > > > 1. The user wrote something (perhaps in haste, or perhaps > > something that was confidential) that he/she does not want to > > be subsequently read by others either within the organization, > > or through the legal discovery process. > > > > 2. The document was being added by a program within a long-running > > unit-of-work and we want to do a rollback, rather than a > > commit, after it has already been stored and committed to the > > document server. Here we want to avoid wasting space. > > > > 3. Documents are being moved to long-term archive storage and > > deleted from the operational system to free space. This is > > done by a records retention application on a recurring (perhaps > > yearly) basis. By definition, we want to delete it completely > > from the operational system. > > > > 4. The user was using the file system to hold documents (and > > versions) temporarily as work-in-process. When the document is > > deemed finished ("Published") the temporary work products > > should not be retained. > > > > We like having the trash folder, so our current "work-around" to > > permanently delete a document is to issue two deletes. First for > > the document, and then for the trash folder copy. This requires > > the client (human or application) to know about the trash folder > > and have permission to delete stuff from it. > > > > It would be better if a single DELETE could communicate the entire > > request. This avoids having the client know the structure of the > > repository, have access to the trash folder, and avoids > > unit-of-work problems when multiple requests are required to > > fulfill the delete process. > > > > ... > > > > By adding a new delete header, the goal would be to have WebDAV > > fully communicate the client's intent in a single HTTP request. > > How the server honors the request depends on the implementation. > > If the installation is using a programmable server then they can > > customize this behavior to satisfy their business requirements. > > > > I think an environment of appropriate security can thus be built > > using WebDAV. I don't view the 'trash' folder as an OS flaw, but > > as a capability that serves to benefit the user community. It > > needs to be implemented and managed to meet business document > > retention requirements, and also eliminate the potentially wasteful > > accumulation of truly dead documents. Bruce, I think you are quite > > correct, if we are to have a secure environment, it will indeed > > take a overt effort to this end, and this requires a thoughtful > > technical implementation of WebDAV clients and servers. > > > > Gary > > > > At 11:12 PM 4/8/2001 -0700, you wrote: > > > > Gary, > > > > The delete, delete from trash, clear sectors on disk options you > > made reference to brings up something I have always been unclear > > about - what is the 'security' level required/provided by WebDAV? > > As the range of options you mentoned show, this is a classic > > "slippery slope". Where does it end? > > > > I believe many activities delete and leave items in the 'trash'. > > This can in some ways be viewed as a design flaw in the OS, or at > > least a flaw at some level of desired security. And this is the > > point - - if the desired level of security is above that provided, > > in general, by the OS - are we to attempt to make up for this? > > > > If we are to produce a 'secure' enviroment, ( not a bad thing! ), I > > believe it will take a overt effort to this end. Otherwise, we will > > just introduce complications here and there as we "see problems" to > > no real overall gain. > > > > But what do I know? :-) From w3c-dist-auth-request@w3.org Tue Apr 10 12:58:10 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA20967 for ; Tue, 10 Apr 2001 12:58:08 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA24082; Tue, 10 Apr 2001 12:52:29 -0400 (EDT) Resent-Date: Tue, 10 Apr 2001 12:52:29 -0400 (EDT) Resent-Message-Id: <200104101652.MAA24082@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id MAA24062 for ; Tue, 10 Apr 2001 12:52:23 -0400 (EDT) Received: from localhost.localdomain ([216.52.68.3]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id MAA10275 for ; Tue, 10 Apr 2001 12:52:23 -0400 Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.11.0/8.11.0) with ESMTP id f3AGxZe30907 for ; Tue, 10 Apr 2001 12:59:38 -0400 Message-ID: <3AD33BF7.ACEA0EA5@ecal.com> Date: Tue, 10 Apr 2001 12:59:35 -0400 From: John Stracke X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i586) X-Accept-Language: en, de, es MIME-Version: 1.0 To: WebDAV Working Group References: <3906C56A7BD1F54593344C05BD1374B1018E233D@SUS-MA1IT01> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [offlist] WebDAV Delete post (Flavors of DELETE) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4751 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit "Clemm, Geoff" wrote: > HTTP headers are a poor way of marshalling method specific > information. A header exists in a global namespace, and should be > reserved for things that proxies need to look at. It *might* be useful for a proxy to know that a resource has been moved to a trash folder--it can update its cache. On the other hand, looking through the trash folder isn't going to be all that common. Uh...ah! And the HTTP/1.1 definition of DELETE semi-forbids moving the resource to a trash folder that can be accessed via HTTP: the server SHOULD NOT indicate success unless, at the time the response is given, it intends to delete the resource or move it to an inaccessible location. (RFC-2616, section 9.7, first paragraph.) > So if you want to extend DELETE, I would suggest following the > standard WebDAV approach and add an XML request body to the DELETE > method. It might also be useful to have a response body, to indicate what action was actually taken. -- /==============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own.| |Chief Scientist |=============================================| |eCal Corp. |"The avalanche has already started. It is too| |francis@ecal.com|late for the pebbles to vote." --Kosh | \==============================================================/ From w3c-dist-auth-request@w3.org Tue Apr 10 13:09:57 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA21320 for ; Tue, 10 Apr 2001 13:09:57 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA17149; Tue, 10 Apr 2001 12:12:47 -0400 (EDT) Resent-Date: Tue, 10 Apr 2001 12:12:47 -0400 (EDT) Resent-Message-Id: <200104101612.MAA17149@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id MAA17124 for ; Tue, 10 Apr 2001 12:12:41 -0400 (EDT) Received: from megapathdsl.net (snowbird.megapath.net [216.200.176.7]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id MAA05049 for ; Tue, 10 Apr 2001 12:12:37 -0400 Received: from [216.36.75.57] (HELO beaver) by megapathdsl.net (CommuniGate Pro SMTP 3.4.3) with SMTP id 19032811; Tue, 10 Apr 2001 09:12:15 -0700 From: "Lisa Dusseault" To: "Clemm, Geoff" , "'Gary Gershon'" , "Bruce Williams" Cc: "WebDAV Working Group" Date: Tue, 10 Apr 2001 09:11:24 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: <3906C56A7BD1F54593344C05BD1374B1018E233D@SUS-MA1IT01> Subject: RE: [offlist] WebDAV Delete post (Flavors of DELETE) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4748 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Geoff, Good suggestion about marshalling in the body rather than the headers. But the DELETE/MOVE choice won't work. The problem is that choosing the default behaviour means working with clients that are minimally DAV compatible, and that means that one maps the request that those clients are going to make (DELETE) to the default behaviour. One puts the onus on clients that understand the difference to make the special request (DELETE + I-mean-it-really-blow-it-away). Ugly, but that's the kind of compromise one has to make when designing a protocol piece by piece. It's the price we pay for having been able to finish DAV when we did rather than 10 yrs from now :) lisa > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff > Sent: Tuesday, April 10, 2001 7:42 AM > To: 'Gary Gershon'; Bruce Williams > Cc: WebDAV Working Group > Subject: RE: [offlist] WebDAV Delete post (Flavors of DELETE) > > > On the issue of trash folders: > > HTTP headers are a poor way of marshalling method specific > information. A header exists in a global namespace, and should be > reserved for things that proxies need to look at. > > So if you want to extend DELETE, I would suggest following the > standard WebDAV approach and add an XML request body to the DELETE > method. > > In the specific case of trash folders, I would suggest a different > approach. In particular, I would add an OPTIONS parameter that would > let you find out "where is the trash collection for this resource". > Then the client could either issue a DELETE or a MOVE to that trash > collection, depending on what the user wants to do. > > Cheers, > Geoff > > > From: Gary Gershon [mailto:gershon@celsus.net] > > ... > I think a bit of background on my suggestion that we have an > additional WebDAV HTTP header for delete processing would clarify > its goals: > > I've been working on enterprise WebDAV implementations for the last > year, primarily using the Xythos server. Xythos provides a very > handy option to allow deleted files to be automatically stored in a > trash folder associated with the particular root directory. This > is great for the "oops" factor where one wants to recover a deleted > file, and complements their automatic versioning facility. > > Other implementations, of course, have different schemes, and this > is why it would be good to be able to express the original DELETE > request more fully in WebDAV. > > We have four use cases where we do not want this trash-foldering to > happen: > > 1. The user wrote something (perhaps in haste, or perhaps > something that was confidential) that he/she does not want to > be subsequently read by others either within the organization, > or through the legal discovery process. > > 2. The document was being added by a program within a long-running > unit-of-work and we want to do a rollback, rather than a > commit, after it has already been stored and committed to the > document server. Here we want to avoid wasting space. > > 3. Documents are being moved to long-term archive storage and > deleted from the operational system to free space. This is > done by a records retention application on a recurring (perhaps > yearly) basis. By definition, we want to delete it completely > from the operational system. > > 4. The user was using the file system to hold documents (and > versions) temporarily as work-in-process. When the document is > deemed finished ("Published") the temporary work products > should not be retained. > > We like having the trash folder, so our current "work-around" to > permanently delete a document is to issue two deletes. First for > the document, and then for the trash folder copy. This requires > the client (human or application) to know about the trash folder > and have permission to delete stuff from it. > > It would be better if a single DELETE could communicate the entire > request. This avoids having the client know the structure of the > repository, have access to the trash folder, and avoids > unit-of-work problems when multiple requests are required to > fulfill the delete process. > > ... > > By adding a new delete header, the goal would be to have WebDAV > fully communicate the client's intent in a single HTTP request. > How the server honors the request depends on the implementation. > If the installation is using a programmable server then they can > customize this behavior to satisfy their business requirements. > > I think an environment of appropriate security can thus be built > using WebDAV. I don't view the 'trash' folder as an OS flaw, but > as a capability that serves to benefit the user community. It > needs to be implemented and managed to meet business document > retention requirements, and also eliminate the potentially wasteful > accumulation of truly dead documents. Bruce, I think you are quite > correct, if we are to have a secure environment, it will indeed > take a overt effort to this end, and this requires a thoughtful > technical implementation of WebDAV clients and servers. > > Gary > > At 11:12 PM 4/8/2001 -0700, you wrote: > > Gary, > > The delete, delete from trash, clear sectors on disk options you > made reference to brings up something I have always been unclear > about - what is the 'security' level required/provided by WebDAV? > As the range of options you mentoned show, this is a classic > "slippery slope". Where does it end? > > I believe many activities delete and leave items in the 'trash'. > This can in some ways be viewed as a design flaw in the OS, or at > least a flaw at some level of desired security. And this is the > point - - if the desired level of security is above that provided, > in general, by the OS - are we to attempt to make up for this? > > If we are to produce a 'secure' enviroment, ( not a bad thing! ), I > believe it will take a overt effort to this end. Otherwise, we will > just introduce complications here and there as we "see problems" to > no real overall gain. > > But what do I know? :-) From w3c-dist-auth-request@w3.org Tue Apr 10 14:47:58 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA23449 for ; Tue, 10 Apr 2001 14:47:57 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA05534; Tue, 10 Apr 2001 14:38:26 -0400 (EDT) Resent-Date: Tue, 10 Apr 2001 14:38:26 -0400 (EDT) Resent-Message-Id: <200104101838.OAA05534@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id OAA05486 for ; Tue, 10 Apr 2001 14:38:21 -0400 (EDT) Received: from cats.ucsc.edu (rumpleteazer.ucsc.edu [128.114.129.45]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id OAA24235; Tue, 10 Apr 2001 14:38:20 -0400 Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177]) by cats.ucsc.edu (8.9.3/8.8.4.cats-athena) with SMTP id LAA07511; Tue, 10 Apr 2001 11:38:24 -0700 (PDT) From: "Jim Whitehead" To: , "WebDAV WG" Date: Tue, 10 Apr 2001 11:36:55 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Subject: Moving DASL to Experimental Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4752 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit The DAV Searching and Locating (DASL) protocol is a mechanism for remotely submitting search queries to a WebDAV server, using the "SEARCH" method. For approximately a year and a half, from 1999-2000, the IETF had a working group dedicated to working on the DASL protocol specification. Unfortunately, this working group did not make sufficient progress, and was ultimately closed. Current protocol drafts, and minutes from DASL meetings are recorded on the DASL site, at: http://www.webdav.org/dasl/ However, before the DASL WG ran out of steam, the DASL protocol specification got very close to completion. It is currently in an implementable state, and indeed, the Xythos Storage Server has an implementation of the DASL protocol. Exchange 2000 also implements the SEARCH method, but does not implement the DAV:basicsearch query syntax, and hence cannot be claimed to fully implement the DASL protocol. There was some discussion on reviving DASL at the Minneapolis IETF meeting. While several participants there were interested in seeing this work be completed, no one there could commit to working on the protocol, and finishing it. It is my understanding that the most significant remaining issues concern i18n search issues (sort ordering, string equality comparison, etc.). Participants at the Minneapolis meeting felt that other activities in the WebDAV space (DeltaV, access control, interoperability, to name a few) have higher current priority. As a result, DASL is not likely to percolate up to the top of the priority queue for quite some time. The suggestion was made in Minneapolis that the current DASL protocol specification be moved to Experimental status. From RFC 2026 ("The Internet Standards Process -- Revision 3"), an Experimental specification is: The "Experimental" designation typically denotes a specification that is part of some research or development effort. Such a specification is published for the general information of the Internet technical community and as an archival record of the work, subject only to editorial considerations and to verification that there has been adequate coordination with the standards process (see below). An Experimental specification may be the output of an organized Internet research effort (e.g., a Research Group of the IRTF), an IETF Working Group, or it may be an individual contribution. Basically, the Experimental designation would allow the current DASL protocol to be baselined as an RFC, and allow implementation of the protocol to begin, for the purpose of gathering additional information concerning the behavior of the protocol. When it comes time to revive DASL, and move it to Proposed Standard, the information gathered while the specification is in Experimental status will be very helpful in improving the specification, and in making the case that the specification is ready to move to Proposed. I personally favor moving the DASL specification to Experimenal status, since I feel it is a good way to express that the current DASL specification is solid enough to implement, and will increase the likelihood that other implementations of the DASL specification will be made, thus helping us to better understand the characteristics of this protocol. It is a course of action that requires low effort, and adds value to the existing specification. Assuming the WebDAV WG agrees with this course of action, in the near future I will be submitting the DASL protocol specification to the IESG for consideration as an Experimental RFC, and the DASL requirements document as an Informational RFC. - Jim From w3c-dist-auth-request@w3.org Tue Apr 10 15:05:16 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA23984 for ; Tue, 10 Apr 2001 15:05:15 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA18875; Tue, 10 Apr 2001 12:27:40 -0400 (EDT) Resent-Date: Tue, 10 Apr 2001 12:27:40 -0400 (EDT) Resent-Message-Id: <200104101627.MAA18875@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id MAA18855 for ; Tue, 10 Apr 2001 12:27:37 -0400 (EDT) Received: from sus-ma1it00.rational.com (ext-37140.rational.com [192.229.37.140]) by tux.w3.org (8.9.3/8.9.3) with SMTP id MAA06779 for ; Tue, 10 Apr 2001 12:27:37 -0400 Received: from 192.168.215.70 by sus-ma1it00.rational.com (InterScan E-Mail VirusWall NT); Tue, 10 Apr 2001 12:28:34 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Tue, 10 Apr 2001 12:28:34 -0400 Message-ID: <3906C56A7BD1F54593344C05BD1374B1018E2340@SUS-MA1IT01> From: "Clemm, Geoff" To: WebDAV Working Group Date: Tue, 10 Apr 2001 12:27:00 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [offlist] WebDAV Delete post (Flavors of DELETE) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4749 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Good points. I agree that a client that wants to provide the advanced behavior to a downlevel client would have to provide an override capability (e.g. some method arguments) for an advanced client that wants "the other" functionality. There remains the question of whether (in this particular case) the benefit of providing advanced behavior to downlevel clients is worth the cost of adding these parameters to the DELETE method (protocol bloat, and all that ...). Cheers, Geoff -----Original Message----- From: Lisa Dusseault [mailto:lisa@xythos.com] Geoff, Good suggestion about marshalling in the body rather than the headers. But the DELETE/MOVE choice won't work. The problem is that choosing the default behaviour means working with clients that are minimally DAV compatible, and that means that one maps the request that those clients are going to make (DELETE) to the default behaviour. One puts the onus on clients that understand the difference to make the special request (DELETE + I-mean-it-really-blow-it-away). Ugly, but that's the kind of compromise one has to make when designing a protocol piece by piece. It's the price we pay for having been able to finish DAV when we did rather than 10 yrs from now :) lisa > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff > Sent: Tuesday, April 10, 2001 7:42 AM > To: 'Gary Gershon'; Bruce Williams > Cc: WebDAV Working Group > Subject: RE: [offlist] WebDAV Delete post (Flavors of DELETE) > > > On the issue of trash folders: > > HTTP headers are a poor way of marshalling method specific > information. A header exists in a global namespace, and should be > reserved for things that proxies need to look at. > > So if you want to extend DELETE, I would suggest following the > standard WebDAV approach and add an XML request body to the DELETE > method. > > In the specific case of trash folders, I would suggest a different > approach. In particular, I would add an OPTIONS parameter that would > let you find out "where is the trash collection for this resource". > Then the client could either issue a DELETE or a MOVE to that trash > collection, depending on what the user wants to do. > > Cheers, > Geoff > > > From: Gary Gershon [mailto:gershon@celsus.net] > > ... > I think a bit of background on my suggestion that we have an > additional WebDAV HTTP header for delete processing would clarify > its goals: > > I've been working on enterprise WebDAV implementations for the last > year, primarily using the Xythos server. Xythos provides a very > handy option to allow deleted files to be automatically stored in a > trash folder associated with the particular root directory. This > is great for the "oops" factor where one wants to recover a deleted > file, and complements their automatic versioning facility. > > Other implementations, of course, have different schemes, and this > is why it would be good to be able to express the original DELETE > request more fully in WebDAV. > > We have four use cases where we do not want this trash-foldering to > happen: > > 1. The user wrote something (perhaps in haste, or perhaps > something that was confidential) that he/she does not want to > be subsequently read by others either within the organization, > or through the legal discovery process. > > 2. The document was being added by a program within a long-running > unit-of-work and we want to do a rollback, rather than a > commit, after it has already been stored and committed to the > document server. Here we want to avoid wasting space. > > 3. Documents are being moved to long-term archive storage and > deleted from the operational system to free space. This is > done by a records retention application on a recurring (perhaps > yearly) basis. By definition, we want to delete it completely > from the operational system. > > 4. The user was using the file system to hold documents (and > versions) temporarily as work-in-process. When the document is > deemed finished ("Published") the temporary work products > should not be retained. > > We like having the trash folder, so our current "work-around" to > permanently delete a document is to issue two deletes. First for > the document, and then for the trash folder copy. This requires > the client (human or application) to know about the trash folder > and have permission to delete stuff from it. > > It would be better if a single DELETE could communicate the entire > request. This avoids having the client know the structure of the > repository, have access to the trash folder, and avoids > unit-of-work problems when multiple requests are required to > fulfill the delete process. > > ... > > By adding a new delete header, the goal would be to have WebDAV > fully communicate the client's intent in a single HTTP request. > How the server honors the request depends on the implementation. > If the installation is using a programmable server then they can > customize this behavior to satisfy their business requirements. > > I think an environment of appropriate security can thus be built > using WebDAV. I don't view the 'trash' folder as an OS flaw, but > as a capability that serves to benefit the user community. It > needs to be implemented and managed to meet business document > retention requirements, and also eliminate the potentially wasteful > accumulation of truly dead documents. Bruce, I think you are quite > correct, if we are to have a secure environment, it will indeed > take a overt effort to this end, and this requires a thoughtful > technical implementation of WebDAV clients and servers. > > Gary > > At 11:12 PM 4/8/2001 -0700, you wrote: > > Gary, > > The delete, delete from trash, clear sectors on disk options you > made reference to brings up something I have always been unclear > about - what is the 'security' level required/provided by WebDAV? > As the range of options you mentoned show, this is a classic > "slippery slope". Where does it end? > > I believe many activities delete and leave items in the 'trash'. > This can in some ways be viewed as a design flaw in the OS, or at > least a flaw at some level of desired security. And this is the > point - - if the desired level of security is above that provided, > in general, by the OS - are we to attempt to make up for this? > > If we are to produce a 'secure' enviroment, ( not a bad thing! ), I > believe it will take a overt effort to this end. Otherwise, we will > just introduce complications here and there as we "see problems" to > no real overall gain. > > But what do I know? :-) From w3c-dist-auth-request@w3.org Tue Apr 10 15:34:18 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA24678 for ; Tue, 10 Apr 2001 15:34:18 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA10057; Tue, 10 Apr 2001 15:27:06 -0400 (EDT) Resent-Date: Tue, 10 Apr 2001 15:27:06 -0400 (EDT) Resent-Message-Id: <200104101927.PAA10057@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id PAA10037 for ; Tue, 10 Apr 2001 15:27:01 -0400 (EDT) Received: from cats.ucsc.edu (rumpleteazer.ucsc.edu [128.114.129.45]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id PAA30299 for ; Tue, 10 Apr 2001 15:27:01 -0400 Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177]) by cats.ucsc.edu (8.9.3/8.8.4.cats-athena) with SMTP id MAA18618; Tue, 10 Apr 2001 12:27:04 -0700 (PDT) From: "Jim Whitehead" To: "WebDAV WG" , Date: Tue, 10 Apr 2001 12:25:35 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Subject: XML version of RFC 2518, Adv. Collection drafts Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4753 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Due to the volunteer efforts of Julian Reschke, XML (and nice HTML) versions of RFC 2518, the Redirect References specification, and the Ordered Collection specification, are now available via the WebDAV WG web site, at: http://www.ics.uci.edu/pub/ietf/webdav/ These documents are compliant with RFC 2629 ("Writing I-Ds and RFCs using XML", by Marshall Rose), available at: http://www.ietf.org/rfc/rfc2629.txt In particular, this RFC states: 3.2 Converting to Text Format The author has written the xml2rfc tool [10], which reads the source file and produces both a text and HTML version of the document. (This memo was produced using the xml2rfc tool.) Note that xml2rfc isn't a validating tool, so it's a good idea to use either a validating editor or run a stand-alone validating parser prior to using the tool. Where reference [10] is: [10] http://memory.palace.org/authoring/ (See also http://xml.resource.org/). Since converting I-Ds and RFCs to text and HTML format has always been a *major* pain, and since Julian has gone to the effort of converting these documents to XML, I think it makes a lot of sense to start using the XML version as the original document format (switching from Word). RFC 2518: XML: http://www.ics.uci.edu/pub/ietf/webdav/protocol/rfc2518.xml HTML: http://www.ics.uci.edu/pub/ietf/webdav/protocol/rfc2518.html Redirect References Protocol: XML: http://www.ics.uci.edu/pub/ietf/webdav/collection/draft-ietf-webdav-redirect ref-protocol-02.xml HTML: http://www.ics.uci.edu/pub/ietf/webdav/collection/draft-ietf-webdav-redirect ref-protocol-02.html Ordered Collections Protocol: XML: http://www.ics.uci.edu/pub/ietf/webdav/collection/draft-ietf-webdav-ordering -protocol-02.xml HTML: http://www.ics.uci.edu/pub/ietf/webdav/collection/draft-ietf-webdav-ordering -protocol-02.html You probably won't be able to view the XML files directly in your browser, since it won't know the location of the XSLT (XML style sheet) file. The RFC 2629 XSLT file can be found at: http://www.ics.uci.edu/pub/ietf/webdav/protocol/rfc2629.xslt. Chose the "Save As file" option to save the XML locally, and view it in a text editor (or "View Source" on the XML page). I'm very grateful to Julian for his efforts in converting these documents to XML, and pathfinding use of the XML I-D and RFC tools. Thank you! - Jim From w3c-dist-auth-request@w3.org Tue Apr 10 17:23:55 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA26349 for ; Tue, 10 Apr 2001 17:23:52 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA17737; Tue, 10 Apr 2001 17:12:57 -0400 (EDT) Resent-Date: Tue, 10 Apr 2001 17:12:57 -0400 (EDT) Resent-Message-Id: <200104102112.RAA17737@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id RAA17717 for ; Tue, 10 Apr 2001 17:12:53 -0400 (EDT) Received: from mutley.ebuilt.net (nat.ebuilt.com [209.216.46.200]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id RAA10705 for ; Tue, 10 Apr 2001 17:12:52 -0400 Received: (from root@localhost) by mutley.ebuilt.net (8.11.1/8.11.1) id f3ALCCv18589 for ; Tue, 10 Apr 2001 14:12:12 -0700 Received: from waka.ebuilt.net (IDENT:root@i199.ir.ebuilt.net [10.1.2.199]) by mutley.ebuilt.net (8.11.1/8.11.1) with ESMTP id f3ALCC718508; Tue, 10 Apr 2001 14:12:12 -0700 Received: (from fielding@localhost) by waka.ebuilt.net (8.11.0/8.11.0) id f3ALAZs01082; Tue, 10 Apr 2001 14:10:35 -0700 Date: Tue, 10 Apr 2001 14:10:35 -0700 From: "Roy T. Fielding" To: "Clemm, Geoff" Cc: WebDAV Working Group Message-ID: <20010410141035.C968@waka.ebuilt.net> References: <3906C56A7BD1F54593344C05BD1374B1018E233D@SUS-MA1IT01> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.13-current-20010115i In-Reply-To: <3906C56A7BD1F54593344C05BD1374B1018E233D@SUS-MA1IT01>; from gclemm@rational.com on Tue, Apr 10, 2001 at 10:41:30AM -0400 X-AntiVirus: scanned for viruses by AMaViS 0.2.1-pre3 (http://amavis.org/) Subject: Re: [offlist] WebDAV Delete post (Flavors of DELETE) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4755 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: On Tue, Apr 10, 2001 at 10:41:30AM -0400, Clemm, Geoff wrote: > On the issue of trash folders: > > HTTP headers are a poor way of marshalling method specific > information. A header exists in a global namespace, and should be > reserved for things that proxies need to look at. > > So if you want to extend DELETE, I would suggest following the > standard WebDAV approach and add an XML request body to the DELETE > method. Huh? You've got that entirely backwards. HTTP header fields are intended to be method-specific. The only part of an HTTP message that is not supposed to be method-specific is the message payload (entity-headers and entity-body). I thought I made that perfectly clear in the HTTP spec, but it probably got lost in the noise. > In the specific case of trash folders, I would suggest a different > approach. In particular, I would add an OPTIONS parameter that would > let you find out "where is the trash collection for this resource". > Then the client could either issue a DELETE or a MOVE to that trash > collection, depending on what the user wants to do. Either the client knows where the trash is or it doesn't deserve to know where the trash might be -- it is just another collection on the server. Just make it an optional link in the metadata (a live property). ....Roy From w3c-dist-auth-request@w3.org Tue Apr 10 17:41:30 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA26712 for ; Tue, 10 Apr 2001 17:41:29 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA18927; Tue, 10 Apr 2001 17:35:27 -0400 (EDT) Resent-Date: Tue, 10 Apr 2001 17:35:27 -0400 (EDT) Resent-Message-Id: <200104102135.RAA18927@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id RAA18876 for ; Tue, 10 Apr 2001 17:35:21 -0400 (EDT) Received: from sus-ma1it00.rational.com (ext-37140.rational.com [192.229.37.140]) by tux.w3.org (8.9.3/8.9.3) with SMTP id RAA12630 for ; Tue, 10 Apr 2001 17:35:21 -0400 Received: from 192.168.215.70 by sus-ma1it00.rational.com (InterScan E-Mail VirusWall NT); Tue, 10 Apr 2001 17:36:22 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Tue, 10 Apr 2001 17:36:22 -0400 Message-ID: <3906C56A7BD1F54593344C05BD1374B1018E234B@SUS-MA1IT01> From: "Clemm, Geoff" To: WebDAV Working Group Date: Tue, 10 Apr 2001 17:36:25 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: RE: [offlist] WebDAV Delete post (Flavors of DELETE) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4756 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Some folks prefer to use OPTIONS for things that are true for the whole server, and some folks just hate live properties, but the live property is fine with me. As for the issue of whether to marshal in a request header vs. in a request body, a new request header eats up part of a global namespace, whereas an XML request body can use namespaces to keep extensions from stepping on each others toes, so I stand by my preference for using the request body for method specific parameters (of course, for methods like PUT that use the request body for content, that is not an option). Cheers, Geoff -----Original Message----- From: Roy T. Fielding [mailto:fielding@ebuilt.com] Sent: Tuesday, April 10, 2001 5:11 PM To: Clemm, Geoff Cc: WebDAV Working Group Subject: Re: [offlist] WebDAV Delete post (Flavors of DELETE) On Tue, Apr 10, 2001 at 10:41:30AM -0400, Clemm, Geoff wrote: > On the issue of trash folders: > > HTTP headers are a poor way of marshalling method specific > information. A header exists in a global namespace, and should be > reserved for things that proxies need to look at. > > So if you want to extend DELETE, I would suggest following the > standard WebDAV approach and add an XML request body to the DELETE > method. Huh? You've got that entirely backwards. HTTP header fields are intended to be method-specific. The only part of an HTTP message that is not supposed to be method-specific is the message payload (entity-headers and entity-body). I thought I made that perfectly clear in the HTTP spec, but it probably got lost in the noise. > In the specific case of trash folders, I would suggest a different > approach. In particular, I would add an OPTIONS parameter that would > let you find out "where is the trash collection for this resource". > Then the client could either issue a DELETE or a MOVE to that trash > collection, depending on what the user wants to do. Either the client knows where the trash is or it doesn't deserve to know where the trash might be -- it is just another collection on the server. Just make it an optional link in the metadata (a live property). ....Roy From w3c-dist-auth-request@w3.org Tue Apr 10 17:53:08 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA26845 for ; Tue, 10 Apr 2001 17:53:08 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA16556; Tue, 10 Apr 2001 16:48:18 -0400 (EDT) Resent-Date: Tue, 10 Apr 2001 16:48:18 -0400 (EDT) Resent-Message-Id: <200104102048.QAA16556@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id QAA16532 for ; Tue, 10 Apr 2001 16:48:14 -0400 (EDT) Received: from cats.ucsc.edu (rumpleteazer.ucsc.edu [128.114.129.45]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id QAA08413 for ; Tue, 10 Apr 2001 16:48:13 -0400 Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177]) by cats.ucsc.edu (8.9.3/8.8.4.cats-athena) with SMTP id NAA07668 for ; Tue, 10 Apr 2001 13:48:18 -0700 (PDT) From: "Jim Whitehead" To: "WebDAV WG" Date: Tue, 10 Apr 2001 13:46:48 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Subject: Moving RFC 2518 to Draft Standard Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4754 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit It's time to start the process of revising RFC 2518 to move it from Proposed Standard to Draft Standard status. Revising protocol specifications based on operational experience is a normal part of the IETF process. Standards-track protocol specifications begin at "Proposed Standard", then progress to "Draft Standard" and full "Standard". Currently RFC 2518 is a Proposed Standard. According to RFC 2026 ("The Internet Standards Process -- Revision 3"), a Proposed Standard has the following characteristics: 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. A Draft Standard, in contrast, has the following characteristics: A specification from which at least two independent and interoperable implementations from different code bases have been developed, and for which sufficient successful operational experience has been obtained, may be elevated to the "Draft Standard" level. ... The requirement for at least two independent and interoperable implementations applies to all of the options and features of the specification. In cases in which one or more options or features have not been demonstrated in at least two interoperable implementations, the specification may advance to the Draft Standard level only if those options or features are removed. The Working Group chair is responsible for documenting the specific implementations which qualify the specification for Draft or Internet Standard status along with documentation about testing of the interoperation of these implementations. The documentation must include information about the support of each of the individual options and features. This documentation should be submitted to the Area Director with the protocol action request. (see Section 6) A Draft Standard must be well-understood and known to be quite stable, both in its semantics and as a basis for developing an implementation. A Draft Standard may still require additional or more widespread field experience, since it is possible for implementations based on Draft Standard specifications to demonstrate unforeseen behavior when subjected to large-scale use in production environments. At last count, there are 22 independent WebDAV server code bases, and 9 indepdent client code bases, as well as 10 independent client APIs (see http://www.ics.uci.edu/pub/ietf/webdav/ for a listing). The WebDAV protocol is in daily use by a large number of people who are using it to do useful work. As a result, I believe the two criteria for advancing to Draft Standard have been met: (1) there are at least two interoperable implementations (from distinct code bases) of each feature, on the client and server side, and (2) sufficient operational experience has been developed for the WebDAV protocol. Therefore, as Chair, I hereby initiate the process of revising RFC 2518 and documenting interoperability experience for the purpose of advancing RFC 2518 to Draft Standard status. A following email will detail the process WebDAV WG will to follow to achieve this goal. - Jim Whitehead Chair, WebDAV WG From w3c-dist-auth-request@w3.org Tue Apr 10 18:27:05 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA27328 for ; Tue, 10 Apr 2001 18:27:04 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAA22002; Tue, 10 Apr 2001 18:21:49 -0400 (EDT) Resent-Date: Tue, 10 Apr 2001 18:21:49 -0400 (EDT) Resent-Message-Id: <200104102221.SAA22002@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id SAA21907 for ; Tue, 10 Apr 2001 18:21:43 -0400 (EDT) Received: from mutley.ebuilt.net (nat.ebuilt.com [209.216.46.200]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id SAA16771 for ; Tue, 10 Apr 2001 18:21:43 -0400 Received: (from root@localhost) by mutley.ebuilt.net (8.11.1/8.11.1) id f3AMLCr12499 for ; Tue, 10 Apr 2001 15:21:12 -0700 Received: from waka.ebuilt.net (IDENT:root@i199.ir.ebuilt.net [10.1.2.199]) by mutley.ebuilt.net (8.11.1/8.11.1) with ESMTP id f3AMLC712418; Tue, 10 Apr 2001 15:21:12 -0700 Received: (from fielding@localhost) by waka.ebuilt.net (8.11.0/8.11.0) id f3AMK7O01137; Tue, 10 Apr 2001 15:20:07 -0700 Date: Tue, 10 Apr 2001 15:20:07 -0700 From: "Roy T. Fielding" To: "Clemm, Geoff" Cc: WebDAV Working Group Message-ID: <20010410152007.F968@waka.ebuilt.net> References: <3906C56A7BD1F54593344C05BD1374B1018E234B@SUS-MA1IT01> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.13-current-20010115i In-Reply-To: <3906C56A7BD1F54593344C05BD1374B1018E234B@SUS-MA1IT01>; from gclemm@rational.com on Tue, Apr 10, 2001 at 05:36:25PM -0400 X-AntiVirus: scanned for viruses by AMaViS 0.2.1-pre3 (http://amavis.org/) Subject: Re: [offlist] WebDAV Delete post (Flavors of DELETE) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4757 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: On Tue, Apr 10, 2001 at 05:36:25PM -0400, Clemm, Geoff wrote: > Some folks prefer to use OPTIONS for things that are true > for the whole server, and some folks just > hate live properties, but the live property is fine with me. OPTIONS is for communicating extensions and capabilities, not for identifying the URI of a trash resource. That is simply an external link in hypermedia parlance. > As for the issue of whether to marshal in a request header vs. in a > request body, a new request header eats up part of a global namespace, > whereas an XML request body can use namespaces to keep extensions > from stepping on each others toes, so I stand by my > preference for using the request body for method specific parameters > (of course, for methods like PUT that use the request body for content, > that is not an option). XML namespaces are no more capable of extensions than a global namespace controlled by a standard. The only difference is who gets to define them. HTTP and XML have different design philosophies in that regard, and so far the HTTP one has proven to be right (XML namespaces are 100% extensible, but have almost zero interoperability success). I'm not sure yet which type of extensibility is better for a protocol. I only know that needing to parse XML in order to determine request semantics is totally and irretrievably bad design. Cheers, Roy T. Fielding, Chief Scientist, eBuilt, Inc. 2652 McGaw Avenue Irvine, CA 92614-5840 fax:+1.949.609.0001 (fielding@ebuilt.com) From w3c-dist-auth-request@w3.org Tue Apr 10 18:50:58 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA27566 for ; Tue, 10 Apr 2001 18:50:51 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAA23486; Tue, 10 Apr 2001 18:44:12 -0400 (EDT) Resent-Date: Tue, 10 Apr 2001 18:44:12 -0400 (EDT) Resent-Message-Id: <200104102244.SAA23486@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id SAA23463 for ; Tue, 10 Apr 2001 18:44:07 -0400 (EDT) Received: from sus-ma1it00.rational.com (ext-37140.rational.com [192.229.37.140]) by tux.w3.org (8.9.3/8.9.3) with SMTP id SAA18538 for ; Tue, 10 Apr 2001 18:44:07 -0400 Received: from 192.168.215.70 by sus-ma1it00.rational.com (InterScan E-Mail VirusWall NT); Tue, 10 Apr 2001 18:45:09 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Tue, 10 Apr 2001 18:45:09 -0400 Message-ID: <3906C56A7BD1F54593344C05BD1374B1018E234F@SUS-MA1IT01> From: "Clemm, Geoff" To: WebDAV Working Group Date: Tue, 10 Apr 2001 18:45:11 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: RE: [offlist] WebDAV Delete post (Flavors of DELETE) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4758 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Well, since we've got Roy's attention (:-) ... If your server does DELETE's to a trash collection (instead of making it totally disappear), wouldn't that fall under the "capabilities" of your server? And if your server maintains that trash collection at a fixed location (for all resources on that server), why would that be unreasonable/bad information to include in the OPTIONS response (I am assuming that we give OPTIONS a request body in which the client indicates what OPTIONS information it is interested in). To emphasize, I don't advocate this approach (i.e. live properties are fine with me), but the topic has been raised in several threads, and I haven't seen a convincing argument either way. (Note: There has been no lack of definitive statements ... but unfortunately the definitive statements from different people have not agreed with each other :-). On the separate topic of header vs. method body, although it is clear that method semantics of concern to a proxy should be in headers (so that the proxy doesn't need to process the body), could you motivate why the detailed request semantics needed only by the resource implementation shouldn't appear as XML (WebDAV seems to work reasonably well with request bodies like PROPPATCH in XML). Is it important for a proxy to know whether or not a DELETE'd resource has been copied/moved to a trash collection? Or is it some other argument against XML (XML parsers are pretty trivial). Cheers, Geoff From: Roy T. Fielding [mailto:fielding@ebuilt.com] On Tue, Apr 10, 2001 at 05:36:25PM -0400, Clemm, Geoff wrote: > Some folks prefer to use OPTIONS for things that are true > for the whole server, and some folks just > hate live properties, but the live property is fine with me. OPTIONS is for communicating extensions and capabilities, not for identifying the URI of a trash resource. That is simply an external link in hypermedia parlance. > As for the issue of whether to marshal in a request header vs. in a > request body, a new request header eats up part of a global namespace, > whereas an XML request body can use namespaces to keep extensions > from stepping on each others toes, so I stand by my > preference for using the request body for method specific parameters > (of course, for methods like PUT that use the request body for content, > that is not an option). XML namespaces are no more capable of extensions than a global namespace controlled by a standard. The only difference is who gets to define them. HTTP and XML have different design philosophies in that regard, and so far the HTTP one has proven to be right (XML namespaces are 100% extensible, but have almost zero interoperability success). I'm not sure yet which type of extensibility is better for a protocol. I only know that needing to parse XML in order to determine request semantics is totally and irretrievably bad design. From w3c-dist-auth-request@w3.org Tue Apr 10 19:00:56 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA27665 for ; Tue, 10 Apr 2001 19:00:53 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAA23940; Tue, 10 Apr 2001 18:54:51 -0400 (EDT) Resent-Date: Tue, 10 Apr 2001 18:54:51 -0400 (EDT) Resent-Message-Id: <200104102254.SAA23940@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id SAA23920 for ; Tue, 10 Apr 2001 18:54:48 -0400 (EDT) Received: from smtpgw04.chubb.com (smtpgw04.chubb.com [12.14.122.21]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id SAA19383 for ; Tue, 10 Apr 2001 18:54:47 -0400 Received: from chubb.com (chubb.com [167.156.31.100]) by smtpgw04.chubb.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f3AMi7Z21751; Tue, 10 Apr 2001 18:44:08 -0400 Received: from gmg600x.celsus.net ([167.156.240.106]) by chubb.com (CHUBB/chubb) with ESMTP id SAA01608; Tue, 10 Apr 2001 18:53:32 -0400 (EDT) Message-Id: <5.0.0.25.2.20010410180455.0444e8a0@pop3.norton.antivirus> X-Sender: ggershon/pop.snet.net@pop3.norton.antivirus X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Tue, 10 Apr 2001 18:52:47 -0400 To: "Clemm, Geoff" , WebDAV Working Group From: Gary M Gershon In-Reply-To: <3906C56A7BD1F54593344C05BD1374B1018E234B@SUS-MA1IT01> Mime-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [offlist] WebDAV Delete post (Flavors of DELETE) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4759 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: quoted-printable I'm not as thrilled with the live property.  This assumes there is an actual folder, which is true fin some systems, but I'm not sure if that would be universal (e.g. Windows has a Recycle Bin icon on my desktop, but I don't have any folders with *recycle* in their name on my system).  I suppose it could be implemented as a virtual folder, where the server mimics the desired behavior of deleting.

It also requires a second operation to be performed to delete the copy from trash.  This isn't clean from a unit-of-work standpoint, particularly since the successful completion of the original delete would seem to cause the live property to vanish, which would thus make subsequently re-issuing the delete-from-trash difficult, if not impossible.  Also, when a document of a specific name is repeatedly deleted in some systems, the system adds a unique suffix to the name in trash so the file names remain unique in that folder,  It may not be possible to construct what name was assigned in trash after the original live property is gone.  All this is a real possibility if there is a communications or other client problem between the two deletes and one restarts the client.  I might see that the original file is gone, I know their is a copy now in trash, I don't know its name, and it is quite possible that I don't have permission to  just browse this shared folder looking for stuff...

The other DELETE option suggested in the original post, dealt with allowing the client to specify overwriting the file with binary information to prevent inadvertent or intentional viewing of the file.  This, of course, depends on the server having the capability to do this.  This really does need to be specified on the original request (by those who are a bit paranoid -- or those who are doing classified government work...).

I think a header is a better choice than an XML body because there are implicit deletes in doing other WebDAV requests.  A PUT deletes the original, unless some type of versioning is implemented, and (as Geoff reminds us) the body content of a PUT is already spoken for.  A MOVE may require copying to a new physical volume (such as with  a mountable file system), and deleting the original.

I like the idea of having something in the OPTIONS response to indicate the delete processing and security capabilities of the server.  The client would then know what can or needs to be sent, and, in a more extreme scenario, might decide not to store documents on this server, or to warn the human user of the implied consequences of doing so.  This would also be more honest if the administrative policy of the server is to inhibit users from deleting items from trash. (Or keeping copies somewhere despite deleting them.)  The user would know not to store his or her plans for a new .com business on this repository... or the original formula for CocaCola :)

Gary

At 05:36 PM 4/10/2001 -0400, Clemm, Geoff wrote:
Some folks prefer to use OPTIONS for things that are true
for the whole server, and some folks just
hate live properties, but the live property is fine with me.

As for the issue of whether to marshal in a request header vs. in a
request body, a new request header eats up part of a global namespace,
whereas an XML request body can use namespaces to keep extensions
from stepping on each others toes, so I stand by my
preference for using the request body for method specific=20 parameters
(of course, for methods like PUT that use the request body for content,
that is not an option).

Cheers,
Geoff

-----Original Message-----
From: Roy T. Fielding [mailto:fielding@ebuilt.com]
Sent: Tuesday, April 10, 2001 5:11 PM
To: Clemm, Geoff
Cc: WebDAV Working Group
Subject: Re: [offlist] WebDAV Delete post (Flavors of DELETE)


On Tue, Apr 10, 2001 at 10:41:30AM -0400, Clemm, Geoff wrote:
> On the issue of trash folders:
>
> HTTP headers are a poor way of marshalling method specific
> information.  A header exists in a global namespace, and should be
> reserved for things that proxies need to look at.
>
> So if you want to extend DELETE, I would suggest following the
> standard WebDAV approach and add an XML request body to the DELETE
> method.

Huh?  You've got that entirely backwards.  HTTP header fields are intended
to be method-specific.  The only part of an HTTP message that is not
supposed to be method-specific is the message payload (entity-headers
and entity-body).  I thought I made that perfectly clear in the HTTP spec,
but it probably got lost in the noise.

> In the specific case of trash folders, I would suggest a different
> approach.  In particular, I would add an OPTIONS parameter that would
> let you find out "where is the trash collection for this resource".
> Then the client could either issue a DELETE or a MOVE to that trash
> collection, depending on what the user wants to do.

Either the client knows where the trash is or it doesn't deserve to know
where the trash might be -- it is just another collection on the server.
Just make it an optional link in the metadata (a live property).

....Roy

----------------------------------------------------------------------------= ----------------------
Gary M. Gershon  -- gershon@celsus.net  -- 203-431-9328 From w3c-dist-auth-request@w3.org Tue Apr 10 20:49:17 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA29037 for ; Tue, 10 Apr 2001 20:49:15 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id UAA00742; Tue, 10 Apr 2001 20:42:46 -0400 (EDT) Resent-Date: Tue, 10 Apr 2001 20:42:46 -0400 (EDT) Resent-Message-Id: <200104110042.UAA00742@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id UAA00709 for ; Tue, 10 Apr 2001 20:42:41 -0400 (EDT) Received: from cats.ucsc.edu (rumpleteazer.ucsc.edu [128.114.129.45]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id UAA29979 for ; Tue, 10 Apr 2001 20:42:41 -0400 Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177]) by cats.ucsc.edu (8.9.3/8.8.4.cats-athena) with SMTP id RAA01792 for ; Tue, 10 Apr 2001 17:42:46 -0700 (PDT) From: "Jim Whitehead" To: "WebDAV WG" Date: Tue, 10 Apr 2001 17:41:14 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Subject: Four-part process for moving to Draft Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4760 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit The process of moving RFC 2518 to Draft Standard status has two main goals: * Revise RFC 2518, the WebDAV Distributed Authoring Protocol, to fix or address known functional or interoperability problems with the protocol. Protocol features which are not found in at least two implementations must be removed from the document. * Document the implementation and interoperability of protocol features, to show that at least two implementations, from independent code bases, exist for each feature. Accomplishing these goals can be subdivided into the following four actions: 1. Resolving existing Issues List items on the mailing list. 2. Hold a face-to-face interoperability event (b*ke-off). 3. Develop an online form to gather RFC 2518 implementation experience data. 4. Create a farm of existing server implementations for ongoing interoperability testing. What is involved in each item? 1. Resolving existing Issues List items on the mailing list. At present, there is a fairly significant list of known issues with the WebDAV protocol. These are items that have been reported to the mailing list over the past 2 1/2 years. This issues list can be found at: http://www.ics.uci.edu/pub/ietf/webdav/protocol/issues.html Basically, for every item marked "Open", there needs to be a resolution of the issue. Item resolutions have three parts: * Description of the issue A description of the problem, independent of any proposed solution to the problem. The existing description of each issue is a good starting point for this. * Description of the solution to the issue A concise description of how to address the issue, independent of any text describing why this is a good way to solve the problem. * Description of advantages and disadvantages of the solution. Many solutions to issues will involve design tradeoffs of one form or another. Recording these tradeoffs will be important, so future implementors of the protocol will understand the rationale for the decisions taken (and why certain solutions were not adopted). As Chair, I will be driving this discussion forward by selecting a small number of issues (2-3), and raising them for discussion by the mailing list. My hope is these issues can be resolved within a week, thus clearing the deck for consideration of new issues the following week. This process will allow the existing issues to be steadily resolved over the next few months. 2. Hold a face-to-face interoperability event (b*ke-off). It is common practice for IETF protocol development communities to actually meet in person, and hold a face-to-face interoperability event. These typically last 2-3 days, and are attended by engineers who understand the code base (and typically have the code and development tools with them). During the event, various client/server interactions are tested, interoperability issues are identified, and in some cases fixed right on the spot. Interoperability events tend to be very high-value activities, providing a very cost effective way to identify and remedy interoperability issues. At present, I'm targeting an interoperability event in the mid-June timeframe, to be held in the San Francisco Bay Area (Silicon Valley or Santa Cruz). Protocol issues identified during the interoperability event will be added to the RFC 2518 issues list, and fed into the protocol revision process. 3. Develop an online form to gather RFC 2518 implementation experience data. When the HTTP 1.1 specification went to Draft standard, they employed a Web-based form to gather information from implementors concerning what HTTP features they supported. The form they used is still online, and can be viewed at: http://www.agranat.com:1998/ The results from this activity are listed here: http://www.w3.org/Protocols/HTTP/Forum/Reports/ The online form is an effective way of gathering implementation experience. For the HTTP 1.1 effort, it was used in lieu of holding an interoperability event. However, Larry Masinter, the Chair of the HTTP Working Group recommends doing both, and I agree. The online form only reports implementation experience, and does not give detailed information on interoperability. It is well known that implementing a specification to the letter does not necessarily guarantee interoperability. As well, the granularity of information gathered in the online form is fairly large-grain -- it is possible to explore issues in greater depth during an interoperability event. Finally, two parties can claim to implement a feature while still carrying different mental models of the operation of the feature. The divergence between models will not be exposed by the form, by may be exposed during interoperability testing. Bottom line, both the online form, and the interoperability event have value. Over the next few weeks, I will be implementing a form listing features in the WebDAV protocol, patterned after the HTTP one, and ask for implementors to fill out the form. Data from this effort will form a significant part of the case I will make to the IESG concerning the state of implementation of features in the protocol. 4. Create a farm of existing server implementations for ongoing interoperability testing. One of the drawbacks of the interoperability event, and the online form, is they only capture information at a single point in time. However, new clients and servers are being developed all the time. It is extremely useful for client developers to have multiple WebDAV servers that can be used for interoperability testing during client development. This allows interoperability problems to be identified and fixed before the client software is publically released. At present, though there are 22 independent server code bases, only a small number of these (Apache, Xythos Storage Server, CyberTeams, to name few) provide servers where it is easy to request an account for interoperability testing purposes. It stands to reason that if you cannot test a particular client/server pair, the possibility exists there might be some unexpected interactions between them. The remedy is to make it as easy as possible to test a client against as many servers as possible. Over the next few months, I will work to develop a more complete set of WebDAV servers that are available to client developers for ongoing interoperability testing. One factor preventing server implementations being publically available is the need to run them on a machine outside a corporate firewall. At many organizations, this is a time consuming and difficult action to pull off, and so it doesn't happen. Since I am at a university, it is relatively easy to place a machine on the open Internet. The support staff in the School of Engineering at UC Santa Cruz are quite willing to let me place machines in our machine room, and have them running on the open Internet. However, I do not have the funding necessary to purchase multiple machines just for WebDAV interoperability testing. As a result, if you have a server implementation, and wish to have your server implementation available for interoperability testing, please consider donating or lending a computer (and server software) for this purpose. This is really enlightened altruism: by making the server available for interoperability testing, more client implementations will test against your server, and hence will work against the server. This can only improve the value of the server. ------- Whew! We have a lot of work ahead of us. But, in the end, the result will be a much stronger specification, and a much stronger standard, creating a solid foundation for existing, and future applications. - Jim Whitehead Chair, WebDAV WG From w3c-dist-auth-request@w3.org Tue Apr 10 21:06:52 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA29540 for ; Tue, 10 Apr 2001 21:06:52 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id VAA02649; Tue, 10 Apr 2001 21:00:06 -0400 (EDT) Resent-Date: Tue, 10 Apr 2001 21:00:06 -0400 (EDT) Resent-Message-Id: <200104110100.VAA02649@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id VAA02625 for ; Tue, 10 Apr 2001 21:00:02 -0400 (EDT) Received: from cats.ucsc.edu (rumpleteazer.ucsc.edu [128.114.129.45]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id VAA31341 for ; Tue, 10 Apr 2001 21:00:02 -0400 Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177]) by cats.ucsc.edu (8.9.3/8.8.4.cats-athena) with SMTP id SAA04482 for ; Tue, 10 Apr 2001 18:00:08 -0700 (PDT) From: "Jim Whitehead" To: "WebDAV WG" Date: Tue, 10 Apr 2001 17:58:36 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Subject: Issue: WRITE_DAV_PROP Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4762 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: X-MIME-Autoconverted: from 8bit to quoted-printable by www19.w3.org id VAA02649 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id VAA29540 Issue: WRITE_DAV_PROP Description: Which properties specified in the WebDAV specification (i.e., “DAV:” properties) may be written by the client? For example, can the client write to DAV:getcontenttype? Jim Davis raised this issue: http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0204.html See also: http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0205.html http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0289.html http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0292.html - Jim From w3c-dist-auth-request@w3.org Tue Apr 10 21:26:17 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA29738 for ; Tue, 10 Apr 2001 21:26:17 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id UAA02323; Tue, 10 Apr 2001 20:54:59 -0400 (EDT) Resent-Date: Tue, 10 Apr 2001 20:54:59 -0400 (EDT) Resent-Message-Id: <200104110054.UAA02323@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id UAA02301 for ; Tue, 10 Apr 2001 20:54:56 -0400 (EDT) Received: from cats.ucsc.edu (rumpleteazer.ucsc.edu [128.114.129.45]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id UAA30968 for ; Tue, 10 Apr 2001 20:54:56 -0400 Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177]) by cats.ucsc.edu (8.9.3/8.8.4.cats-athena) with SMTP id RAA03625 for ; Tue, 10 Apr 2001 17:55:02 -0700 (PDT) From: "Jim Whitehead" To: "WebDAV WG" Date: Tue, 10 Apr 2001 17:53:30 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Subject: Issue: PROP_ATTR Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4761 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit As mentioned in a previous post, now is the time to start resolving issues on the RFC 2518 issues list. As fate would have it, the first issue on the list is one that has been contentious in the past. Can we come to consensus on it now? Issue: PROP_ATTR Description: What is a WebDAV server required to do with XML attributes other than xml:lang submitted with a PROPPATCH? This affects how well WebDAV will be able to support RDF, since RDF uses attributes extensively. Greg Stein originally raised this issue: http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0089.html See also: http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0092.html http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0094.html http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0095.html From w3c-dist-auth-request@w3.org Tue Apr 10 21:31:13 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA29839 for ; Tue, 10 Apr 2001 21:31:12 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id VAA03789; Tue, 10 Apr 2001 21:24:51 -0400 (EDT) Resent-Date: Tue, 10 Apr 2001 21:24:51 -0400 (EDT) Resent-Message-Id: <200104110124.VAA03789@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id VAA03769 for ; Tue, 10 Apr 2001 21:24:48 -0400 (EDT) Received: from smtp.interwoven.com (smtp.interwoven.com [63.70.28.39]) by tux.w3.org (8.9.3/8.9.3) with SMTP id VAA00847 for ; Tue, 10 Apr 2001 21:24:48 -0400 Received: (qmail 11274 invoked from network); 11 Apr 2001 01:20:58 -0000 Received: from unknown (HELO MARK) (10.0.41.236) by 10.0.10.66 with SMTP; 11 Apr 2001 01:20:58 -0000 Reply-To: From: "Mark A. Hale" To: "WebDAV WG" Date: Tue, 10 Apr 2001 18:29:00 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: X-AntiVirus: scanned for viruses by Interwoven Virus scanner (http://www.interwoven.com) Subject: RE: Issue: PROP_ATTR Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4763 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Jim: Thanks for getting the issues list started. I believe that WebDAV must permit properties to have attributes. As you've pointed out, RDF and PRISM do use them extensively. A server can reformat the attributes in a subsequent PROPFIND request. Attrbiutes should be persistent. Thanks, Mark > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jim Whitehead > Sent: Tuesday, April 10, 2001 5:54 PM > To: WebDAV WG > Subject: Issue: PROP_ATTR > > > As mentioned in a previous post, now is the time to start resolving issues > on the RFC 2518 issues list. As fate would have it, the first > issue on the > list is one that has been contentious in the past. Can we come to > consensus > on it now? > > Issue: PROP_ATTR > > Description: > > What is a WebDAV server required to do with XML attributes other than > xml:lang submitted with a PROPPATCH? This affects how well WebDAV will be > able to support RDF, since RDF uses attributes extensively. > > Greg Stein originally raised this issue: > > http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0089.html > > See also: > > http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0092.html > http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0094.html > http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0095.html > > > > > From w3c-dist-auth-request@w3.org Tue Apr 10 22:03:36 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA01140 for ; Tue, 10 Apr 2001 22:03:36 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id VAA05173; Tue, 10 Apr 2001 21:57:53 -0400 (EDT) Resent-Date: Tue, 10 Apr 2001 21:57:53 -0400 (EDT) Resent-Message-Id: <200104110157.VAA05173@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id VAA05150 for ; Tue, 10 Apr 2001 21:57:44 -0400 (EDT) Received: from mutley.ebuilt.net (nat.ebuilt.com [209.216.46.200]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id VAA03224 for ; Tue, 10 Apr 2001 21:57:44 -0400 Received: (from root@localhost) by mutley.ebuilt.net (8.11.1/8.11.1) id f3B1vDD09737 for ; Tue, 10 Apr 2001 18:57:13 -0700 Received: from waka.ebuilt.net (IDENT:root@i199.ir.ebuilt.net [10.1.2.199]) by mutley.ebuilt.net (8.11.1/8.11.1) with ESMTP id f3B1vC709656; Tue, 10 Apr 2001 18:57:12 -0700 Received: (from fielding@localhost) by waka.ebuilt.net (8.11.0/8.11.0) id f3B1spw01429; Tue, 10 Apr 2001 18:54:51 -0700 Date: Tue, 10 Apr 2001 18:54:51 -0700 From: "Roy T. Fielding" To: "Clemm, Geoff" Cc: WebDAV Working Group Message-ID: <20010410185451.K968@waka.ebuilt.net> References: <3906C56A7BD1F54593344C05BD1374B1018E234F@SUS-MA1IT01> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.13-current-20010115i In-Reply-To: <3906C56A7BD1F54593344C05BD1374B1018E234F@SUS-MA1IT01>; from gclemm@rational.com on Tue, Apr 10, 2001 at 06:45:11PM -0400 X-AntiVirus: scanned for viruses by AMaViS 0.2.1-pre3 (http://amavis.org/) Subject: Re: [offlist] WebDAV Delete post (Flavors of DELETE) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4764 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: On Tue, Apr 10, 2001 at 06:45:11PM -0400, Clemm, Geoff wrote: > Well, since we've got Roy's attention (:-) ... DAV always has my attention -- I just don't usually have time to argue. Right now I am procrastinating from doing my taxes. > If your server does DELETE's to a trash collection (instead of making > it totally disappear), wouldn't that fall under the "capabilities" > of your server? And if your server maintains that trash collection > at a fixed location (for all resources on that server), why would that > be unreasonable/bad information to include in the OPTIONS response > (I am assuming that we give OPTIONS a request body in which the > client indicates what OPTIONS information it is interested in). The fact that a server runs on a Pentium III 500MHz CPU falls under "capabilities" too, but that doesn't mean that an OPTIONS message should advertize it as such. OPTIONS was intended for info that defines the interoperability mechanisms available at the server/resource. It would have been better defined as a PROPFIND that returned a property consisting of a link to a URL space containing configurable options as resources, but OPTIONS predates properties by a long shot. Alternatively, we could stick a fork in this subject by deprecating PROPFIND and just using OPTIONS for all property retrievals. I bet that would be popular. > To emphasize, I don't advocate this approach (i.e. live properties are > fine with me), but the topic has been raised in several threads, and I > haven't seen a convincing argument either way. (Note: There has been > no lack of definitive statements ... but unfortunately the definitive > statements from different people have not agreed with each other :-). Okay, let's try one. Is it possible for a web server to have multiple trash cans? Yes -- that is a resource implementation issue -- the resource URI hierarchy visible to the client may span hundreds of separate systems/disks/virtual spaces behind the web server interface. So, from an interoperability standpoint, it is pointless to ask the server itself (without using a URL) for a reference to a trash can for all of its resources. Therefore, the relationship between a resource and its potential trash can must be resource-specific. That means it is either a property of the resource or a property of a container of that resource (which, by inference, makes it a property of the resource). So it can be a live property or a dead property. If we make it a dead property, then a client is allowed to set its value, which is something that could be considered a security problem if the server isn't careful about checking the value. OTOH, it might be useful if we wanted to define a distributed trash can protocol, wherein the server POSTs the content to the trash can resource as part of the DELETE. *shrug* Of course, access control on that property becomes an issue, but that would lead me down the rathole of why the set of properties of a resource are themselves resources ... We are then left with the question of what is the most appropriate mechanism for revealing a property of a resource to the client of a webdav server? If the answer is not PROPFIND, then why should any other property be retrievable via PROPFIND? Regarding the trash can itself, it is either accessible to clients as a resource or not accessible at all (because there is no such thing as accessing something other than a resource on the Web). If it is a resource, then what kind of resource is it? I suppose it could be anything, but if we want the trash can to be browsable like any other DAV resource space (as is the case for Macintosh and Windows trash cans), then the only reasonable choice is a collection resource. Otherwise we'd have to define a completely new protocol standard for interoperating with trash cans, for which I doubt we can find any volunteers. So, the right protocol is to allow each resource to have an optional property that is a link to a collection resource that can be operated upon as a trash can, with appropriate access control. > On the separate topic of header vs. method body, although it is > clear that method semantics of concern to a proxy should be in > headers (so that the proxy doesn't need to process the body), > could you motivate why the detailed request semantics needed only > by the resource implementation shouldn't appear as XML (WebDAV > seems to work reasonably well with request bodies like PROPPATCH > in XML). Is it important for a proxy to know whether or not a > DELETE'd resource has been copied/moved to a trash collection? > Or is it some other argument against XML (XML parsers are pretty > trivial). Application-level semantics need to be visible for any intermediary, not just proxies. How does the client know that it is talking to the origin server? For this specific request semantic, it probably doesn't matter because the effect on intermediaries is already covered by the method name. However, what you stated earlier was a general principle, which caught my eye because your description contradicts one of the design principles of HTTP that I described in my dissertation. As you probably noted, I get a little annoyed whenever webdav contradicts my dissertation, regardless of whether or not it is the right solution. ;-) Back to the original question, I don't see any reason to allow the client to choose whether or not the DELETE goes to the trash can. A trash can is, after all, just a poor man's form of version control. I think it should be set as part of the configuration of a containing collection resource, either by the server internals or by linking to a resource on the server that knows how to be a trash can. Cheers, Roy T. Fielding, Chief Scientist, eBuilt, Inc. 2652 McGaw Avenue Irvine, CA 92614-5840 fax:+1.949.609.0001 (fielding@ebuilt.com) From w3c-dist-auth-request@w3.org Tue Apr 10 22:28:28 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA01347 for ; Tue, 10 Apr 2001 22:28:27 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id WAA06359; Tue, 10 Apr 2001 22:22:24 -0400 (EDT) Resent-Date: Tue, 10 Apr 2001 22:22:24 -0400 (EDT) Resent-Message-Id: <200104110222.WAA06359@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id WAA06320 for ; Tue, 10 Apr 2001 22:22:16 -0400 (EDT) Received: from mta6.snfc21.pbi.net (mta6.snfc21.pbi.net [206.13.28.240]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id WAA04976 for ; Tue, 10 Apr 2001 22:22:12 -0400 Disposition-notification-to: Bruce Williams Received: from midnightwork ([64.171.77.8]) by mta6.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with SMTP id <0GBL003KVVWP8Z@mta6.snfc21.pbi.net> for w3c-dist-auth@w3.org; Tue, 10 Apr 2001 19:22:01 -0700 (PDT) Date: Tue, 10 Apr 2001 19:20:43 -0700 From: Bruce Williams To: WebDAV Working Group Reply-to: Bruce Williams Message-id: <007a01c0c22e$09e72000$a302fea9@midnightwork> MIME-version: 1.0 X-Mailer: Microsoft Outlook Express 5.50.4522.1200 Content-type: text/plain; charset="iso-8859-1" Content-transfer-encoding: 7bit X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 References: <3906C56A7BD1F54593344C05BD1374B1018E234F@SUS-MA1IT01> <20010410185451.K968@waka.ebuilt.net> X-Priority: 3 Subject: Re: [offlist] WebDAV Delete post (Flavors of DELETE) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4765 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Point! Good security practice is to "firewall" and not reveal too much. A subsystem that "tells all" is frowned upon by at least some admins. Good practice in standards development is to find the "least" that has to be defined. Why does this can of worms have to be opened? What is the minimal functionality needed and why? Just asking. :-) If we are VERY clear on what we have to do, we will find a way to do it, I guess. Otherwise we will "what if" forever. Bruce Williams brucewms@pacbell.net - ---------------------------------------------------------------------- - -- Hic locus est ubi mors gaudet succurrere vitae - ----- Original Message ----- From: "Roy T. Fielding" To: "Clemm, Geoff" Cc: "WebDAV Working Group" Sent: Tuesday, April 10, 2001 6:54 PM Subject: Re: [offlist] WebDAV Delete post (Flavors of DELETE) > On Tue, Apr 10, 2001 at 06:45:11PM -0400, Clemm, Geoff wrote: > > Well, since we've got Roy's attention (:-) ... > > DAV always has my attention -- I just don't usually have time to > argue. Right now I am procrastinating from doing my taxes. > > > If your server does DELETE's to a trash collection (instead of > > making it totally disappear), wouldn't that fall under the > > "capabilities" of your server? And if your server maintains that > > trash collection at a fixed location (for all resources on that > > server), why would that be unreasonable/bad information to > > include in the OPTIONS response (I am assuming that we give > > OPTIONS a request body in which the client indicates what OPTIONS > > information it is interested in). > > The fact that a server runs on a Pentium III 500MHz CPU falls under > "capabilities" too, but that doesn't mean that an OPTIONS message > should advertize it as such. OPTIONS was intended for info that > defines the interoperability mechanisms available at the > server/resource. > It would have been better defined as a PROPFIND that returned a > property consisting of a link to a URL space containing > configurable options as resources, but OPTIONS predates properties > by a long shot. Alternatively, we could stick a fork in this > subject by deprecating PROPFIND and just using OPTIONS for all > property retrievals. I bet that would be popular. > > > To emphasize, I don't advocate this approach (i.e. live > > properties are fine with me), but the topic has been raised in > > several threads, and I haven't seen a convincing argument either > > way. (Note: There has been no lack of definitive statements ... > > but unfortunately the definitive statements from different people > > have not agreed with each other :-). > > Okay, let's try one. Is it possible for a web server to have > multiple trash cans? Yes -- that is a resource implementation > issue -- the resource URI hierarchy visible to the client may span > hundreds of > separate systems/disks/virtual spaces behind the web server > interface. So, from an interoperability standpoint, it is pointless > to ask the server itself (without using a URL) for a reference to a > trash can for all of its resources. Therefore, the relationship > between a resource and its potential trash can must be > resource-specific. That means it is either a property of the > resource or a property of a container of that resource (which, by > inference, makes it a property of the resource). > > So it can be a live property or a dead property. If we make it a > dead property, then a client is allowed to set its value, which is > something that could be considered a security problem if the server > isn't careful about checking the value. OTOH, it might be useful > if we wanted to define a distributed trash can protocol, wherein > the server POSTs the content to the trash can resource as part of > the DELETE. *shrug* > Of course, access control on that property becomes an issue, but > that would lead me down the rathole of why the set of properties of > a > resource are themselves resources ... > > We are then left with the question of what is the most appropriate > mechanism for revealing a property of a resource to the client of a > webdav server? If the answer is not PROPFIND, then why should any > other property be retrievable via PROPFIND? > > Regarding the trash can itself, it is either accessible to clients > as a resource or not accessible at all (because there is no such > thing as accessing something other than a resource on the Web). If > it is a resource, then what kind of resource is it? I suppose it > could be anything, but if we want the trash can to be browsable > like any other DAV resource space (as is the case for Macintosh and > Windows trash cans), then the only reasonable choice is a > collection resource. Otherwise we'd have to define a completely > new protocol standard for interoperating with trash cans, for which > I doubt we can find any volunteers. > > So, the right protocol is to allow each resource to have an > optional property that is a link to a collection resource that can > be operated upon as a trash can, with appropriate access control. > > > On the separate topic of header vs. method body, although it is > > clear that method semantics of concern to a proxy should be in > > headers (so that the proxy doesn't need to process the body), > > could you motivate why the detailed request semantics needed only > > by the resource implementation shouldn't appear as XML (WebDAV > > seems to work reasonably well with request bodies like PROPPATCH > > in XML). Is it important for a proxy to know whether or not a > > DELETE'd resource has been copied/moved to a trash collection? > > Or is it some other argument against XML (XML parsers are pretty > > trivial). > > Application-level semantics need to be visible for any > intermediary, not just proxies. How does the client know that it > is talking to > the origin server? For this specific request semantic, it probably > doesn't matter because the effect on intermediaries is already > covered by the method name. However, what you stated earlier was a > general principle, which caught my eye because your description > contradicts one of the design principles of HTTP that I described > in my dissertation. > > As you probably noted, I get a little annoyed whenever webdav > contradicts my dissertation, regardless of whether or not it is the > right solution. ;-) > > Back to the original question, I don't see any reason to allow the > client to choose whether or not the DELETE goes to the trash can. > A trash can is, > after all, just a poor man's form of version control. I think it > should be > set as part of the configuration of a containing collection > resource, either by the server internals or by linking to a > resource on the server that knows how to be a trash can. > > Cheers, > > Roy T. Fielding, Chief Scientist, eBuilt, Inc. > 2652 McGaw Avenue > Irvine, CA 92614-5840 fax:+1.949.609.0001 > (fielding@ebuilt.com) > -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 6.5.3 for non-commercial use iQA/AwUBOtO/eXuDB3/hEB6MEQKFVgCg16VZq1mAjQkaZlRmqVsO+Z9a9XUAniDV xEQXkvPscz8Pw79CescwFIe0 =vHDN -----END PGP SIGNATURE----- From w3c-dist-auth-request@w3.org Wed Apr 11 02:07:04 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA17931 for ; Wed, 11 Apr 2001 02:07:03 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id CAA10879; Wed, 11 Apr 2001 02:04:43 -0400 (EDT) Resent-Date: Wed, 11 Apr 2001 02:04:43 -0400 (EDT) Resent-Message-Id: <200104110604.CAA10879@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id CAA10859 for ; Wed, 11 Apr 2001 02:04:39 -0400 (EDT) Received: from inet-mail3.oracle.com (inet-mail3.oracle.com [148.87.2.203]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id CAA20492 for ; Wed, 11 Apr 2001 02:04:39 -0400 Received: from gmgw02.oraclecorp.com (gmgw02.us.oracle.com [130.35.60.248]) by inet-mail3.oracle.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f3B61d509285 for ; Tue, 10 Apr 2001 23:01:39 -0700 (PDT) Received: from esedlarpc (esedlar-pc-xdsl.us.oracle.com [152.68.17.154]) by gmgw02.oraclecorp.com (Switch-2.1.1/Switch-2.1.0) with SMTP id f3B648x21124 for ; Tue, 10 Apr 2001 23:04:08 -0700 (PDT) From: "Eric Sedlar" To: "WebDAV WG" Date: Tue, 10 Apr 2001 22:58:21 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 In-Reply-To: Importance: Normal Subject: RE: Issue: PROP_ATTR Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4766 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit I agree. There is no reason not to persist attributes. > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Mark A. Hale > Sent: Tuesday, April 10, 2001 6:29 PM > To: WebDAV WG > Subject: RE: Issue: PROP_ATTR > > > Jim: Thanks for getting the issues list started. > > I believe that WebDAV must permit properties to have attributes. > As you've > pointed out, RDF and PRISM do use them extensively. A server can reformat > the attributes in a subsequent PROPFIND request. Attrbiutes should be > persistent. > > Thanks, > > Mark > > > > > > -----Original Message----- > > From: w3c-dist-auth-request@w3.org > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jim Whitehead > > Sent: Tuesday, April 10, 2001 5:54 PM > > To: WebDAV WG > > Subject: Issue: PROP_ATTR > > > > > > As mentioned in a previous post, now is the time to start > resolving issues > > on the RFC 2518 issues list. As fate would have it, the first > > issue on the > > list is one that has been contentious in the past. Can we come to > > consensus > > on it now? > > > > Issue: PROP_ATTR > > > > Description: > > > > What is a WebDAV server required to do with XML attributes other than > > xml:lang submitted with a PROPPATCH? This affects how well > WebDAV will be > > able to support RDF, since RDF uses attributes extensively. > > > > Greg Stein originally raised this issue: > > > > http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0089.html > > > > See also: > > > > http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0092.html > > http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0094.html > > http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0095.html > > > > > > > > > > > > From w3c-dist-auth-request@w3.org Wed Apr 11 03:49:29 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA18562 for ; Wed, 11 Apr 2001 03:49:29 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id DAA16496; Wed, 11 Apr 2001 03:46:16 -0400 (EDT) Resent-Date: Wed, 11 Apr 2001 03:46:16 -0400 (EDT) Resent-Message-Id: <200104110746.DAA16496@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id DAA16476 for ; Wed, 11 Apr 2001 03:46:11 -0400 (EDT) Received: from mail.gmx.net (pop.gmx.net [194.221.183.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id DAA27554 for ; Wed, 11 Apr 2001 03:46:10 -0400 Received: (qmail 25476 invoked by uid 0); 11 Apr 2001 07:45:38 -0000 Received: from p3ee2462a.dip.t-dialin.net (HELO lisa) (62.226.70.42) by mail.gmx.net (mp025-rz3) with SMTP; 11 Apr 2001 07:45:38 -0000 From: "Julian F. Reschke" To: , "WebDAV WG" Date: Wed, 11 Apr 2001 09:45:33 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000 Subject: RE: Issue: PROP_ATTR Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4767 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit I agree here. Maybe the way property values are round-tripped needs to be defined in terms of the XML infoset [1] or the Canonical XML rec [2]. If a server supports "arbitrary" content of properties (like child elements with attribute, mixed content and so on), it will have to store the content in some XML friendly format anyway. Instead of storing the "value" of the property (all contained elements?), it can instead store the element (with all it's attributes and childs), thus preserving all attribute information. [1] [2] > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Mark A. Hale > Sent: Wednesday, April 11, 2001 3:29 AM > To: WebDAV WG > Subject: RE: Issue: PROP_ATTR > > > Jim: Thanks for getting the issues list started. > > I believe that WebDAV must permit properties to have attributes. > As you've > pointed out, RDF and PRISM do use them extensively. A server can reformat > the attributes in a subsequent PROPFIND request. Attrbiutes should be > persistent. > > Thanks, > > Mark > > > > > > -----Original Message----- > > From: w3c-dist-auth-request@w3.org > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jim Whitehead > > Sent: Tuesday, April 10, 2001 5:54 PM > > To: WebDAV WG > > Subject: Issue: PROP_ATTR > > > > > > As mentioned in a previous post, now is the time to start > resolving issues > > on the RFC 2518 issues list. As fate would have it, the first > > issue on the > > list is one that has been contentious in the past. Can we come to > > consensus > > on it now? > > > > Issue: PROP_ATTR > > > > Description: > > > > What is a WebDAV server required to do with XML attributes other than > > xml:lang submitted with a PROPPATCH? This affects how well > WebDAV will be > > able to support RDF, since RDF uses attributes extensively. > > > > Greg Stein originally raised this issue: > > > > http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0089.html > > > > See also: > > > > http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0092.html > > http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0094.html > > http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0095.html > > > > > > > > > > > From w3c-dist-auth-request@w3.org Wed Apr 11 04:11:12 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA18681 for ; Wed, 11 Apr 2001 04:11:12 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id EAA17548; Wed, 11 Apr 2001 04:05:01 -0400 (EDT) Resent-Date: Wed, 11 Apr 2001 04:05:01 -0400 (EDT) Resent-Message-Id: <200104110805.EAA17548@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id EAA17519 for ; Wed, 11 Apr 2001 04:04:57 -0400 (EDT) Received: from kurgan.lyra.org (test.webdav.org [198.144.203.199]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id EAA29110 for ; Wed, 11 Apr 2001 04:04:56 -0400 Received: (from gstein@localhost) by kurgan.lyra.org (8.9.3/8.9.3) id BAA30431 for w3c-dist-auth@w3.org; Wed, 11 Apr 2001 01:06:29 -0700 X-Authentication-Warning: kurgan.lyra.org: gstein set sender to gstein@lyra.org using -f Date: Wed, 11 Apr 2001 01:06:29 -0700 From: Greg Stein To: WebDAV WG Message-ID: <20010411010628.G29269@lyra.org> Mail-Followup-To: WebDAV WG References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from Eric.Sedlar@oracle.com on Tue, Apr 10, 2001 at 10:58:21PM -0700 X-URL: http://www.lyra.org/greg/ Subject: Re: Issue: PROP_ATTR Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4768 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: The question isn't about attributes in general, it is about *which* attributes. Consider the following: thevalue I believe everybody would agree that attr2 gets stored. The real question is about attr1. I see that attribute as part of the element that *names* a property, but it isn't part of the property *value*. IMO, PROP_ATTR is about defining the boundary between property naming, and a property's value. Cheers, -g On Tue, Apr 10, 2001 at 10:58:21PM -0700, Eric Sedlar wrote: > I agree. There is no reason not to persist attributes. > > > -----Original Message----- > > From: w3c-dist-auth-request@w3.org > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Mark A. Hale > > Sent: Tuesday, April 10, 2001 6:29 PM > > To: WebDAV WG > > Subject: RE: Issue: PROP_ATTR > > > > > > Jim: Thanks for getting the issues list started. > > > > I believe that WebDAV must permit properties to have attributes. > > As you've > > pointed out, RDF and PRISM do use them extensively. A server can reformat > > the attributes in a subsequent PROPFIND request. Attrbiutes should be > > persistent. > > > > Thanks, > > > > Mark > > > > > > > > > > > -----Original Message----- > > > From: w3c-dist-auth-request@w3.org > > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jim Whitehead > > > Sent: Tuesday, April 10, 2001 5:54 PM > > > To: WebDAV WG > > > Subject: Issue: PROP_ATTR > > > > > > > > > As mentioned in a previous post, now is the time to start > > resolving issues > > > on the RFC 2518 issues list. As fate would have it, the first > > > issue on the > > > list is one that has been contentious in the past. Can we come to > > > consensus > > > on it now? > > > > > > Issue: PROP_ATTR > > > > > > Description: > > > > > > What is a WebDAV server required to do with XML attributes other than > > > xml:lang submitted with a PROPPATCH? This affects how well > > WebDAV will be > > > able to support RDF, since RDF uses attributes extensively. > > > > > > Greg Stein originally raised this issue: > > > > > > http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0089.html > > > > > > See also: > > > > > > http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0092.html > > > http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0094.html > > > http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0095.html > > > > > > > > > > > > > > > > > > > -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Wed Apr 11 05:35:54 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA19244 for ; Wed, 11 Apr 2001 05:35:54 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id FAA19380; Wed, 11 Apr 2001 05:30:55 -0400 (EDT) Resent-Date: Wed, 11 Apr 2001 05:30:55 -0400 (EDT) Resent-Message-Id: <200104110930.FAA19380@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id FAA19360 for ; Wed, 11 Apr 2001 05:30:48 -0400 (EDT) Received: from d06lmsgate-2.uk.ibm.com (d06lmsgate-2.uk.ibm.com [195.212.29.2]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id FAA02829 for ; Wed, 11 Apr 2001 05:30:47 -0400 From: Tim_Ellison@uk.ibm.com Received: from d06relay02.portsmouth.uk.ibm.com (d06relay02.portsmouth.uk.ibm.com [9.166.84.148]) by d06lmsgate-2.uk.ibm.com (1.0.0) with ESMTP id KAA165282 for ; Wed, 11 Apr 2001 10:14:56 +0100 Received: from d06mta07.portsmouth.uk.ibm.com (d06mta07_cs0 [9.180.35.5]) by d06relay02.portsmouth.uk.ibm.com (8.8.8m3/NCO v4.95) with SMTP id KAA286178 for ; Wed, 11 Apr 2001 10:30:13 +0100 Received: by d06mta07.portsmouth.uk.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 80256A2B.00343378 ; Wed, 11 Apr 2001 10:30:10 +0100 X-Lotus-FromDomain: IBMGB To: WebDAV WG Message-ID: <80256A2B.003431DC.00@d06mta07.portsmouth.uk.ibm.com> Date: Wed, 11 Apr 2001 10:30:06 +0100 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Re: Issue: PROP_ATTR Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4769 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Greg wrote: > The question isn't about attributes in general, it > is about *which* attributes. Consider the following: > > > > thevalue > > > > > I believe everybody would agree that attr2 gets stored. Yes. > The real question is about attr1. I see that attribute > as part of the element that *names* a property, but it > isn't part of the property *value*. That's an interesting comment -- I'd say that everything from the opening element is the property, and the outermost element is called its 'name'. Everything about the property should be stored, including 'copying down' namespace declarations where required. > IMO, PROP_ATTR is about defining the boundary between > property naming, and a property's value. I don't think there is a boundary per se, the name is extracted from the property. Tim From w3c-dist-auth-request@w3.org Wed Apr 11 07:39:45 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA20992 for ; Wed, 11 Apr 2001 07:39:45 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id HAA26988; Wed, 11 Apr 2001 07:34:20 -0400 (EDT) Resent-Date: Wed, 11 Apr 2001 07:34:20 -0400 (EDT) Resent-Message-Id: <200104111134.HAA26988@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id HAA26931 for ; Wed, 11 Apr 2001 07:34:08 -0400 (EDT) Received: from sus-ma1it00.rational.com (ext-37140.rational.com [192.229.37.140]) by tux.w3.org (8.9.3/8.9.3) with SMTP id HAA12041 for ; Wed, 11 Apr 2001 07:34:08 -0400 Received: from 192.168.215.70 by sus-ma1it00.rational.com (InterScan E-Mail VirusWall NT); Wed, 11 Apr 2001 07:35:09 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Wed, 11 Apr 2001 07:35:09 -0400 Message-ID: <3906C56A7BD1F54593344C05BD1374B102A755AE@SUS-MA1IT01> From: "Clemm, Geoff" To: WebDAV WG Date: Wed, 11 Apr 2001 07:35:12 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Issue: WRITE_DAV_PROP Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4771 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: My vote: - protected (i.e. properties that MUST NOT be modifiable with PROPPATCH) creationdate getcontentlength getetag getlastmodified lockdiscovery supportedlock resourcetype - not protected (i.e. properties that MUST be modifiable by PROPPATCH) displayname getcontentlanguage getcontenttype source My rationale for DAV:resourcetype is that the resourcetype should be used to define the inherent nature of a resource (e.g. collection vs. non-collection), while getcontenttype is definable by the client. Cheers, Geoff -----Original Message----- From: Jim Whitehead [mailto:ejw@cse.ucsc.edu] Sent: Tuesday, April 10, 2001 8:59 PM To: WebDAV WG Subject: Issue: WRITE_DAV_PROP Issue: WRITE_DAV_PROP Description: Which properties specified in the WebDAV specification (i.e., "DAV:" properties) may be written by the client? For example, can the client write to DAV:getcontenttype? Jim Davis raised this issue: http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0204.html See also: http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0205.html http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0289.html http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0292.html - Jim From w3c-dist-auth-request@w3.org Wed Apr 11 07:54:21 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA20994 for ; Wed, 11 Apr 2001 07:39:45 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id HAA26961; Wed, 11 Apr 2001 07:34:12 -0400 (EDT) Resent-Date: Wed, 11 Apr 2001 07:34:12 -0400 (EDT) Resent-Message-Id: <200104111134.HAA26961@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id HAA26929 for ; Wed, 11 Apr 2001 07:34:08 -0400 (EDT) Received: from sus-ma1it00.rational.com (ext-37140.rational.com [192.229.37.140]) by tux.w3.org (8.9.3/8.9.3) with SMTP id HAA12040 for ; Wed, 11 Apr 2001 07:34:08 -0400 Received: from 192.168.215.70 by sus-ma1it00.rational.com (InterScan E-Mail VirusWall NT); Wed, 11 Apr 2001 07:35:09 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Wed, 11 Apr 2001 07:35:09 -0400 Message-ID: <3906C56A7BD1F54593344C05BD1374B102A755AD@SUS-MA1IT01> From: "Clemm, Geoff" To: WebDAV WG Date: Wed, 11 Apr 2001 07:35:11 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Issue: PROP_ATTR Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4770 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: I vote, require that all attributes be kept for dead properties, and that the behavior for live properties be defined in the specification that defines that live property. My rationale is that dead properties pretty much have to be stored as a string, since the server doesn't know how the user might want to use them, while for live properties, there often will be "value preserving" transformations the server can apply, since the server knows what the semantics of that property are. Cheers, Geoff -----Original Message----- From: Jim Whitehead [mailto:ejw@cse.ucsc.edu] Sent: Tuesday, April 10, 2001 8:54 PM To: WebDAV WG Subject: Issue: PROP_ATTR As mentioned in a previous post, now is the time to start resolving issues on the RFC 2518 issues list. As fate would have it, the first issue on the list is one that has been contentious in the past. Can we come to consensus on it now? Issue: PROP_ATTR Description: What is a WebDAV server required to do with XML attributes other than xml:lang submitted with a PROPPATCH? This affects how well WebDAV will be able to support RDF, since RDF uses attributes extensively. Greg Stein originally raised this issue: http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0089.html See also: http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0092.html http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0094.html http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0095.html From w3c-dist-auth-request@w3.org Wed Apr 11 11:02:57 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA25508 for ; Wed, 11 Apr 2001 11:02:57 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id KAA08934; Wed, 11 Apr 2001 10:54:11 -0400 (EDT) Resent-Date: Wed, 11 Apr 2001 10:54:11 -0400 (EDT) Resent-Message-Id: <200104111454.KAA08934@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id KAA08911 for ; Wed, 11 Apr 2001 10:54:06 -0400 (EDT) Received: from bang.ekeeper.com ([38.204.71.240]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id KAA02243 for ; Wed, 11 Apr 2001 10:54:02 -0400 Received: by BANG with Internet Mail Service (5.5.2650.21) id <2NDK7FR4>; Wed, 11 Apr 2001 09:45:45 -0500 Message-ID: From: Douglas Steen To: WebDAV WG Date: Wed, 11 Apr 2001 09:45:36 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Issue: PROP_ATTR Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4772 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: I'll add my vote: "Aye"; enforce attribute persistence on the top-level node for dead properties. I will point out, however, that -- according to my own quick test -- Microsoft's IIS5 DAV implementation does NOT persist attributes at that level. And since they don't allow markup in dead properties, they essentially don't persist attributes at ANY level. Now I know that the onus is on MS to conform to the DAV spec, and not vice-versa, but I'd be curious to know if there were server implementation issues (for MS and others) that might change some minds on this decision. Douglas R. Steen dsteen@eKeeper.Com Drag-and-Drop Web Content Management http://www.eKeeper.com From w3c-dist-auth-request@w3.org Wed Apr 11 13:21:34 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA29305 for ; Wed, 11 Apr 2001 13:21:33 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA19809; Wed, 11 Apr 2001 13:14:24 -0400 (EDT) Resent-Date: Wed, 11 Apr 2001 13:14:24 -0400 (EDT) Resent-Message-Id: <200104111714.NAA19809@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id NAA19786 for ; Wed, 11 Apr 2001 13:14:19 -0400 (EDT) Received: from cats.ucsc.edu (rumpleteazer.ucsc.edu [128.114.129.45]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id NAA18299 for ; Wed, 11 Apr 2001 13:14:20 -0400 Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177]) by cats.ucsc.edu (8.9.3/8.8.4.cats-athena) with SMTP id KAA18609 for ; Wed, 11 Apr 2001 10:14:23 -0700 (PDT) From: "Jim Whitehead" To: "WebDAV WG" Date: Wed, 11 Apr 2001 10:12:53 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: <80256A2B.003431DC.00@d06mta07.portsmouth.uk.ibm.com> Subject: RE: Issue: PROP_ATTR Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4774 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > > The real question is about attr1. I see that attribute > > as part of the element that *names* a property, but it > > isn't part of the property *value*. > > That's an interesting comment -- I'd say that everything from the opening > element is the property, and > the outermost element is called its 'name'. Everything about the property > should be stored, including 'copying down' namespace declarations where > required. Since persisting the attributes is going to be tricky enough, my leaning is to only allow namespace and xml:lang attributes in the property name tag. However, I do agree that servers MUST persistently store XML attribute information found in the value of the property. I don't care how they store it -- the XML is just a marshalling format. I agree with the suggestion to look at the XML Canonicalization Recommendation for ideas on how to specify the round-trip behavior . It's important to support XLink style linking , and this is *very* dependent on the use of attributes. Storage of XLinks in DAV properties is a very natural way to persistently attach link metadata to a resource -- the major roadblock holding this up at present is the fact that, right now, a client does not have a guarantee that attribute information will be persistently stored. I'm glad to see the sentiment of the working group leaning in this direction. - Jim From w3c-dist-auth-request@w3.org Wed Apr 11 13:43:34 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA29643 for ; Wed, 11 Apr 2001 13:43:29 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA20970; Wed, 11 Apr 2001 13:37:41 -0400 (EDT) Resent-Date: Wed, 11 Apr 2001 13:37:41 -0400 (EDT) Resent-Message-Id: <200104111737.NAA20970@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id NAA20950 for ; Wed, 11 Apr 2001 13:37:35 -0400 (EDT) Received: from mail.gmx.net (pop.gmx.net [194.221.183.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id NAA21193 for ; Wed, 11 Apr 2001 13:37:31 -0400 Received: (qmail 3568 invoked by uid 0); 11 Apr 2001 17:37:00 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mp010-rz3) with SMTP; 11 Apr 2001 17:37:00 -0000 From: "Julian F. Reschke" To: "Jim Whitehead" , "WebDAV WG" Date: Wed, 11 Apr 2001 19:36:55 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000 Importance: Normal In-reply-to: Subject: RE: Issue: PROP_ATTR Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4775 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Let's try to approach it this way: A property is a tupel of (namespacename, localname, content). content can be (for instance) empty, a string, or mixed XML content. By definition, it can by anything that belongs to the property element's infoset (including anything below it). If "content" is not a simple string, it needs to be stored in an XML-friendly way. For instance, elements or attributes in the content might use namespace prefixes that have been defined outside that element. For instance: If attributes of the property itself need to be recorded as well, that's extremely easy to do: just instead of storing the "content" of the element, you store the XML serialization of the element including it's attributes and children. Two other notes: a) It needs to be specified which parts of the Infoset are preserved (comments, processing instructions)? I'd say: all of them. b) Microsoft's webfolders already use the old XML data namespace to put data type information into properties, for instance . Julian > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jim Whitehead > Sent: Wednesday, April 11, 2001 7:13 PM > To: WebDAV WG > Subject: RE: Issue: PROP_ATTR > > > > > The real question is about attr1. I see that attribute > > > as part of the element that *names* a property, but it > > > isn't part of the property *value*. > > > > That's an interesting comment -- I'd say that everything from > the opening > > element is the > property, and > > the outermost element is called its 'name'. Everything about > the property > > should be stored, including 'copying down' namespace declarations where > > required. > > Since persisting the attributes is going to be tricky enough, my > leaning is > to only allow namespace and xml:lang attributes in the property name tag. > > However, I do agree that servers MUST persistently store XML attribute > information found in the value of the property. I don't care how > they store > it -- the XML is just a marshalling format. I agree with the suggestion to > look at the XML Canonicalization Recommendation for ideas on how > to specify > the round-trip behavior . > > It's important to support XLink style linking > , and this is > *very* dependent > on the use of attributes. Storage of XLinks in DAV properties is a very > natural way to persistently attach link metadata to a resource -- > the major > roadblock holding this up at present is the fact that, right now, a client > does not have a guarantee that attribute information will be persistently > stored. I'm glad to see the sentiment of the working group > leaning in this > direction. > > - Jim > From w3c-dist-auth-request@w3.org Wed Apr 11 14:22:22 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA00466 for ; Wed, 11 Apr 2001 14:22:21 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA24819; Wed, 11 Apr 2001 14:13:33 -0400 (EDT) Resent-Date: Wed, 11 Apr 2001 14:13:33 -0400 (EDT) Resent-Message-Id: <200104111813.OAA24819@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id OAA24778 for ; Wed, 11 Apr 2001 14:13:28 -0400 (EDT) Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id OAA25398 for ; Wed, 11 Apr 2001 14:13:28 -0400 Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e21.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id OAA43278 for ; Wed, 11 Apr 2001 14:07:50 -0500 Received: from d04nm303.raleigh.ibm.com (d04nm303.raleigh.ibm.com [9.67.228.168]) by southrelay02.raleigh.ibm.com (8.11.1/NCO v4.95) with ESMTP id f3BIDG930478 for ; Wed, 11 Apr 2001 14:13:16 -0400 To: w3c-dist-auth@w3c.org X-Mailer: Lotus Notes Release 5.0.6a January 17, 2001 Message-ID: From: "Jim Amsden" Date: Wed, 11 Apr 2001 14:08:25 -0400 X-MIMETrack: Serialize by Router on D04NM303/04/M/IBM(Release 5.0.6 |December 14, 2000) at 04/11/2001 02:13:15 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: Issue: PROP_ATTR Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4776 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Boy we've got to put our old thinking caps on for these issues! Anyway, as has been pointed out many times in the past, WebDAV does not specify the persistence format or semantics of (at least) dead properties, it only specifies how properties are marshalled on the wire using the protocol. It also does not specify anything but the property name and that its value is some XML element. I think WebDAV has the right to define the PROPPATCH prop, set, multistatus, etc. elements including the property name and any of their associated attributes. But it should not have anything to say about the value of the property other then that it is marshalled in well formed XML. Clients/servers can use whatever they want for attributes or content model for the value element, but must use the attributes (if any) and content specified by the WebDAV protocol for the parent of the value. If there is some conversion from a property value to some underlying storage mechanism, it is the responsibility of the server to figure out what to do with the properties value element, attributes, content model, and all. Servers may have restrictions about what value types the can support, how well they can serialize generic objects in XML, if they use RDF, XML Schema, or DTDs to validate, etc. WebDAV shouldn't need to concern itself with this. Any attributes on DAV defined elements that are not defined in the protocol should be ignored. "Jim Whitehead" To: "WebDAV WG" Sent by: w3c-dist-auth-request@w3.org cc: Subject: Issue: PROP_ATTR 04/10/2001 08:53 PM As mentioned in a previous post, now is the time to start resolving issues on the RFC 2518 issues list. As fate would have it, the first issue on the list is one that has been contentious in the past. Can we come to consensus on it now? Issue: PROP_ATTR Description: What is a WebDAV server required to do with XML attributes other than xml:lang submitted with a PROPPATCH? This affects how well WebDAV will be able to support RDF, since RDF uses attributes extensively. Greg Stein originally raised this issue: http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0089.html See also: http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0092.html http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0094.html http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0095.html From w3c-dist-auth-request@w3.org Wed Apr 11 14:50:18 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA00956 for ; Wed, 11 Apr 2001 14:50:17 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA19190; Wed, 11 Apr 2001 12:54:19 -0400 (EDT) Resent-Date: Wed, 11 Apr 2001 12:54:19 -0400 (EDT) Resent-Message-Id: <200104111654.MAA19190@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id MAA19170 for ; Wed, 11 Apr 2001 12:54:16 -0400 (EDT) Received: from cats.ucsc.edu (rumpleteazer.ucsc.edu [128.114.129.45]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id MAA16309 for ; Wed, 11 Apr 2001 12:54:16 -0400 Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177]) by cats.ucsc.edu (8.9.3/8.8.4.cats-athena) with SMTP id JAA13796 for ; Wed, 11 Apr 2001 09:54:19 -0700 (PDT) From: "Jim Whitehead" To: "WebDAV WG" Date: Wed, 11 Apr 2001 09:52:49 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: <3906C56A7BD1F54593344C05BD1374B102A755AE@SUS-MA1IT01> Subject: RE: Issue: WRITE_DAV_PROP Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4773 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit I agree. - Jim > My vote: > - protected (i.e. properties that MUST NOT be modifiable with PROPPATCH) > creationdate > getcontentlength > getetag > getlastmodified > lockdiscovery > supportedlock > resourcetype > - not protected (i.e. properties that MUST be modifiable by PROPPATCH) > displayname > getcontentlanguage > getcontenttype > source > > My rationale for DAV:resourcetype is that the resourcetype should be used > to define the inherent nature of a resource (e.g. collection vs. > non-collection), while getcontenttype is definable by the client. > > Cheers, > Geoff > From w3c-dist-auth-request@w3.org Wed Apr 11 23:06:06 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA08593 for ; Wed, 11 Apr 2001 23:06:06 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAA13219; Wed, 11 Apr 2001 18:38:26 -0400 (EDT) Resent-Date: Wed, 11 Apr 2001 18:38:26 -0400 (EDT) Resent-Message-Id: <200104112238.SAA13219@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id SAA13199 for ; Wed, 11 Apr 2001 18:38:22 -0400 (EDT) Received: from mail.gmx.net (pop.gmx.net [194.221.183.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id SAA18819 for ; Wed, 11 Apr 2001 18:38:21 -0400 Received: (qmail 29449 invoked by uid 0); 11 Apr 2001 22:38:16 -0000 Received: from p3ee2461a.dip.t-dialin.net (HELO lisa) (62.226.70.26) by mail.gmx.net (mp003-rz3) with SMTP; 11 Apr 2001 22:38:16 -0000 From: "Julian F. Reschke" To: "WebDAV WG" Date: Thu, 12 Apr 2001 00:38:11 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000 In-Reply-To: Importance: Normal Subject: deltaV (draft 14) questions Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4777 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi, a few questions/comments: 1) 2.2.4 DAV:supported-live-property-set (protected) namespace value: an XML namespace This seems to indicate that only properties in the DAV: namespace can be live properties, which I think is wrong. 2) General comment regarding new required properties for all resources Unless I'm making a mistake, this makes propfind/allprop extremly chatty... Regarding "supported-method-set" -- what is it for? If I really would need to know this, couldn't I just do OPTIONS on the resource? Regarding "supported-live-property-set": this *is* very useful, but it seems it could be implemented simpler and more effective by extending propfind/propname to include this information, for instance: >>Request PROPFIND /container/ HTTP/1.1 Host: www.foo.bar Content-Type: text/xml; charset="utf-8" Content-Length: xxxx >>Response HTTP/1.1 207 Multi-Status Content-Type: text/xml; charset="utf-8" Content-Length: xxxx http://www.foo.bar/container/ HTTP/1.1 200 OK Obviously this could also be made propfind/propinfo (new propfind type), and it could also use child elements rather than attributes (...). 3. 2.1.1 Creating a Version-Controlled Resource and 2.3.1 DAV:checked-in (protected) OK, under core versioning, every version is a resource on it's own. Does this mean that a server has to assign a unique URL and make the version resource visible under this URL, for instance for PROPINFO? Or is this optional? Regards, Julian From w3c-dist-auth-request@w3.org Thu Apr 12 00:16:21 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA09517 for ; Thu, 12 Apr 2001 00:16:20 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id AAA27173; Thu, 12 Apr 2001 00:05:50 -0400 (EDT) Resent-Date: Thu, 12 Apr 2001 00:05:50 -0400 (EDT) Resent-Message-Id: <200104120405.AAA27173@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id AAA27149 for ; Thu, 12 Apr 2001 00:05:46 -0400 (EDT) Received: from sus-ma1it00.rational.com (ext-37140.rational.com [192.229.37.140]) by tux.w3.org (8.9.3/8.9.3) with SMTP id AAA12052 for ; Thu, 12 Apr 2001 00:05:42 -0400 Received: from 192.168.215.70 by sus-ma1it00.rational.com (InterScan E-Mail VirusWall NT); Thu, 12 Apr 2001 00:07:09 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Thu, 12 Apr 2001 00:07:09 -0400 Message-ID: <3906C56A7BD1F54593344C05BD1374B102A7593B@SUS-MA1IT01> From: "Clemm, Geoff" To: WebDAV WG Date: Thu, 12 Apr 2001 00:07:07 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: RE: deltaV (draft 14) questions Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4778 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: From: Julian F. Reschke [mailto:julian.reschke@gmx.de] a few questions/comments: 1) 2.2.4 DAV:supported-live-property-set (protected) namespace value: an XML namespace This seems to indicate that only properties in the DAV: namespace can be live properties, which I think is wrong. The NMTOKEN "DAV:" construct just says that if no namespace attribute is specified, it defaults to "DAV:". An explicit namespace attribute overrides this default. 2) General comment regarding new required properties for all resources Unless I'm making a mistake, this makes propfind/allprop extremly chatty... In 14.1, we have added the statement that a server SHOULD NOT return any versioning properties in an allprop PROPFIND. Regarding "supported-method-set" -- what is it for? If I really would need to know this, couldn't I just do OPTIONS on the resource? You often want to populate a "tree explorer" GUI with this information. If it is a property, you can use a Depth PROPFIND to get this information for the whole tree in one request. Otherwise, you would have to do a separate OPTIONS call for every member of the tree. Regarding "supported-live-property-set": this *is* very useful, but it seems it could be implemented simpler and more effective by extending propfind/propname to include this information, for instance: >>Request PROPFIND /container/ HTTP/1.1 Host: www.foo.bar Content-Type: text/xml; charset="utf-8" Content-Length: xxxx >>Response HTTP/1.1 207 Multi-Status Content-Type: text/xml; charset="utf-8" Content-Length: xxxx http://www.foo.bar/container/ HTTP/1.1 200 OK Obviously this could also be made propfind/propinfo (new propfind type), and it could also use child elements rather than attributes (...). The "live-property" property effectively provides the basis for this query (i.e. the detailed information will appear as child elements of the live-property element). In general, nested elements are better than attributes, since element values have structure while attribute values are just strings. 3. 2.1.1 Creating a Version-Controlled Resource and 2.3.1 DAV:checked-in (protected) OK, under core versioning, every version is a resource on it's own. Does this mean that a server has to assign a unique URL and make the version resource visible under this URL, for instance for PROPINFO? Or is this optional? It is required. Cheers, Geoff From w3c-dist-auth-request@w3.org Fri Apr 13 12:10:10 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA11780 for ; Fri, 13 Apr 2001 12:10:09 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA20308; Fri, 13 Apr 2001 12:03:19 -0400 (EDT) Resent-Date: Fri, 13 Apr 2001 12:03:19 -0400 (EDT) Resent-Message-Id: <200104131603.MAA20308@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id MAA20265 for ; Fri, 13 Apr 2001 12:03:06 -0400 (EDT) Received: from megapathdsl.net (snowbird.megapath.net [216.200.176.7]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id MAA01539 for ; Fri, 13 Apr 2001 12:03:06 -0400 Received: from [216.36.75.57] (HELO ZERG) by megapathdsl.net (CommuniGate Pro SMTP 3.4.3) with SMTP id 19387201; Fri, 13 Apr 2001 09:02:39 -0700 From: "Kevin Wiggen" To: "Greg Stein" , "WebDAV WG" Date: Fri, 13 Apr 2001 09:02:25 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <20010411010628.G29269@lyra.org> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: RE: Issue: PROP_ATTR Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4780 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit I agree with Greg et all that "attr2" needs to be stored. I believe that allowing "attr1" could lead to some interop problems, or we need to spec this out a little better: Is that legal? Does the attribute make the property unique? Does simply the value of an attribute make it unique? Or do we (like xmllang) simply store one set of attributes for a property? Also how does one use Dasl with attributes on properties? I would like to see attributes on the property name not be supported. Kevin -----Original Message----- From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Greg Stein Sent: Wednesday, April 11, 2001 1:06 AM To: WebDAV WG Subject: Re: Issue: PROP_ATTR The question isn't about attributes in general, it is about *which* attributes. Consider the following: thevalue I believe everybody would agree that attr2 gets stored. The real question is about attr1. I see that attribute as part of the element that *names* a property, but it isn't part of the property *value*. IMO, PROP_ATTR is about defining the boundary between property naming, and a property's value. Cheers, -g On Tue, Apr 10, 2001 at 10:58:21PM -0700, Eric Sedlar wrote: > I agree. There is no reason not to persist attributes. > > > -----Original Message----- > > From: w3c-dist-auth-request@w3.org > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Mark A. Hale > > Sent: Tuesday, April 10, 2001 6:29 PM > > To: WebDAV WG > > Subject: RE: Issue: PROP_ATTR > > > > > > Jim: Thanks for getting the issues list started. > > > > I believe that WebDAV must permit properties to have attributes. > > As you've > > pointed out, RDF and PRISM do use them extensively. A server can reformat > > the attributes in a subsequent PROPFIND request. Attrbiutes should be > > persistent. > > > > Thanks, > > > > Mark > > > > > > > > > > > -----Original Message----- > > > From: w3c-dist-auth-request@w3.org > > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jim Whitehead > > > Sent: Tuesday, April 10, 2001 5:54 PM > > > To: WebDAV WG > > > Subject: Issue: PROP_ATTR > > > > > > > > > As mentioned in a previous post, now is the time to start > > resolving issues > > > on the RFC 2518 issues list. As fate would have it, the first > > > issue on the > > > list is one that has been contentious in the past. Can we come to > > > consensus > > > on it now? > > > > > > Issue: PROP_ATTR > > > > > > Description: > > > > > > What is a WebDAV server required to do with XML attributes other than > > > xml:lang submitted with a PROPPATCH? This affects how well > > WebDAV will be > > > able to support RDF, since RDF uses attributes extensively. > > > > > > Greg Stein originally raised this issue: > > > > > > http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0089.html > > > > > > See also: > > > > > > http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0092.html > > > http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0094.html > > > http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0095.html > > > > > > > > > > > > > > > > > > > -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Fri Apr 13 12:10:19 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA11793 for ; Fri, 13 Apr 2001 12:10:16 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA20293; Fri, 13 Apr 2001 12:03:10 -0400 (EDT) Resent-Date: Fri, 13 Apr 2001 12:03:10 -0400 (EDT) Resent-Message-Id: <200104131603.MAA20293@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id MAA20261 for ; Fri, 13 Apr 2001 12:03:06 -0400 (EDT) Received: from megapathdsl.net (snowbird.megapath.net [216.200.176.7]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id MAA01537 for ; Fri, 13 Apr 2001 12:03:05 -0400 Received: from [216.36.75.57] (HELO ZERG) by megapathdsl.net (CommuniGate Pro SMTP 3.4.3) with SMTP id 19387197; Fri, 13 Apr 2001 09:02:39 -0700 From: "Kevin Wiggen" To: "Jim Whitehead" , "WebDAV WG" Date: Fri, 13 Apr 2001 09:02:25 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: RE: Issue: WRITE_DAV_PROP Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4779 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit I agree also. -----Original Message----- From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jim Whitehead Sent: Wednesday, April 11, 2001 9:53 AM To: WebDAV WG Subject: RE: Issue: WRITE_DAV_PROP I agree. - Jim > My vote: > - protected (i.e. properties that MUST NOT be modifiable with PROPPATCH) > creationdate > getcontentlength > getetag > getlastmodified > lockdiscovery > supportedlock > resourcetype > - not protected (i.e. properties that MUST be modifiable by PROPPATCH) > displayname > getcontentlanguage > getcontenttype > source > > My rationale for DAV:resourcetype is that the resourcetype should be used > to define the inherent nature of a resource (e.g. collection vs. > non-collection), while getcontenttype is definable by the client. > > Cheers, > Geoff > From w3c-dist-auth-request@w3.org Fri Apr 13 14:41:55 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA15966 for ; Fri, 13 Apr 2001 14:41:50 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA28952; Fri, 13 Apr 2001 14:35:19 -0400 (EDT) Resent-Date: Fri, 13 Apr 2001 14:35:19 -0400 (EDT) Resent-Message-Id: <200104131835.OAA28952@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id OAA28929 for ; Fri, 13 Apr 2001 14:35:14 -0400 (EDT) Received: from sus-ma1it00.rational.com (ext-37140.rational.com [192.229.37.140]) by tux.w3.org (8.9.3/8.9.3) with SMTP id OAA17730 for ; Fri, 13 Apr 2001 14:35:14 -0400 Received: from 192.168.215.70 by sus-ma1it00.rational.com (InterScan E-Mail VirusWall NT); Fri, 13 Apr 2001 14:36:42 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Fri, 13 Apr 2001 14:36:42 -0400 Message-ID: <3906C56A7BD1F54593344C05BD1374B1018E235C@SUS-MA1IT01> From: "Clemm, Geoff" To: WebDAV WG Date: Fri, 13 Apr 2001 14:34:36 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: RE: Issue: PROP_ATTR Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4781 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: For dead properties, I don't see the issue wrt storing attribute values for the root element. If you are storing attributes on all the nested elements (as I believe everyone has agreed), it should be trivial to store it on the root element as well. For live properties, where the server can take advantage of its knowledge of the value space for the live property values, then I agree that it could be an issue. So I still prefer saying MUST on all attributes of dead properties, and "as specified in the property definition" for live properties. Cheers, Geoff -----Original Message----- From: Kevin Wiggen [mailto:wiggs@wiggenout.com] Sent: Friday, April 13, 2001 12:02 PM To: Greg Stein; WebDAV WG Subject: RE: Issue: PROP_ATTR I agree with Greg et all that "attr2" needs to be stored. I believe that allowing "attr1" could lead to some interop problems, or we need to spec this out a little better: Is that legal? Does the attribute make the property unique? Does simply the value of an attribute make it unique? Or do we (like xmllang) simply store one set of attributes for a property? Also how does one use Dasl with attributes on properties? I would like to see attributes on the property name not be supported. Kevin -----Original Message----- From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Greg Stein Sent: Wednesday, April 11, 2001 1:06 AM To: WebDAV WG Subject: Re: Issue: PROP_ATTR The question isn't about attributes in general, it is about *which* attributes. Consider the following: thevalue I believe everybody would agree that attr2 gets stored. The real question is about attr1. I see that attribute as part of the element that *names* a property, but it isn't part of the property *value*. IMO, PROP_ATTR is about defining the boundary between property naming, and a property's value. Cheers, -g On Tue, Apr 10, 2001 at 10:58:21PM -0700, Eric Sedlar wrote: > I agree. There is no reason not to persist attributes. > > > -----Original Message----- > > From: w3c-dist-auth-request@w3.org > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Mark A. Hale > > Sent: Tuesday, April 10, 2001 6:29 PM > > To: WebDAV WG > > Subject: RE: Issue: PROP_ATTR > > > > > > Jim: Thanks for getting the issues list started. > > > > I believe that WebDAV must permit properties to have attributes. > > As you've > > pointed out, RDF and PRISM do use them extensively. A server can reformat > > the attributes in a subsequent PROPFIND request. Attrbiutes should be > > persistent. > > > > Thanks, > > > > Mark > > > > > > > > > > > -----Original Message----- > > > From: w3c-dist-auth-request@w3.org > > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jim Whitehead > > > Sent: Tuesday, April 10, 2001 5:54 PM > > > To: WebDAV WG > > > Subject: Issue: PROP_ATTR > > > > > > > > > As mentioned in a previous post, now is the time to start > > resolving issues > > > on the RFC 2518 issues list. As fate would have it, the first > > > issue on the > > > list is one that has been contentious in the past. Can we come to > > > consensus > > > on it now? > > > > > > Issue: PROP_ATTR > > > > > > Description: > > > > > > What is a WebDAV server required to do with XML attributes other than > > > xml:lang submitted with a PROPPATCH? This affects how well > > WebDAV will be > > > able to support RDF, since RDF uses attributes extensively. > > > > > > Greg Stein originally raised this issue: > > > > > > http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0089.html > > > > > > See also: > > > > > > http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0092.html > > > http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0094.html > > > http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0095.html > > > > > > > > > > > > > > > > > > > -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Fri Apr 13 15:32:44 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA16685 for ; Fri, 13 Apr 2001 15:32:41 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA02068; Fri, 13 Apr 2001 15:24:52 -0400 (EDT) Resent-Date: Fri, 13 Apr 2001 15:24:52 -0400 (EDT) Resent-Message-Id: <200104131924.PAA02068@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id PAA02041 for ; Fri, 13 Apr 2001 15:24:47 -0400 (EDT) Received: from e1.ny.us.ibm.com ([32.97.182.101]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id PAA22580 for ; Fri, 13 Apr 2001 15:24:45 -0400 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id PAA32756; Fri, 13 Apr 2001 15:22:46 -0400 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.117.200.72]) by northrelay02.pok.ibm.com (8.8.8m3/NCO v4.96) with ESMTP id PAA39882; Fri, 13 Apr 2001 15:19:28 -0400 Importance: Normal To: "Clemm, Geoff" Cc: w3c-dist-auth@w3.org X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "Jason Crawford" Date: Fri, 13 Apr 2001 15:12:44 -0400 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 5.0.7 |March 21, 2001) at 04/13/2001 03:24:08 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: RE: Issue: PROP_ATTR Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4782 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: I agree with Geoff about attributes on live vs dead properties. (Although I'm frustrated that the name of the property is mixed in with the value. I just don't have an acceptable alternative.) That is... the attributes of the property name tag of dead properties (until we find an exception) must be retained. For live properties, it's up to the definition of the property. J. ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com From w3c-dist-auth-request@w3.org Fri Apr 13 16:45:03 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA18139 for ; Fri, 13 Apr 2001 16:44:56 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA04797; Fri, 13 Apr 2001 16:29:46 -0400 (EDT) Resent-Date: Fri, 13 Apr 2001 16:29:46 -0400 (EDT) Resent-Message-Id: <200104132029.QAA04797@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id QAA04771 for ; Fri, 13 Apr 2001 16:29:41 -0400 (EDT) Received: from kurgan.lyra.org (kurgan.lyra.org [198.144.203.198]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id QAA29779 for ; Fri, 13 Apr 2001 16:19:18 -0400 Received: (from gstein@localhost) by kurgan.lyra.org (8.9.3/8.9.3) id NAA02490 for w3c-dist-auth@w3.org; Fri, 13 Apr 2001 13:20:39 -0700 X-Authentication-Warning: kurgan.lyra.org: gstein set sender to gstein@lyra.org using -f Date: Fri, 13 Apr 2001 13:20:39 -0700 From: Greg Stein To: WebDAV WG Message-ID: <20010413132038.L31832@lyra.org> Mail-Followup-To: WebDAV WG References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from ccjason@us.ibm.com on Fri, Apr 13, 2001 at 03:28:46PM -0400 X-URL: http://www.lyra.org/greg/ Subject: Re: Issue: PROP_ATTR Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4784 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: On Fri, Apr 13, 2001 at 03:28:46PM -0400, Jason Crawford wrote: > > > << > > > > > > >> > I agree that this is not acceptable unless attr1 and attr2 are namespace > attributes that alter the effective tag name of the property name tags. > > This does lead me to another question though. If in the PROPPATCH call > there are xmlns attributes on the propertyupdate, set, or prop tags that > could potentially affect the tags within the property value, is the server > responsible for collecting those and representing those in PROPPATCH > responses? Or should we require that the client put any xmlns attributes > that it cares about on the propertyname tag and within? No way... we should not be demanding that an xmlns attribute lives in a specific area. That seems to run completely counter to the notion of namespaces and their scoping. At a specific point in the XML body, an xmlns set and an xml:lang are "in scope", and the server better be storing those. Cheers, -g -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Fri Apr 13 16:45:08 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA18150 for ; Fri, 13 Apr 2001 16:45:07 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA05203; Fri, 13 Apr 2001 16:38:52 -0400 (EDT) Resent-Date: Fri, 13 Apr 2001 16:38:52 -0400 (EDT) Resent-Message-Id: <200104132038.QAA05203@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id QAA05182 for ; Fri, 13 Apr 2001 16:38:49 -0400 (EDT) Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id QAA00887 for ; Fri, 13 Apr 2001 16:32:03 -0400 Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e21.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id QAA177766 for ; Fri, 13 Apr 2001 16:25:20 -0500 Received: from d04nm303.raleigh.ibm.com (d04nm303.raleigh.ibm.com [9.67.228.168]) by southrelay02.raleigh.ibm.com (8.11.1/NCO v4.96) with ESMTP id f3DKUXT124856 for ; Fri, 13 Apr 2001 16:30:33 -0400 To: w3c-dist-auth@w3c.org X-Mailer: Lotus Notes Release 5.0.6a January 17, 2001 Message-ID: From: "Jim Amsden" Date: Fri, 13 Apr 2001 16:27:03 -0400 X-MIMETrack: Serialize by Router on D04NM303/04/M/IBM(Release 5.0.6 |December 14, 2000) at 04/13/2001 04:30:32 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: RE: Issue: PROP_ATTR Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4785 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: I agree that all attributes should be stored on the property value, but the DAV:prop element belongs to WebDAV, and WebDAV should define its attributes as well as content. We should keep attributes off the property name except those defined by the protocol. Clients should be able to put whatever they want on the value however they want. And servers should feel free to store them any way they want. "Clemm, Geoff" om> cc: Sent by: Subject: RE: Issue: PROP_ATTR w3c-dist-auth-requ est@w3.org 04/13/2001 02:34 PM For dead properties, I don't see the issue wrt storing attribute values for the root element. If you are storing attributes on all the nested elements (as I believe everyone has agreed), it should be trivial to store it on the root element as well. For live properties, where the server can take advantage of its knowledge of the value space for the live property values, then I agree that it could be an issue. So I still prefer saying MUST on all attributes of dead properties, and "as specified in the property definition" for live properties. Cheers, Geoff -----Original Message----- From: Kevin Wiggen [mailto:wiggs@wiggenout.com] Sent: Friday, April 13, 2001 12:02 PM To: Greg Stein; WebDAV WG Subject: RE: Issue: PROP_ATTR I agree with Greg et all that "attr2" needs to be stored. I believe that allowing "attr1" could lead to some interop problems, or we need to spec this out a little better: Is that legal? Does the attribute make the property unique? Does simply the value of an attribute make it unique? Or do we (like xmllang) simply store one set of attributes for a property? Also how does one use Dasl with attributes on properties? I would like to see attributes on the property name not be supported. Kevin -----Original Message----- From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Greg Stein Sent: Wednesday, April 11, 2001 1:06 AM To: WebDAV WG Subject: Re: Issue: PROP_ATTR The question isn't about attributes in general, it is about *which* attributes. Consider the following: thevalue I believe everybody would agree that attr2 gets stored. The real question is about attr1. I see that attribute as part of the element that *names* a property, but it isn't part of the property *value*. IMO, PROP_ATTR is about defining the boundary between property naming, and a property's value. Cheers, -g On Tue, Apr 10, 2001 at 10:58:21PM -0700, Eric Sedlar wrote: > I agree. There is no reason not to persist attributes. > > > -----Original Message----- > > From: w3c-dist-auth-request@w3.org > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Mark A. Hale > > Sent: Tuesday, April 10, 2001 6:29 PM > > To: WebDAV WG > > Subject: RE: Issue: PROP_ATTR > > > > > > Jim: Thanks for getting the issues list started. > > > > I believe that WebDAV must permit properties to have attributes. > > As you've > > pointed out, RDF and PRISM do use them extensively. A server can reformat > > the attributes in a subsequent PROPFIND request. Attrbiutes should be > > persistent. > > > > Thanks, > > > > Mark > > > > > > > > > > > -----Original Message----- > > > From: w3c-dist-auth-request@w3.org > > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jim Whitehead > > > Sent: Tuesday, April 10, 2001 5:54 PM > > > To: WebDAV WG > > > Subject: Issue: PROP_ATTR > > > > > > > > > As mentioned in a previous post, now is the time to start > > resolving issues > > > on the RFC 2518 issues list. As fate would have it, the first > > > issue on the > > > list is one that has been contentious in the past. Can we come to > > > consensus > > > on it now? > > > > > > Issue: PROP_ATTR > > > > > > Description: > > > > > > What is a WebDAV server required to do with XML attributes other than > > > xml:lang submitted with a PROPPATCH? This affects how well > > WebDAV will be > > > able to support RDF, since RDF uses attributes extensively. > > > > > > Greg Stein originally raised this issue: > > > > > > http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0089.html > > > > > > See also: > > > > > > http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0092.html > > > http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0094.html > > > http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0095.html > > > > > > > > > > > > > > > > > > > -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Fri Apr 13 16:48:24 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA18210 for ; Fri, 13 Apr 2001 16:48:24 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA05338; Fri, 13 Apr 2001 16:43:06 -0400 (EDT) Resent-Date: Fri, 13 Apr 2001 16:43:06 -0400 (EDT) Resent-Message-Id: <200104132043.QAA05338@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id QAA05318 for ; Fri, 13 Apr 2001 16:43:02 -0400 (EDT) Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id QAA06767 for ; Fri, 13 Apr 2001 16:34:10 -0400 Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e21.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id QAA38792 for ; Fri, 13 Apr 2001 16:27:39 -0500 Received: from d04nm303.raleigh.ibm.com (d04nm303.raleigh.ibm.com [9.67.228.168]) by southrelay02.raleigh.ibm.com (8.11.1/NCO v4.96) with ESMTP id f3DKWwT88758 for ; Fri, 13 Apr 2001 16:32:58 -0400 To: w3c-dist-auth@w3c.org X-Mailer: Lotus Notes Release 5.0.6a January 17, 2001 Message-ID: From: "Jim Amsden" Date: Fri, 13 Apr 2001 16:30:28 -0400 X-MIMETrack: Serialize by Router on D04NM303/04/M/IBM(Release 5.0.6 |December 14, 2000) at 04/13/2001 04:32:57 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: RE: Issue: PROP_ATTR Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4786 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: I think the usual XML rules should apply. That is, namespace attributes on the DAV:prop element get applied by default to the value unless the value provides its own. Clients have complete control of this if it the default isn't what they want. Servers should be uninvolved in determining semantics other than following XML rules. "Jason Crawford" To: "Kevin Wiggen" m.com> Subject: RE: Issue: PROP_ATTR 04/13/2001 03:28 PM << >> I agree that this is not acceptable unless attr1 and attr2 are namespace attributes that alter the effective tag name of the property name tags. This does lead me to another question though. If in the PROPPATCH call there are xmlns attributes on the propertyupdate, set, or prop tags that could potentially affect the tags within the property value, is the server responsible for collecting those and representing those in PROPPATCH responses? Or should we require that the client put any xmlns attributes that it cares about on the propertyname tag and within? J. From w3c-dist-auth-request@w3.org Fri Apr 13 16:50:32 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA18260 for ; Fri, 13 Apr 2001 16:50:30 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA05442; Fri, 13 Apr 2001 16:44:37 -0400 (EDT) Resent-Date: Fri, 13 Apr 2001 16:44:37 -0400 (EDT) Resent-Message-Id: <200104132044.QAA05442@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id QAA05422 for ; Fri, 13 Apr 2001 16:44:33 -0400 (EDT) Received: from kurgan.lyra.org (test.webdav.org [198.144.203.199]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id QAA12242 for ; Fri, 13 Apr 2001 16:44:32 -0400 Received: (from gstein@localhost) by kurgan.lyra.org (8.9.3/8.9.3) id NAA02571 for w3c-dist-auth@w3.org; Fri, 13 Apr 2001 13:46:24 -0700 X-Authentication-Warning: kurgan.lyra.org: gstein set sender to gstein@lyra.org using -f Date: Fri, 13 Apr 2001 13:46:24 -0700 From: Greg Stein To: WebDAV WG Message-ID: <20010413134623.M31832@lyra.org> Mail-Followup-To: WebDAV WG References: <3906C56A7BD1F54593344C05BD1374B1018E235C@SUS-MA1IT01> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <3906C56A7BD1F54593344C05BD1374B1018E235C@SUS-MA1IT01>; from gclemm@rational.com on Fri, Apr 13, 2001 at 02:34:36PM -0400 X-URL: http://www.lyra.org/greg/ Subject: Re: Issue: PROP_ATTR Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4787 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: The issue is that provides the name. The stuff inside that is the property value. Attributes on the root are associated with the name, not the value. Haven't we always tried to use element nesting as a means of structure? Don't we tend to say that attributes are modifiers for the element they occur on? I'd rather not see attributes on the name supported. On the value, sure. Maybe people are thinking that the name element is stored with the value. I see it more as the name is a key, which then maps to the value. Further, the name (key) is broken into a tuple of (localpart, namespace-uri, xml:lang), so I don't see it as stored as XML with the rest of the value. And since it isn't in XML format, it becomes very difficult to store things such as attributes. Let's say that you *do* choose to store the name with the XML value. How do you manage the namespace and xml:lang. Does the property always have to store a private namespace to ensure that you don't get prefix clashes? For example: value (as opposed to collecting a union of all namespace prefixes and placing them on a higher element) In the store-with-value approach, you're duplicating the data from the key to the value. Maybe the word "normalization" is too loud in my head :-), but I prefer not to do that. Cheers, -g On Fri, Apr 13, 2001 at 02:34:36PM -0400, Clemm, Geoff wrote: > For dead properties, I don't see the issue wrt storing attribute values > for the root element. If you are storing attributes on all the nested > elements (as I believe everyone has agreed), it should be trivial > to store it on the root element as well. > > For live properties, where the server can take advantage of its knowledge > of the value space for the live property values, then I agree that it > could be an issue. > > So I still prefer saying MUST on all attributes of dead properties, > and "as specified in the property definition" for live properties. > > Cheers, > Geoff > > -----Original Message----- > From: Kevin Wiggen [mailto:wiggs@wiggenout.com] > Sent: Friday, April 13, 2001 12:02 PM > To: Greg Stein; WebDAV WG > Subject: RE: Issue: PROP_ATTR > > > > I agree with Greg et all that "attr2" needs to be stored. > > I believe that allowing "attr1" could lead to some interop problems, or we > need to spec this out a little better: > > > > > > > > Is that legal? Does the attribute make the property unique? Does simply > the value of an attribute make it unique? Or do we (like xmllang) simply > store one set of attributes for a property? > > Also how does one use Dasl with attributes on properties? > > I would like to see attributes on the property name not be supported. > > Kevin > > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Greg Stein > Sent: Wednesday, April 11, 2001 1:06 AM > To: WebDAV WG > Subject: Re: Issue: PROP_ATTR > > > The question isn't about attributes in general, it is about *which* > attributes. Consider the following: > > > > thevalue > > > > > I believe everybody would agree that attr2 gets stored. The real question is > about attr1. I see that attribute as part of the element that *names* a > property, but it isn't part of the property *value*. > > IMO, PROP_ATTR is about defining the boundary between property naming, and a > property's value. > > Cheers, > -g > > On Tue, Apr 10, 2001 at 10:58:21PM -0700, Eric Sedlar wrote: > > I agree. There is no reason not to persist attributes. > > > > > -----Original Message----- > > > From: w3c-dist-auth-request@w3.org > > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Mark A. Hale > > > Sent: Tuesday, April 10, 2001 6:29 PM > > > To: WebDAV WG > > > Subject: RE: Issue: PROP_ATTR > > > > > > > > > Jim: Thanks for getting the issues list started. > > > > > > I believe that WebDAV must permit properties to have attributes. > > > As you've > > > pointed out, RDF and PRISM do use them extensively. A server can > reformat > > > the attributes in a subsequent PROPFIND request. Attrbiutes should be > > > persistent. > > > > > > Thanks, > > > > > > Mark > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: w3c-dist-auth-request@w3.org > > > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jim Whitehead > > > > Sent: Tuesday, April 10, 2001 5:54 PM > > > > To: WebDAV WG > > > > Subject: Issue: PROP_ATTR > > > > > > > > > > > > As mentioned in a previous post, now is the time to start > > > resolving issues > > > > on the RFC 2518 issues list. As fate would have it, the first > > > > issue on the > > > > list is one that has been contentious in the past. Can we come to > > > > consensus > > > > on it now? > > > > > > > > Issue: PROP_ATTR > > > > > > > > Description: > > > > > > > > What is a WebDAV server required to do with XML attributes other than > > > > xml:lang submitted with a PROPPATCH? This affects how well > > > WebDAV will be > > > > able to support RDF, since RDF uses attributes extensively. > > > > > > > > Greg Stein originally raised this issue: > > > > > > > > http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0089.html > > > > > > > > See also: > > > > > > > > http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0092.html > > > > http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0094.html > > > > http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0095.html > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > Greg Stein, http://www.lyra.org/ -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Fri Apr 13 17:10:45 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA18547 for ; Fri, 13 Apr 2001 17:10:45 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA06411; Fri, 13 Apr 2001 16:54:21 -0400 (EDT) Resent-Date: Fri, 13 Apr 2001 16:54:21 -0400 (EDT) Resent-Message-Id: <200104132054.QAA06411@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id QAA06387 for ; Fri, 13 Apr 2001 16:54:16 -0400 (EDT) Received: from kurgan.lyra.org (test.webdav.org [198.144.203.199]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id QAA13505 for ; Fri, 13 Apr 2001 16:54:15 -0400 Received: (from gstein@localhost) by kurgan.lyra.org (8.9.3/8.9.3) id NAA02580 for w3c-dist-auth@w3.org; Fri, 13 Apr 2001 13:56:07 -0700 X-Authentication-Warning: kurgan.lyra.org: gstein set sender to gstein@lyra.org using -f Date: Fri, 13 Apr 2001 13:56:06 -0700 From: Greg Stein To: WebDAV WG Message-ID: <20010413135606.N31832@lyra.org> Mail-Followup-To: WebDAV WG References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from wiggs@wiggenout.com on Fri, Apr 13, 2001 at 09:02:25AM -0700 X-URL: http://www.lyra.org/greg/ Subject: Re: Issue: WRITE_DAV_PROP Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4788 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Seems fine, but... I could see an argument for getlastmodified (e.g. "touch" the resource). And maybe for creationdate for somebody that is restoring documents to a server. Then you have the "COPY is performed using PROPPATCH" where you may need to copy all the props. I'm also a bit leery of the getcontentlanguage and getcontenttype being a MUST. I'd prefer those be a MAY, and displayname and source remain as MUST. The basic problem with the language/type is needing to look them up for each GET from the server. That can seriously impact server performance. Cheers, -g On Fri, Apr 13, 2001 at 09:02:25AM -0700, Kevin Wiggen wrote: > > I agree also. > > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jim Whitehead > Sent: Wednesday, April 11, 2001 9:53 AM > To: WebDAV WG > Subject: RE: Issue: WRITE_DAV_PROP > > > I agree. > > - Jim > > > My vote: > > - protected (i.e. properties that MUST NOT be modifiable with PROPPATCH) > > creationdate > > getcontentlength > > getetag > > getlastmodified > > lockdiscovery > > supportedlock > > resourcetype > > - not protected (i.e. properties that MUST be modifiable by PROPPATCH) > > displayname > > getcontentlanguage > > getcontenttype > > source > > > > My rationale for DAV:resourcetype is that the resourcetype should be used > > to define the inherent nature of a resource (e.g. collection vs. > > non-collection), while getcontenttype is definable by the client. > > > > Cheers, > > Geoff > > -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Fri Apr 13 17:59:05 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA19280 for ; Fri, 13 Apr 2001 17:59:05 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA02274; Fri, 13 Apr 2001 15:30:57 -0400 (EDT) Resent-Date: Fri, 13 Apr 2001 15:30:57 -0400 (EDT) Resent-Message-Id: <200104131930.PAA02274@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id PAA02254 for ; Fri, 13 Apr 2001 15:30:53 -0400 (EDT) Received: from e1.ny.us.ibm.com ([32.97.182.101]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id PAA23267 for ; Fri, 13 Apr 2001 15:30:52 -0400 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id PAA178354; Fri, 13 Apr 2001 15:28:54 -0400 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.117.200.72]) by northrelay02.pok.ibm.com (8.8.8m3/NCO v4.96) with ESMTP id PAA147786; Fri, 13 Apr 2001 15:25:31 -0400 Importance: Normal To: "Kevin Wiggen" Cc: "WebDAV WG" X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "Jason Crawford" Date: Fri, 13 Apr 2001 15:28:46 -0400 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 5.0.7 |March 21, 2001) at 04/13/2001 03:30:16 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: RE: Issue: PROP_ATTR Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4783 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: << >> I agree that this is not acceptable unless attr1 and attr2 are namespace attributes that alter the effective tag name of the property name tags. This does lead me to another question though. If in the PROPPATCH call there are xmlns attributes on the propertyupdate, set, or prop tags that could potentially affect the tags within the property value, is the server responsible for collecting those and representing those in PROPPATCH responses? Or should we require that the client put any xmlns attributes that it cares about on the propertyname tag and within? J. From w3c-dist-auth-request@w3.org Fri Apr 13 18:02:00 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA19343 for ; Fri, 13 Apr 2001 18:01:58 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA08662; Fri, 13 Apr 2001 17:55:32 -0400 (EDT) Resent-Date: Fri, 13 Apr 2001 17:55:32 -0400 (EDT) Resent-Message-Id: <200104132155.RAA08662@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id RAA08642 for ; Fri, 13 Apr 2001 17:55:26 -0400 (EDT) Received: from ladon.host4u.net (ladon.host4u.net [216.71.64.24]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id RAA19263 for ; Fri, 13 Apr 2001 17:55:26 -0400 Received: from win2k (CBL120.pool007.CH001-riverside.dhcp.hs.earthlink.net [24.41.38.120]) by ladon.host4u.net (8.8.5/8.8.5) with SMTP id QAA05559 for ; Fri, 13 Apr 2001 16:49:59 -0500 Message-ID: <001b01c0c465$dc1ca660$6701a8c0@win2k> From: "John Glavin" To: "WebDAV WG" References: <20010413135606.N31832@lyra.org> Date: Fri, 13 Apr 2001 15:05:32 -0700 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.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Subject: Re: Issue: WRITE_DAV_PROP Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4789 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit I agree about the "getlastmodified" property. I would love to be able to set this so that file synchronization software will work properly. My product maps a network drive to a DAV server and unless I can set the "getlastmodified" property file synch software won't work right. I only know of one server that allows this now, it would be nice if this could be standardized. John Glavin RiverFront Software john@webdrive.com http://www.webdrive.com ----- Original Message ----- From: "Greg Stein" To: "WebDAV WG" Sent: Friday, April 13, 2001 1:56 PM Subject: Re: Issue: WRITE_DAV_PROP > Seems fine, but... > > I could see an argument for getlastmodified (e.g. "touch" the resource). And > maybe for creationdate for somebody that is restoring documents to a server. > Then you have the "COPY is performed using PROPPATCH" where you may need to > copy all the props. > > I'm also a bit leery of the getcontentlanguage and getcontenttype being a > MUST. I'd prefer those be a MAY, and displayname and source remain as MUST. > The basic problem with the language/type is needing to look them up for each > GET from the server. That can seriously impact server performance. > > Cheers, > -g > > On Fri, Apr 13, 2001 at 09:02:25AM -0700, Kevin Wiggen wrote: > > > > I agree also. > > > > -----Original Message----- > > From: w3c-dist-auth-request@w3.org > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jim Whitehead > > Sent: Wednesday, April 11, 2001 9:53 AM > > To: WebDAV WG > > Subject: RE: Issue: WRITE_DAV_PROP > > > > > > I agree. > > > > - Jim > > > > > My vote: > > > - protected (i.e. properties that MUST NOT be modifiable with PROPPATCH) > > > creationdate > > > getcontentlength > > > getetag > > > getlastmodified > > > lockdiscovery > > > supportedlock > > > resourcetype > > > - not protected (i.e. properties that MUST be modifiable by PROPPATCH) > > > displayname > > > getcontentlanguage > > > getcontenttype > > > source > > > > > > My rationale for DAV:resourcetype is that the resourcetype should be used > > > to define the inherent nature of a resource (e.g. collection vs. > > > non-collection), while getcontenttype is definable by the client. > > > > > > Cheers, > > > Geoff > > > > > -- > Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Fri Apr 13 18:31:53 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA19666 for ; Fri, 13 Apr 2001 18:31:51 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAA09709; Fri, 13 Apr 2001 18:26:22 -0400 (EDT) Resent-Date: Fri, 13 Apr 2001 18:26:22 -0400 (EDT) Resent-Message-Id: <200104132226.SAA09709@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id SAA09688 for ; Fri, 13 Apr 2001 18:26:17 -0400 (EDT) Received: from e24.nc.us.ibm.com (e24.nc.us.ibm.com [32.97.136.230]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id SAA21908 for ; Fri, 13 Apr 2001 18:26:16 -0400 Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e24.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id SAA57996 for ; Fri, 13 Apr 2001 18:26:40 -0500 Received: from d04nm303.raleigh.ibm.com (d04nm303.raleigh.ibm.com [9.67.228.168]) by southrelay02.raleigh.ibm.com (8.11.1/NCO v4.96) with ESMTP id f3DMOwT58544 for ; Fri, 13 Apr 2001 18:24:59 -0400 To: w3c-dist-auth@w3c.org X-Mailer: Lotus Notes Release 5.0.6a January 17, 2001 Message-ID: From: "Jim Amsden" Date: Fri, 13 Apr 2001 18:20:36 -0400 X-MIMETrack: Serialize by Router on D04NM303/04/M/IBM(Release 5.0.6 |December 14, 2000) at 04/13/2001 06:24:58 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: Re: Issue: PROP_ATTR Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4790 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: I agree with Greg. One clarification. The property name may need a namespace too. In this case, the usual XML rules should apply. Define a namespace for the name. WebDAV specifies what this means: replace the namespace prefix with it namespace value and concatenate it to the front of the property name to create the key. This rule however DOES NOT APPLY to the value. It is up to the application to determine how to handle the namespace and prefix for the value. If the value doesn't specify a different namespace, again the usual XML rules apply and the property name namespace is also applied to element tags in the value, if they use the prefix. If this is not what is desired, the clients can put a different namespace on the value. The only issues is what does the server store for the property key? The name after prefix substitution? The namespace and prefix so they can be reconstructed on a PROPFIND? I think the server needs to store all namespace information on the property name because WebDAV says propery names are XML tags. On storing the property name (key) with the value: if its in the value, store it with the value. If not, don't. Greg Stein To: WebDAV WG Sent by: cc: w3c-dist-auth-requ Subject: Re: Issue: PROP_ATTR est@w3.org 04/13/2001 04:46 PM The issue is that provides the name. The stuff inside that is the property value. Attributes on the root are associated with the name, not the value. Haven't we always tried to use element nesting as a means of structure? Don't we tend to say that attributes are modifiers for the element they occur on? I'd rather not see attributes on the name supported. On the value, sure. Maybe people are thinking that the name element is stored with the value. I see it more as the name is a key, which then maps to the value. Further, the name (key) is broken into a tuple of (localpart, namespace-uri, xml:lang), so I don't see it as stored as XML with the rest of the value. And since it isn't in XML format, it becomes very difficult to store things such as attributes. Let's say that you *do* choose to store the name with the XML value. How do you manage the namespace and xml:lang. Does the property always have to store a private namespace to ensure that you don't get prefix clashes? For example: value (as opposed to collecting a union of all namespace prefixes and placing them on a higher element) In the store-with-value approach, you're duplicating the data from the key to the value. Maybe the word "normalization" is too loud in my head :-), but I prefer not to do that. Cheers, -g On Fri, Apr 13, 2001 at 02:34:36PM -0400, Clemm, Geoff wrote: > For dead properties, I don't see the issue wrt storing attribute values > for the root element. If you are storing attributes on all the nested > elements (as I believe everyone has agreed), it should be trivial > to store it on the root element as well. > > For live properties, where the server can take advantage of its knowledge > of the value space for the live property values, then I agree that it > could be an issue. > > So I still prefer saying MUST on all attributes of dead properties, > and "as specified in the property definition" for live properties. > > Cheers, > Geoff > > -----Original Message----- > From: Kevin Wiggen [mailto:wiggs@wiggenout.com] > Sent: Friday, April 13, 2001 12:02 PM > To: Greg Stein; WebDAV WG > Subject: RE: Issue: PROP_ATTR > > > > I agree with Greg et all that "attr2" needs to be stored. > > I believe that allowing "attr1" could lead to some interop problems, or we > need to spec this out a little better: > > > > > > > > Is that legal? Does the attribute make the property unique? Does simply > the value of an attribute make it unique? Or do we (like xmllang) simply > store one set of attributes for a property? > > Also how does one use Dasl with attributes on properties? > > I would like to see attributes on the property name not be supported. > > Kevin > > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Greg Stein > Sent: Wednesday, April 11, 2001 1:06 AM > To: WebDAV WG > Subject: Re: Issue: PROP_ATTR > > > The question isn't about attributes in general, it is about *which* > attributes. Consider the following: > > > > thevalue > > > > > I believe everybody would agree that attr2 gets stored. The real question is > about attr1. I see that attribute as part of the element that *names* a > property, but it isn't part of the property *value*. > > IMO, PROP_ATTR is about defining the boundary between property naming, and a > property's value. > > Cheers, > -g > > On Tue, Apr 10, 2001 at 10:58:21PM -0700, Eric Sedlar wrote: > > I agree. There is no reason not to persist attributes. > > > > > -----Original Message----- > > > From: w3c-dist-auth-request@w3.org > > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Mark A. Hale > > > Sent: Tuesday, April 10, 2001 6:29 PM > > > To: WebDAV WG > > > Subject: RE: Issue: PROP_ATTR > > > > > > > > > Jim: Thanks for getting the issues list started. > > > > > > I believe that WebDAV must permit properties to have attributes. > > > As you've > > > pointed out, RDF and PRISM do use them extensively. A server can > reformat > > > the attributes in a subsequent PROPFIND request. Attrbiutes should be > > > persistent. > > > > > > Thanks, > > > > > > Mark > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: w3c-dist-auth-request@w3.org > > > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jim Whitehead > > > > Sent: Tuesday, April 10, 2001 5:54 PM > > > > To: WebDAV WG > > > > Subject: Issue: PROP_ATTR > > > > > > > > > > > > As mentioned in a previous post, now is the time to start > > > resolving issues > > > > on the RFC 2518 issues list. As fate would have it, the first > > > > issue on the > > > > list is one that has been contentious in the past. Can we come to > > > > consensus > > > > on it now? > > > > > > > > Issue: PROP_ATTR > > > > > > > > Description: > > > > > > > > What is a WebDAV server required to do with XML attributes other than > > > > xml:lang submitted with a PROPPATCH? This affects how well > > > WebDAV will be > > > > able to support RDF, since RDF uses attributes extensively. > > > > > > > > Greg Stein originally raised this issue: > > > > > > > > http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0089.html > > > > > > > > See also: > > > > > > > > http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0092.html > > > > http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0094.html > > > > http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0095.html > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > Greg Stein, http://www.lyra.org/ -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Fri Apr 13 18:41:31 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA19849 for ; Fri, 13 Apr 2001 18:41:30 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAA09788; Fri, 13 Apr 2001 18:30:32 -0400 (EDT) Resent-Date: Fri, 13 Apr 2001 18:30:32 -0400 (EDT) Resent-Message-Id: <200104132230.SAA09788@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id SAA09767 for ; Fri, 13 Apr 2001 18:30:27 -0400 (EDT) Received: from e24.nc.us.ibm.com (e24.nc.us.ibm.com [32.97.136.230]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id SAA22185 for ; Fri, 13 Apr 2001 18:30:26 -0400 Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e24.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id SAA16882 for ; Fri, 13 Apr 2001 18:30:50 -0500 Received: from d04nm303.raleigh.ibm.com (d04nm303.raleigh.ibm.com [9.67.228.168]) by southrelay02.raleigh.ibm.com (8.11.1/NCO v4.96) with ESMTP id f3DMT8T131444 for ; Fri, 13 Apr 2001 18:29:09 -0400 To: w3c-dist-auth@w3c.org X-Mailer: Lotus Notes Release 5.0.6a January 17, 2001 Message-ID: From: "Jim Amsden" Date: Fri, 13 Apr 2001 18:23:17 -0400 X-MIMETrack: Serialize by Router on D04NM303/04/M/IBM(Release 5.0.6 |December 14, 2000) at 04/13/2001 06:29:09 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: Re: Issue: WRITE_DAV_PROP Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4791 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Sounds fine to me. "John Glavin" tware.com> cc: Sent by: Subject: Re: Issue: WRITE_DAV_PROP w3c-dist-auth-reque st@w3.org 04/13/2001 06:05 PM I agree about the "getlastmodified" property. I would love to be able to set this so that file synchronization software will work properly. My product maps a network drive to a DAV server and unless I can set the "getlastmodified" property file synch software won't work right. I only know of one server that allows this now, it would be nice if this could be standardized. John Glavin RiverFront Software john@webdrive.com http://www.webdrive.com ----- Original Message ----- From: "Greg Stein" To: "WebDAV WG" Sent: Friday, April 13, 2001 1:56 PM Subject: Re: Issue: WRITE_DAV_PROP > Seems fine, but... > > I could see an argument for getlastmodified (e.g. "touch" the resource). And > maybe for creationdate for somebody that is restoring documents to a server. > Then you have the "COPY is performed using PROPPATCH" where you may need to > copy all the props. > > I'm also a bit leery of the getcontentlanguage and getcontenttype being a > MUST. I'd prefer those be a MAY, and displayname and source remain as MUST. > The basic problem with the language/type is needing to look them up for each > GET from the server. That can seriously impact server performance. > > Cheers, > -g > > On Fri, Apr 13, 2001 at 09:02:25AM -0700, Kevin Wiggen wrote: > > > > I agree also. > > > > -----Original Message----- > > From: w3c-dist-auth-request@w3.org > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jim Whitehead > > Sent: Wednesday, April 11, 2001 9:53 AM > > To: WebDAV WG > > Subject: RE: Issue: WRITE_DAV_PROP > > > > > > I agree. > > > > - Jim > > > > > My vote: > > > - protected (i.e. properties that MUST NOT be modifiable with PROPPATCH) > > > creationdate > > > getcontentlength > > > getetag > > > getlastmodified > > > lockdiscovery > > > supportedlock > > > resourcetype > > > - not protected (i.e. properties that MUST be modifiable by PROPPATCH) > > > displayname > > > getcontentlanguage > > > getcontenttype > > > source > > > > > > My rationale for DAV:resourcetype is that the resourcetype should be used > > > to define the inherent nature of a resource (e.g. collection vs. > > > non-collection), while getcontenttype is definable by the client. > > > > > > Cheers, > > > Geoff > > > > > -- > Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Sat Apr 14 00:27:09 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA25273 for ; Sat, 14 Apr 2001 00:27:07 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id AAA19561; Sat, 14 Apr 2001 00:15:13 -0400 (EDT) Resent-Date: Sat, 14 Apr 2001 00:15:13 -0400 (EDT) Resent-Message-Id: <200104140415.AAA19561@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id AAA19538 for ; Sat, 14 Apr 2001 00:15:07 -0400 (EDT) Received: from kurgan.lyra.org (kurgan.lyra.org [198.144.203.198]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id AAA14412 for ; Sat, 14 Apr 2001 00:15:05 -0400 Received: (from gstein@localhost) by kurgan.lyra.org (8.9.3/8.9.3) id VAA02990 for w3c-dist-auth@w3.org; Fri, 13 Apr 2001 21:16:54 -0700 X-Authentication-Warning: kurgan.lyra.org: gstein set sender to gstein@lyra.org using -f Date: Fri, 13 Apr 2001 21:16:54 -0700 From: Greg Stein To: w3c-dist-auth@w3.org Message-ID: <20010413211653.P31832@lyra.org> Mail-Followup-To: w3c-dist-auth@w3.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i X-URL: http://www.lyra.org/greg/ Subject: [zodiac@holoweb.net: Re: Issue: PROP_ATTR] Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4792 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: ----- Forwarded message from Laurie Harper ----- From: Laurie Harper Subject: Re: Issue: PROP_ATTR To: Greg Stein Date: Thu, 12 Apr 2001 11:38:41 -0400 Greg Stein wrote: > IMO, PROP_ATTR is about defining the boundary between property naming, and a > property's value. I'd say this is exactly scope of the issue. There is no reason why a property's value should be considered to be XML just because it is transported in an XML encoding. The problem is that, if the characters between the property's start and end tag *look like* XML then they are likely going to get processed by the DAV server *as* XML, meaning that byte-for-byte equivalence between the input and the stored value is unlikely to be easily achievable. Since an XML fragment can always be escaped (via a CDATA section or what have you) so that it does not get processes as XML by the DAV server's parser, all that is necessary is to define what the server is required to do with property values that are specified as inline XML. In that case, requiring the server to preserve all info items defined by the XML Infoset is probably the strictest reasonable constraint. So, what does that imply about preserving attributes on the property's enclosing element? As I see it, xml:lang and namespace declaration attributes are directly significant, as are any other namespaces in scope. All other attributes are part of the Infoset of the property's XML encoding but are *not* part of the property value itself (how would such an attribute contribute to a Base64 encoded jpeg image property value, for example?). That can all be summed up consistently by saying that a property's value is the Infoset of the property's element content. In the case of a non-XML (plain text) value this is just the text value; for structured XML, that places only reasonable requirements on the DAV server. L. -- http: www.holoweb.net/~zodiac/ | jabber: zodiac(@)jabber!org email: zodiac(@)holoweb!net | icq: #78724820 ----------------------------------------------------------------- condom: general protection error, child process produced. ----- End forwarded message ----- -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Sat Apr 14 06:28:34 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA10665 for ; Sat, 14 Apr 2001 06:28:33 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id GAA25612; Sat, 14 Apr 2001 06:23:52 -0400 (EDT) Resent-Date: Sat, 14 Apr 2001 06:23:52 -0400 (EDT) Resent-Message-Id: <200104141023.GAA25612@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id GAA25550 for ; Sat, 14 Apr 2001 06:23:38 -0400 (EDT) Received: from ns02.sbphrd.com (firewall-user@ns02.sbphrd.com [208.198.64.2]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id GAA04829 for ; Sat, 14 Apr 2001 06:23:37 -0400 Received: by ns02.sbphrd.com; id GAA03599; Sat, 14 Apr 2001 06:23:31 -0400 (EDT) Received: from unknown(139.136.64.5) by ns02.sbphrd.com via smap (V5.0) id xma003562; Sat, 14 Apr 01 06:23:12 -0400 Received: from uksmtp01.ha.uk.sbphrd.com (uksmtp01.ha.uk.sbphrd.com [139.136.216.185]) by phinet.sbphrd.com (8.9.1b+Sun/8.9.1) with ESMTP id GAA03727 for ; Sat, 14 Apr 2001 06:23:31 -0400 (EDT) Received: from lisa ([139.136.54.5]) by uksmtp01.ha.uk.sbphrd.com (Lotus Domino Release 5.0.5) with SMTP id 2001041411230928:3167 ; Sat, 14 Apr 2001 11:23:09 +0100 From: "Julian F. Reschke" To: "WebDAV WG" Date: Sat, 14 Apr 2001 12:23:04 +0200 Message-ID: MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000 In-Reply-To: X-MIMETrack: Itemize by SMTP Server on UKSMTP01/SERVERS/PHRD/SB_PLC(Release 5.0.5 |September 22, 2000) at 14/04/2001 11:23:10, Serialize by Router on UKSMTP01/SERVERS/PHRD/SB_PLC(Release 5.0.5 |September 22, 2000) at 14/04/2001 11:23:12, Serialize complete at 14/04/2001 11:23:12 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii" Subject: RE: Issue: PROP_ATTR Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4794 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jason Crawford > Sent: Friday, April 13, 2001 9:29 PM > To: Kevin Wiggen > Cc: WebDAV WG > Subject: RE: Issue: PROP_ATTR > > ... > > This does lead me to another question though. If in the PROPPATCH call > there are xmlns attributes on the propertyupdate, set, or prop tags that > could potentially affect the tags within the property value, is the server > responsible for collecting those and representing those in PROPPATCH > responses? Or should we require that the client put any xmlns attributes > that it cares about on the propertyname tag and within? I think by choosing XML+Namespaces as transport protocol, WebDAV must adhere to those rules. For the XML Infoset of a request, it makes little difference where a particular namespace declaration occured. From w3c-dist-auth-request@w3.org Sat Apr 14 06:28:37 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA10684 for ; Sat, 14 Apr 2001 06:28:36 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id GAA25582; Sat, 14 Apr 2001 06:23:43 -0400 (EDT) Resent-Date: Sat, 14 Apr 2001 06:23:43 -0400 (EDT) Resent-Message-Id: <200104141023.GAA25582@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id GAA25552 for ; Sat, 14 Apr 2001 06:23:38 -0400 (EDT) Received: from ns02.sbphrd.com (firewall-user@ns02.sbphrd.com [208.198.64.2]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id GAA04830 for ; Sat, 14 Apr 2001 06:23:37 -0400 Received: by ns02.sbphrd.com; id GAA03600; Sat, 14 Apr 2001 06:23:31 -0400 (EDT) Received: from unknown(139.136.64.5) by ns02.sbphrd.com via smap (V5.0) id xma003567; Sat, 14 Apr 01 06:23:16 -0400 Received: from uksmtp01.ha.uk.sbphrd.com (uksmtp01.ha.uk.sbphrd.com [139.136.216.185]) by phinet.sbphrd.com (8.9.1b+Sun/8.9.1) with ESMTP id GAA03738 for ; Sat, 14 Apr 2001 06:23:35 -0400 (EDT) Received: from lisa ([139.136.54.5]) by uksmtp01.ha.uk.sbphrd.com (Lotus Domino Release 5.0.5) with SMTP id 2001041411231315:3168 ; Sat, 14 Apr 2001 11:23:13 +0100 From: "Julian F. Reschke" To: Date: Sat, 14 Apr 2001 12:23:08 +0200 Message-ID: MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000 In-Reply-To: <20010413211653.P31832@lyra.org> X-MIMETrack: Itemize by SMTP Server on UKSMTP01/SERVERS/PHRD/SB_PLC(Release 5.0.5 |September 22, 2000) at 14/04/2001 11:23:14, Serialize by Router on UKSMTP01/SERVERS/PHRD/SB_PLC(Release 5.0.5 |September 22, 2000) at 14/04/2001 11:23:16, Serialize complete at 14/04/2001 11:23:16 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii" Subject: RE: [zodiac@holoweb.net: Re: Issue: PROP_ATTR] Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4793 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: Laurie Harper > Subject: Re: Issue: PROP_ATTR > To: Greg Stein > Date: Thu, 12 Apr 2001 11:38:41 -0400 > > Greg Stein wrote: > > IMO, PROP_ATTR is about defining the boundary between property > naming, and a > > property's value. > > I'd say this is exactly scope of the issue. There is no reason why a > property's value should be considered to be XML just because it is > transported in an XML encoding. But by using XML as transport layer *and* by having examples of DAV: properties that *do* have XML content (for instance , I think there's a strong indication that it actually *is* XML. > The problem is that, if the characters between the property's > start and end > tag *look like* XML then they are likely going to get processed by the DAV > server *as* XML, meaning that byte-for-byte equivalence between the input They need to. > and the stored value is unlikely to be easily achievable. Which shouldn't be an issue. If a client wants to set a dead property and get it back *exactly* as it is, it should send it as a properly escaped text node. > Since an XML fragment can always be escaped (via a CDATA section or what > have you) so that it does not get processes as XML by the DAV server's > parser, all that is necessary is to define what the server is > required to do > with property values that are specified as inline XML. In that case, > requiring the server to preserve all info items defined by the XML Infoset > is probably the strictest reasonable constraint. That doesn't need to be defined at all. All the server will see is a property with one (or more) text nodes. For instance a) ]]> isn't different from b) <collection /> but is completely different from c) For a) and b), PROPFIND will return an escaped string as value, and I wouldn't expect the server to preserve whether it was escaped by CDATA or not. > So, what does that imply about preserving attributes on the property's > enclosing element? As I see it, xml:lang and namespace declaration > attributes are directly significant, as are any other namespaces > in scope. > All other attributes are part of the Infoset of the property's > XML encoding > but are *not* part of the property value itself (how would such Whether those attributes are part of the property's value is exactly the question that needs to be decided. I think both views are valid, we need to choose one. > an attribute > contribute to a Base64 encoded jpeg image property value, for example?). > That can all be summed up consistently by saying that a > property's value is > the Infoset of the property's element content. In the case of a non-XML ...child node content... > (plain text) value this is just the text value; for structured XML, that > places only reasonable requirements on the DAV server. I agree, but the same remains true if we include the attribute nodes... From w3c-dist-auth-request@w3.org Sat Apr 14 06:29:05 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA10706 for ; Sat, 14 Apr 2001 06:29:04 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id GAA25710; Sat, 14 Apr 2001 06:24:28 -0400 (EDT) Resent-Date: Sat, 14 Apr 2001 06:24:28 -0400 (EDT) Resent-Message-Id: <200104141024.GAA25710@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id GAA25642 for ; Sat, 14 Apr 2001 06:24:14 -0400 (EDT) Received: from ns02.sbphrd.com (firewall-user@ns02.sbphrd.com [208.198.64.2]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id GAA04838 for ; Sat, 14 Apr 2001 06:24:13 -0400 Received: by ns02.sbphrd.com; id GAA03680; Sat, 14 Apr 2001 06:24:12 -0400 (EDT) Received: from unknown(139.136.64.5) by ns02.sbphrd.com via smap (V5.0) id xma003658; Sat, 14 Apr 01 06:24:04 -0400 Received: from uksmtp01.ha.uk.sbphrd.com (uksmtp01.ha.uk.sbphrd.com [139.136.216.185]) by phinet.sbphrd.com (8.9.1b+Sun/8.9.1) with ESMTP id GAA03773 for ; Sat, 14 Apr 2001 06:24:23 -0400 (EDT) Received: from lisa ([139.136.54.5]) by uksmtp01.ha.uk.sbphrd.com (Lotus Domino Release 5.0.5) with SMTP id 2001041411240132:3170 ; Sat, 14 Apr 2001 11:24:01 +0100 From: "Julian F. Reschke" To: "WebDAV WG" Date: Sat, 14 Apr 2001 12:23:56 +0200 Message-ID: MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000 In-Reply-To: <20010413134623.M31832@lyra.org> X-MIMETrack: Itemize by SMTP Server on UKSMTP01/SERVERS/PHRD/SB_PLC(Release 5.0.5 |September 22, 2000) at 14/04/2001 11:24:02, Serialize by Router on UKSMTP01/SERVERS/PHRD/SB_PLC(Release 5.0.5 |September 22, 2000) at 14/04/2001 11:24:04, Serialize complete at 14/04/2001 11:24:04 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii" Subject: RE: Issue: PROP_ATTR Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4796 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Greg Stein > Sent: Friday, April 13, 2001 10:46 PM > To: WebDAV WG > Subject: Re: Issue: PROP_ATTR > > > The issue is that provides the name. The stuff inside > that is the > property value. Attributes on the root are associated with the > name, not the > value. We need to define what the value of a property is: a) the Infoset of the child elements of the element node (minus: comments? processing instructions?) b) the Infoset of the property element itself. I'd still prefer b). > Haven't we always tried to use element nesting as a means of structure? > Don't we tend to say that attributes are modifiers for the element they > occur on? Yes, but they still belong to it's XML Infoset. > I'd rather not see attributes on the name supported. On the value, sure. > > Maybe people are thinking that the name element is stored with > the value. I That's certainly a simple way to preserve the attribute information. > see it more as the name is a key, which then maps to the value. > Further, the > name (key) is broken into a tuple of (localpart, namespace-uri, xml:lang), Why do you say that xml:lang is part of the key? That would indicate that Contents Inhalt would set two different properties, which I don't believe is true. > so I don't see it as stored as XML with the rest of the value. > And since it > isn't in XML format, it becomes very difficult to store things such as > attributes. Make the key (namespace-uri, local-name) and the value "XML serialization of the property element", and you're done. > Let's say that you *do* choose to store the name with the XML > value. How do > you manage the namespace and xml:lang. Does the property always have to > store a private namespace to ensure that you don't get prefix clashes? For > example: > > value > > (as opposed to collecting a union of all namespace prefixes and > placing them > on a higher element) I'd say that's absolutely up to the implementation. You just have to make sure that upon PROPFIND, all element's appear in their original namespace. > In the store-with-value approach, you're duplicating the data from the key > to the value. Maybe the word "normalization" is too loud in my > head :-), but > I prefer not to do that. Actually, it would avoid having xml:lang as part of the key, which IMHO is wrong. From w3c-dist-auth-request@w3.org Sat Apr 14 06:29:08 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA10717 for ; Sat, 14 Apr 2001 06:29:07 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id GAA25750; Sat, 14 Apr 2001 06:24:37 -0400 (EDT) Resent-Date: Sat, 14 Apr 2001 06:24:37 -0400 (EDT) Resent-Message-Id: <200104141024.GAA25750@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id GAA25644 for ; Sat, 14 Apr 2001 06:24:15 -0400 (EDT) Received: from ns02.sbphrd.com (firewall-user@ns02.sbphrd.com [208.198.64.2]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id GAA04839 for ; Sat, 14 Apr 2001 06:24:13 -0400 Received: by ns02.sbphrd.com; id GAA03682; Sat, 14 Apr 2001 06:24:12 -0400 (EDT) Received: from unknown(139.136.64.5) by ns02.sbphrd.com via smap (V5.0) id xma003663; Sat, 14 Apr 01 06:24:07 -0400 Received: from uksmtp01.ha.uk.sbphrd.com (uksmtp01.ha.uk.sbphrd.com [139.136.216.185]) by phinet.sbphrd.com (8.9.1b+Sun/8.9.1) with ESMTP id GAA03778 for ; Sat, 14 Apr 2001 06:24:26 -0400 (EDT) Received: from lisa ([139.136.54.5]) by uksmtp01.ha.uk.sbphrd.com (Lotus Domino Release 5.0.5) with SMTP id 2001041411240461:3171 ; Sat, 14 Apr 2001 11:24:04 +0100 From: "Julian F. Reschke" To: Date: Sat, 14 Apr 2001 12:24:00 +0200 Message-ID: MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000 In-Reply-To: X-MIMETrack: Itemize by SMTP Server on UKSMTP01/SERVERS/PHRD/SB_PLC(Release 5.0.5 |September 22, 2000) at 14/04/2001 11:24:05, Serialize by Router on UKSMTP01/SERVERS/PHRD/SB_PLC(Release 5.0.5 |September 22, 2000) at 14/04/2001 11:24:07, Serialize complete at 14/04/2001 11:24:07 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii" Subject: RE: Issue: PROP_ATTR Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4797 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jim Amsden > Sent: Saturday, April 14, 2001 12:21 AM > To: w3c-dist-auth@w3c.org > Subject: Re: Issue: PROP_ATTR > > > I agree with Greg. One clarification. The property name may need a > namespace too. In this case, the usual XML rules should apply. Define a > namespace for the name. WebDAV specifies what this means: replace the > namespace prefix with it namespace value and concatenate it to > the front of Which contradicts the namespace spec and as far as I understand will be removed from the RFC. Namespace name and local name NEVER should be concatenated (that is, without well-defined delimiters), they are a pair, that's it (see issue "XML_NS"). > the property name to create the key. This rule however DOES NOT APPLY to > the value. It is up to the application to determine how to handle the > namespace and prefix for the value. If the value doesn't specify a > different namespace, again the usual XML rules apply and the property name > namespace is also applied to element tags in the value, if they use the > prefix. If this is not what is desired, the clients can put a different > namespace on the value. What you say is that namespaces within the contents of a property should behave as defined in the XML namespaces recommendation, right? > The only issues is what does the server store for the property key? The > name after prefix substitution? The namespace and prefix so they can be > reconstructed on a PROPFIND? I think the server needs to store all > namespace information on the property name because WebDAV says propery > names are XML tags. > > On storing the property name (key) with the value: if its in the value, > store it with the value. If not, don't. That's an implementation issue, not a specification issue, correct? From w3c-dist-auth-request@w3.org Sat Apr 14 06:29:23 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA10728 for ; Sat, 14 Apr 2001 06:29:23 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id GAA25782; Sat, 14 Apr 2001 06:24:48 -0400 (EDT) Resent-Date: Sat, 14 Apr 2001 06:24:48 -0400 (EDT) Resent-Message-Id: <200104141024.GAA25782@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id GAA25730 for ; Sat, 14 Apr 2001 06:24:34 -0400 (EDT) Received: from ns02.sbphrd.com (firewall-user@ns02.sbphrd.com [208.198.64.2]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id GAA04891 for ; Sat, 14 Apr 2001 06:24:33 -0400 Received: by ns02.sbphrd.com; id GAA03747; Sat, 14 Apr 2001 06:24:32 -0400 (EDT) Received: from unknown(139.136.64.5) by ns02.sbphrd.com via smap (V5.0) id xma003706; Sat, 14 Apr 01 06:24:13 -0400 Received: from uksmtp01.ha.uk.sbphrd.com (uksmtp01.ha.uk.sbphrd.com [139.136.216.185]) by phinet.sbphrd.com (8.9.1b+Sun/8.9.1) with ESMTP id GAA03801 for ; Sat, 14 Apr 2001 06:24:32 -0400 (EDT) Received: from lisa ([139.136.54.5]) by uksmtp01.ha.uk.sbphrd.com (Lotus Domino Release 5.0.5) with SMTP id 2001041411241043:3172 ; Sat, 14 Apr 2001 11:24:10 +0100 From: "Julian F. Reschke" To: "WebDAV WG" Date: Sat, 14 Apr 2001 12:24:06 +0200 Message-ID: MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000 In-Reply-To: <3906C56A7BD1F54593344C05BD1374B1018E235C@SUS-MA1IT01> X-MIMETrack: Itemize by SMTP Server on UKSMTP01/SERVERS/PHRD/SB_PLC(Release 5.0.5 |September 22, 2000) at 14/04/2001 11:24:11, Serialize by Router on UKSMTP01/SERVERS/PHRD/SB_PLC(Release 5.0.5 |September 22, 2000) at 14/04/2001 11:24:13, Serialize complete at 14/04/2001 11:24:13 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Issue: PROP_ATTR Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4798 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Sounds good. > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff > Sent: Friday, April 13, 2001 8:35 PM > To: WebDAV WG > Subject: RE: Issue: PROP_ATTR > > > For dead properties, I don't see the issue wrt storing attribute values > for the root element. If you are storing attributes on all the nested > elements (as I believe everyone has agreed), it should be trivial > to store it on the root element as well. > > For live properties, where the server can take advantage of its knowledge > of the value space for the live property values, then I agree that it > could be an issue. > > So I still prefer saying MUST on all attributes of dead properties, > and "as specified in the property definition" for live properties. > > Cheers, > Geoff > > -----Original Message----- > From: Kevin Wiggen [mailto:wiggs@wiggenout.com] > Sent: Friday, April 13, 2001 12:02 PM > To: Greg Stein; WebDAV WG > Subject: RE: Issue: PROP_ATTR > > > > I agree with Greg et all that "attr2" needs to be stored. > > I believe that allowing "attr1" could lead to some interop problems, or we > need to spec this out a little better: > > > > > > > > Is that legal? Does the attribute make the property unique? Does simply > the value of an attribute make it unique? Or do we (like xmllang) simply > store one set of attributes for a property? > > Also how does one use Dasl with attributes on properties? > > I would like to see attributes on the property name not be supported. > > Kevin > > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Greg Stein > Sent: Wednesday, April 11, 2001 1:06 AM > To: WebDAV WG > Subject: Re: Issue: PROP_ATTR > > > The question isn't about attributes in general, it is about *which* > attributes. Consider the following: > > > > thevalue > > > > > I believe everybody would agree that attr2 gets stored. The real > question is > about attr1. I see that attribute as part of the element that *names* a > property, but it isn't part of the property *value*. > > IMO, PROP_ATTR is about defining the boundary between property > naming, and a > property's value. > > Cheers, > -g > > On Tue, Apr 10, 2001 at 10:58:21PM -0700, Eric Sedlar wrote: > > I agree. There is no reason not to persist attributes. > > > > > -----Original Message----- > > > From: w3c-dist-auth-request@w3.org > > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Mark A. Hale > > > Sent: Tuesday, April 10, 2001 6:29 PM > > > To: WebDAV WG > > > Subject: RE: Issue: PROP_ATTR > > > > > > > > > Jim: Thanks for getting the issues list started. > > > > > > I believe that WebDAV must permit properties to have attributes. > > > As you've > > > pointed out, RDF and PRISM do use them extensively. A server can > reformat > > > the attributes in a subsequent PROPFIND request. Attrbiutes should be > > > persistent. > > > > > > Thanks, > > > > > > Mark > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: w3c-dist-auth-request@w3.org > > > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jim Whitehead > > > > Sent: Tuesday, April 10, 2001 5:54 PM > > > > To: WebDAV WG > > > > Subject: Issue: PROP_ATTR > > > > > > > > > > > > As mentioned in a previous post, now is the time to start > > > resolving issues > > > > on the RFC 2518 issues list. As fate would have it, the first > > > > issue on the > > > > list is one that has been contentious in the past. Can we come to > > > > consensus > > > > on it now? > > > > > > > > Issue: PROP_ATTR > > > > > > > > Description: > > > > > > > > What is a WebDAV server required to do with XML attributes > other than > > > > xml:lang submitted with a PROPPATCH? This affects how well > > > WebDAV will be > > > > able to support RDF, since RDF uses attributes extensively. > > > > > > > > Greg Stein originally raised this issue: > > > > > > > > > http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0089.html > > > > > > > > See also: > > > > > > > > > http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0092.html > > > > > http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0094.html > > > > > http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0095.html > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > Greg Stein, http://www.lyra.org/ > From w3c-dist-auth-request@w3.org Sat Apr 14 06:39:48 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA10667 for ; Sat, 14 Apr 2001 06:28:33 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id GAA25678; Sat, 14 Apr 2001 06:24:19 -0400 (EDT) Resent-Date: Sat, 14 Apr 2001 06:24:19 -0400 (EDT) Resent-Message-Id: <200104141024.GAA25678@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id GAA25634 for ; Sat, 14 Apr 2001 06:24:13 -0400 (EDT) Received: from ns02.sbphrd.com (firewall-user@ns02.sbphrd.com [208.198.64.2]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id GAA04835 for ; Sat, 14 Apr 2001 06:24:12 -0400 Received: by ns02.sbphrd.com; id GAA03679; Sat, 14 Apr 2001 06:24:12 -0400 (EDT) Received: from unknown(139.136.64.5) by ns02.sbphrd.com via smap (V5.0) id xma003649; Sat, 14 Apr 01 06:24:00 -0400 Received: from uksmtp01.ha.uk.sbphrd.com (uksmtp01.ha.uk.sbphrd.com [139.136.216.185]) by phinet.sbphrd.com (8.9.1b+Sun/8.9.1) with ESMTP id GAA03768 for ; Sat, 14 Apr 2001 06:24:19 -0400 (EDT) Received: from lisa ([139.136.54.5]) by uksmtp01.ha.uk.sbphrd.com (Lotus Domino Release 5.0.5) with SMTP id 2001041411235806:3169 ; Sat, 14 Apr 2001 11:23:58 +0100 From: "Julian F. Reschke" To: "WebDAV WG" Date: Sat, 14 Apr 2001 12:23:54 +0200 Message-ID: MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000 In-Reply-To: X-MIMETrack: Itemize by SMTP Server on UKSMTP01/SERVERS/PHRD/SB_PLC(Release 5.0.5 |September 22, 2000) at 14/04/2001 11:23:59, Serialize by Router on UKSMTP01/SERVERS/PHRD/SB_PLC(Release 5.0.5 |September 22, 2000) at 14/04/2001 11:24:00, Serialize complete at 14/04/2001 11:24:00 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii" Subject: RE: Issue: PROP_ATTR Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4795 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Kevin Wiggen > Sent: Friday, April 13, 2001 6:02 PM > To: Greg Stein; WebDAV WG > Subject: RE: Issue: PROP_ATTR > > > > I agree with Greg et all that "attr2" needs to be stored. > > I believe that allowing "attr1" could lead to some interop problems, or we > need to spec this out a little better: > > > > > > > > Is that legal? Does the attribute make the property unique? Does simply No, it doesn't. If the language in section 4.5 () isn't clear enough on that, it should be enhanced. > the value of an attribute make it unique? Or do we (like xmllang) simply > store one set of attributes for a property? Who does? RFC2518 says that xml:lang must be preserved, but it doesn't say that there may be multiple copies of the property with different language values (). > Also how does one use Dasl with attributes on properties? > > I would like to see attributes on the property name not be supported. I might agree, but not for the reasons given here. From w3c-dist-auth-request@w3.org Sat Apr 14 20:03:29 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA15402 for ; Sat, 14 Apr 2001 20:03:29 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id TAA12896; Sat, 14 Apr 2001 19:56:47 -0400 (EDT) Resent-Date: Sat, 14 Apr 2001 19:56:47 -0400 (EDT) Resent-Message-Id: <200104142356.TAA12896@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id TAA12843 for ; Sat, 14 Apr 2001 19:56:33 -0400 (EDT) Received: from kurgan.lyra.org (test.webdav.org [198.144.203.199]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id TAA23405 for ; Sat, 14 Apr 2001 19:56:31 -0400 Received: (from gstein@localhost) by kurgan.lyra.org (8.9.3/8.9.3) id QAA10785 for w3c-dist-auth@w3.org; Sat, 14 Apr 2001 16:58:17 -0700 X-Authentication-Warning: kurgan.lyra.org: gstein set sender to gstein@lyra.org using -f Date: Sat, 14 Apr 2001 16:58:17 -0700 From: Greg Stein To: WebDAV WG Message-ID: <20010414165816.X31832@lyra.org> Mail-Followup-To: WebDAV WG References: <20010413134623.M31832@lyra.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from julian.reschke@greenbytes.de on Sat, Apr 14, 2001 at 12:23:56PM +0200 X-URL: http://www.lyra.org/greg/ Subject: Re: Issue: PROP_ATTR Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4799 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: On Sat, Apr 14, 2001 at 12:23:56PM +0200, Julian F. Reschke wrote: >... > > see it more as the name is a key, which then maps to the value. > > Further, the > > name (key) is broken into a tuple of (localpart, namespace-uri, xml:lang), > > Why do you say that xml:lang is part of the key? That would indicate that Sorry... I didn't mean to imply that. I meant that the name element has three useful pieces of information, which must be recorded. As you suggest, only the localpart and URI are the "key". The xml:lang is effectively part of the value. [ this is how it is implemented in mod_dav today ] >... > > so I don't see it as stored as XML with the rest of the value. > > And since it > > isn't in XML format, it becomes very difficult to store things such as > > attributes. > > Make the key (namespace-uri, local-name) and the value "XML serialization of > the property element", and you're done. I maintain that it should be the serialization of the contents of the name element, but exclude the name element itself. For example: contents In the above example, I see the value as 'contents' (mod_dav actually preserves whitespace; I just omitted it here for clarity). Further, there may be an xml:lang that applies to the "scope" that the property value occurs within. The name is separate, and is a tuple of (localpart, namespace-URI). I believe this is the appropriate interpretation; the element (and any attributes on it) are the name, not the value. > > Let's say that you *do* choose to store the name with the XML > > value. How do > > you manage the namespace and xml:lang. Does the property always have to > > store a private namespace to ensure that you don't get prefix clashes? For > > example: > > > > value > > > > (as opposed to collecting a union of all namespace prefixes and > > placing them > > on a higher element) > > I'd say that's absolutely up to the implementation. You just have to make > sure that upon PROPFIND, all element's appear in their original namespace. I completely agree. My point is that it is more difficult for server implementors if you want to state that the attributes on the name element are part of the property value, and (thus) need to be stored. Cheers, -g -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Sat Apr 14 21:48:54 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA16715 for ; Sat, 14 Apr 2001 21:48:53 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id UAA13611; Sat, 14 Apr 2001 20:24:46 -0400 (EDT) Resent-Date: Sat, 14 Apr 2001 20:24:46 -0400 (EDT) Resent-Message-Id: <200104150024.UAA13611@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id UAA13591 for ; Sat, 14 Apr 2001 20:24:41 -0400 (EDT) Received: from kurgan.lyra.org (test.webdav.org [198.144.203.199]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id UAA25073 for ; Sat, 14 Apr 2001 20:24:41 -0400 Received: (from gstein@localhost) by kurgan.lyra.org (8.9.3/8.9.3) id RAA10800; Sat, 14 Apr 2001 17:26:34 -0700 X-Authentication-Warning: kurgan.lyra.org: gstein set sender to gstein@lyra.org using -f Date: Sat, 14 Apr 2001 17:26:33 -0700 From: Greg Stein To: "Julian F. Reschke" Cc: w3c-dist-auth@w3c.org Message-ID: <20010414172633.Y31832@lyra.org> Mail-Followup-To: "Julian F. Reschke" , w3c-dist-auth@w3c.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from julian.reschke@greenbytes.de on Sat, Apr 14, 2001 at 12:24:00PM +0200 X-URL: http://www.lyra.org/greg/ Subject: Re: Issue: PROP_ATTR Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4800 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: On Sat, Apr 14, 2001 at 12:24:00PM +0200, Julian F. Reschke wrote: > > From: w3c-dist-auth-request@w3.org > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jim Amsden > > Sent: Saturday, April 14, 2001 12:21 AM > > To: w3c-dist-auth@w3c.org > > Subject: Re: Issue: PROP_ATTR > > > > I agree with Greg. One clarification. The property name may need a > > namespace too. In this case, the usual XML rules should apply. Define a > > namespace for the name. WebDAV specifies what this means: replace the > > namespace prefix with it namespace value and concatenate it to > > the front of > > Which contradicts the namespace spec and as far as I understand will be > removed from the RFC. Namespace name and local name NEVER should be > concatenated Actually, it doesn't contradict the namespace spec. The spec is silent on the issue of how to handle the URI and the localpart when used as an identifier or key. In practice, everybody uses them as a tuple. However, before this practice was really "observed", RFC 2518 took the position of concatenation. [ the WebDAV final draft went to the RFC Editor before XML Namespaces were finalized, and certainly before standard practices were identified ] > (that is, without well-defined delimiters), they are a pair, > that's it (see issue "XML_NS"). Yes, RFC 2518 will be changing to that interpretation for a number of reasons. Cheers, -g -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Sun Apr 15 05:20:07 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA07931 for ; Sun, 15 Apr 2001 05:20:07 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id FAA23516; Sun, 15 Apr 2001 05:15:06 -0400 (EDT) Resent-Date: Sun, 15 Apr 2001 05:15:06 -0400 (EDT) Resent-Message-Id: <200104150915.FAA23516@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id FAA23495 for ; Sun, 15 Apr 2001 05:15:00 -0400 (EDT) Received: from ns02.sbphrd.com (firewall-user@ns02.sbphrd.com [208.198.64.2]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id FAA30344 for ; Sun, 15 Apr 2001 05:15:00 -0400 Received: by ns02.sbphrd.com; id FAA15495; Sun, 15 Apr 2001 05:14:52 -0400 (EDT) Received: from unknown(139.136.64.5) by ns02.sbphrd.com via smap (V5.0) id xma015482; Sun, 15 Apr 01 05:14:44 -0400 Received: from uksmtp01.ha.uk.sbphrd.com (uksmtp01.ha.uk.sbphrd.com [139.136.216.185]) by phinet.sbphrd.com (8.9.1b+Sun/8.9.1) with ESMTP id FAA24946; Sun, 15 Apr 2001 05:15:03 -0400 (EDT) Received: from lisa ([139.136.54.7]) by uksmtp01.ha.uk.sbphrd.com (Lotus Domino Release 5.0.5) with SMTP id 2001041510144024:3515 ; Sun, 15 Apr 2001 10:14:40 +0100 From: "Julian F. Reschke" To: "Greg Stein" , "WebDAV WG" Date: Sun, 15 Apr 2001 11:14:33 +0200 Message-ID: MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <20010414165816.X31832@lyra.org> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000 X-MIMETrack: Itemize by SMTP Server on UKSMTP01/SERVERS/PHRD/SB_PLC(Release 5.0.5 |September 22, 2000) at 15/04/2001 10:14:42, Serialize by Router on UKSMTP01/SERVERS/PHRD/SB_PLC(Release 5.0.5 |September 22, 2000) at 15/04/2001 10:14:44, Serialize complete at 15/04/2001 10:14:44 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii" Subject: RE: Issue: PROP_ATTR Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4801 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Greg Stein > Sent: Sunday, April 15, 2001 1:58 AM > To: WebDAV WG > Subject: Re: Issue: PROP_ATTR > > > On Sat, Apr 14, 2001 at 12:23:56PM +0200, Julian F. Reschke wrote: > >... > > > see it more as the name is a key, which then maps to the value. > > > Further, the > > > name (key) is broken into a tuple of (localpart, > namespace-uri, xml:lang), > > > > Why do you say that xml:lang is part of the key? That would > indicate that > > Sorry... I didn't mean to imply that. I meant that the name element has > three useful pieces of information, which must be recorded. As > you suggest, > only the localpart and URI are the "key". The xml:lang is effectively part > of the value. > [ this is how it is implemented in mod_dav today ] > >... > > > so I don't see it as stored as XML with the rest of the value. > > > And since it > > > isn't in XML format, it becomes very difficult to store things such as > > > attributes. > > > > Make the key (namespace-uri, local-name) and the value "XML > serialization of > > the property element", and you're done. > > I maintain that it should be the serialization of the contents of the name > element, but exclude the name element itself. For example: > > > > contents > > > > > In the above example, I see the value as 'contents' > (mod_dav actually preserves whitespace; I just omitted it here > for clarity). > > Further, there may be an xml:lang that applies to the "scope" that the > property value occurs within. The name is separate, and is a tuple of > (localpart, namespace-URI). > > I believe this is the appropriate interpretation; the > element (and > any attributes on it) are the name, not the value. As I said, both point of views are possible. However, your position seems to be: value = Infoset of all child elements *plus* the optional xml:lang attribute How do you put the value of xml:lang into the serialization of the element's contents? Sure, that's again an implementation issue, but including the element itself certainly makes it easier. > My point is that it is more difficult for server implementors if > you want to > state that the attributes on the name element are part of the property > value, and (thus) need to be stored. While my point is that it makes absolutely no difference at all :-) Maybe we need to collect all issues regarding this topic before going back to this one. For instance, if somebody would want to store an XSLT or an XSD schema as a property value, he probably would expect that namespace prefix information is preserved as well... Julian From w3c-dist-auth-request@w3.org Sun Apr 15 16:58:04 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA11634 for ; Sun, 15 Apr 2001 16:58:04 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA09084; Sun, 15 Apr 2001 16:52:09 -0400 (EDT) Resent-Date: Sun, 15 Apr 2001 16:52:09 -0400 (EDT) Resent-Message-Id: <200104152052.QAA09084@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id QAA09054 for ; Sun, 15 Apr 2001 16:52:05 -0400 (EDT) Received: from kurgan.lyra.org (kurgan.lyra.org [198.144.203.198]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id QAA08068 for ; Sun, 15 Apr 2001 16:52:04 -0400 Received: (from gstein@localhost) by kurgan.lyra.org (8.9.3/8.9.3) id NAA28905 for w3c-dist-auth@w3.org; Sun, 15 Apr 2001 13:54:00 -0700 X-Authentication-Warning: kurgan.lyra.org: gstein set sender to gstein@lyra.org using -f Date: Sun, 15 Apr 2001 13:54:00 -0700 From: Greg Stein To: WebDAV WG Message-ID: <20010415135400.D31832@lyra.org> Mail-Followup-To: WebDAV WG References: <20010414165816.X31832@lyra.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from julian.reschke@greenbytes.de on Sun, Apr 15, 2001 at 11:14:33AM +0200 X-URL: http://www.lyra.org/greg/ Subject: Re: Issue: PROP_ATTR Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4803 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: On Sun, Apr 15, 2001 at 11:14:33AM +0200, Julian F. Reschke wrote: >... > As I said, both point of views are possible. However, your position seems to > be: > > value = Infoset of all child elements *plus* the optional xml:lang attribute Yes, because the xml:lang value is scoped, and the property value occurs within that scope. And this isn't just because xml:lang occurs on the property name element; it could be three levels higher in scope. > How do you put the value of xml:lang into the serialization of the element's > contents? Sure, that's again an implementation issue, but including the > element itself certainly makes it easier. Nope. It could occur higher in scope, so it might not be on the property name element at all. Thus, serializing the name isn't going to help with preserving the xml:lang value. I store the xml:lang and the (serialized) value as two items of data in the property database. > > My point is that it is more difficult for server implementors if > > you want to > > state that the attributes on the name element are part of the property > > value, and (thus) need to be stored. > > While my point is that it makes absolutely no difference at all :-) As an implementor of a server, I would disagree :-) I just want to see the language state something to the effect of: all attributes on elements, which are children of the name element, MUST be preserved; attributes on the name element MAY be preserved. [ plus the language about xml:lang ] > Maybe we need to collect all issues regarding this topic before going back > to this one. For instance, if somebody would want to store an XSLT or an XSD > schema as a property value, he probably would expect that namespace prefix > information is preserved as well... They're SOL with (at least) mod_dav. It doesn't preserve prefixes. That is potentially another issue for the RFC 2518 issues list (I have an opinion, but that can occur under a separate issue thread). Cheers, -g -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Sun Apr 15 17:23:56 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA11633 for ; Sun, 15 Apr 2001 16:58:04 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA09020; Sun, 15 Apr 2001 16:51:03 -0400 (EDT) Resent-Date: Sun, 15 Apr 2001 16:51:03 -0400 (EDT) Resent-Message-Id: <200104152051.QAA09020@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id QAA08996 for ; Sun, 15 Apr 2001 16:50:58 -0400 (EDT) Received: from sus-ma1it00.rational.com (ext-37140.rational.com [192.229.37.140]) by tux.w3.org (8.9.3/8.9.3) with SMTP id QAA08001 for ; Sun, 15 Apr 2001 16:50:58 -0400 Received: from 192.168.215.70 by sus-ma1it00.rational.com (InterScan E-Mail VirusWall NT); Sun, 15 Apr 2001 16:52:29 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Sun, 15 Apr 2001 16:52:29 -0400 Message-ID: <3906C56A7BD1F54593344C05BD1374B102A75F13@SUS-MA1IT01> From: "Clemm, Geoff" To: WebDAV WG Date: Sun, 15 Apr 2001 16:50:17 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: RE: Issue: WRITE_DAV_PROP Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4802 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: From: Greg Stein [mailto:gstein@lyra.org] I'm also a bit leery of the getcontentlanguage and getcontenttype being a MUST. I'd prefer those be a MAY, and displayname and source remain as MUST. The basic problem with the language/type is needing to look them up for each GET from the server. That can seriously impact server performance. Another client might have deleted the resource and created a new one in the same location (with different contentlanguage and contenttype) between the two GET's, so whether or not getcontentlanguage and getcontenttype or mutable is irrelevant for this issue, isn't it? Cheers, Geoff From w3c-dist-auth-request@w3.org Sun Apr 15 19:16:23 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA12537 for ; Sun, 15 Apr 2001 19:16:20 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id TAA12171; Sun, 15 Apr 2001 19:10:23 -0400 (EDT) Resent-Date: Sun, 15 Apr 2001 19:10:23 -0400 (EDT) Resent-Message-Id: <200104152310.TAA12171@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id TAA12147 for ; Sun, 15 Apr 2001 19:10:18 -0400 (EDT) Received: from mail.gmx.net (pop.gmx.net [194.221.183.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id TAA16914 for ; Sun, 15 Apr 2001 19:10:18 -0400 Received: (qmail 26039 invoked by uid 0); 15 Apr 2001 23:09:44 -0000 Received: from pd950c29b.dip.t-dialin.net (HELO lisa) (217.80.194.155) by mail.gmx.net (mp020-rz3) with SMTP; 15 Apr 2001 23:09:44 -0000 From: "Julian F. Reschke" To: "Greg Stein" , "WebDAV WG" Date: Mon, 16 Apr 2001 01:09:43 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000 In-reply-to: <20010415135400.D31832@lyra.org> Importance: Normal Subject: RE: Issue: PROP_ATTR Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4804 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Greg Stein > Sent: Sunday, April 15, 2001 10:54 PM > To: WebDAV WG > Subject: Re: Issue: PROP_ATTR > > > How do you put the value of xml:lang into the serialization of > the element's > > contents? Sure, that's again an implementation issue, but including the > > element itself certainly makes it easier. > > Nope. It could occur higher in scope, so it might not be on the property > name element at all. Thus, serializing the name isn't going to help with > preserving the xml:lang value. Well, it can if you just replicate the xml:lang value "into" the property element. From w3c-dist-auth-request@w3.org Mon Apr 16 08:31:04 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA02862 for ; Mon, 16 Apr 2001 08:31:03 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id IAA25385; Mon, 16 Apr 2001 08:25:46 -0400 (EDT) Resent-Date: Mon, 16 Apr 2001 08:25:46 -0400 (EDT) Resent-Message-Id: <200104161225.IAA25385@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id IAA25365 for ; Mon, 16 Apr 2001 08:25:41 -0400 (EDT) Received: from mail.gmx.net (pop.gmx.net [194.221.183.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id IAA02683 for ; Mon, 16 Apr 2001 08:25:41 -0400 Received: (qmail 28494 invoked by uid 0); 16 Apr 2001 12:25:08 -0000 Received: from p3ee2467d.dip.t-dialin.net (HELO lisa) (62.226.70.125) by mail.gmx.net (mp026-rz3) with SMTP; 16 Apr 2001 12:25:08 -0000 From: "Julian F. Reschke" To: "WebDAV WG" Date: Mon, 16 Apr 2001 14:25:07 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000 In-reply-to: <20010415135400.D31832@lyra.org> Importance: Normal Subject: RE: Issue: PROP_ATTR Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4805 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Greg Stein > Sent: Sunday, April 15, 2001 10:54 PM > To: WebDAV WG > Subject: Re: Issue: PROP_ATTR > > > On Sun, Apr 15, 2001 at 11:14:33AM +0200, Julian F. Reschke wrote: > >... > > As I said, both point of views are possible. However, your > position seems to > > be: > > > > value = Infoset of all child elements *plus* the optional > xml:lang attribute > > Yes, because the xml:lang value is scoped, and the property value occurs > within that scope. > > And this isn't just because xml:lang occurs on the property name > element; it > could be three levels higher in scope. I've got a concern here... RFC2518 makes a special case for xml:lang, which I think is a bad thing. "Canonical XML" [1][2] specifies rules for generating canonical representations of document subsets (which seems to be relevant to our problem), and it states that *all* attributes in the xml namespace are inherited (as of today, this would include xml:space as well). Also note that other working groups might be adding more attributes to the xml namespace, such as xml:base [3]. I think it should be considered to either drop the requirement to persist xml:lang with the property value, or to extend the requirement so that all attributes from the xml namespace [4] are treated equally. Julian [1] , [2] , [3] , [4] From w3c-dist-auth-request@w3.org Mon Apr 16 10:42:12 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA04912 for ; Mon, 16 Apr 2001 10:42:12 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id KAA29581; Mon, 16 Apr 2001 10:40:13 -0400 (EDT) Resent-Date: Mon, 16 Apr 2001 10:40:13 -0400 (EDT) Resent-Message-Id: <200104161440.KAA29581@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id KAA29560 for ; Mon, 16 Apr 2001 10:40:08 -0400 (EDT) Received: from mail.gmx.net (pop.gmx.net [194.221.183.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id KAA12298 for ; Mon, 16 Apr 2001 10:40:06 -0400 Received: (qmail 12631 invoked by uid 0); 16 Apr 2001 14:40:00 -0000 Received: from p3ee2467d.dip.t-dialin.net (HELO lisa) (62.226.70.125) by mail.gmx.net (mp012-rz3) with SMTP; 16 Apr 2001 14:40:00 -0000 From: "Julian F. Reschke" To: "WebDAV WG" Date: Mon, 16 Apr 2001 16:39:58 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000 In-reply-to: Importance: Normal Subject: RE: Issue: PROP_ATTR Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4807 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Kevin Wiggen > Sent: Monday, April 16, 2001 4:30 PM > To: Greg Stein; WebDAV WG > Subject: RE: Issue: PROP_ATTR > ... > >They're SOL with (at least) mod_dav. It doesn't preserve > prefixes. That is > >potentially another issue for the RFC 2518 issues list (I have > an opinion, > >but that can occur under a separate issue thread). > > DAV servers cannot preserve the namespace prefix. What would What do you mean by "cannot"? Preserving something doesn't necessarily mean that it needs to contribute to the property's uniquess criteria (like xml:lang). > happen if two > proppatch's told the same resource to store properties with the same > prefixes but differing namespaces? When the server went to > output info on a > propfind, it would not be consistent. I think this is a misunderstatement. We were talking about prefix preservation *inside* property values, like: ... However, whether the prefix of the property *itself* needs to be preserved (although it does not contribute to the key) is yet another open question... Julian From w3c-dist-auth-request@w3.org Mon Apr 16 13:18:38 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA08867 for ; Mon, 16 Apr 2001 13:18:38 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA09027; Mon, 16 Apr 2001 13:07:15 -0400 (EDT) Resent-Date: Mon, 16 Apr 2001 13:07:15 -0400 (EDT) Resent-Message-Id: <200104161707.NAA09027@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id NAA09003 for ; Mon, 16 Apr 2001 13:07:11 -0400 (EDT) Received: from dirk.holoweb.net (dirk2.holoweb.net [216.94.134.20]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id NAA25246 for ; Mon, 16 Apr 2001 13:07:10 -0400 Received: from holoweb.net ([216.94.134.192]) by dirk.holoweb.net (8.9.3/8.9.3) with ESMTP id NAA64085 for ; Mon, 16 Apr 2001 13:07:08 -0400 (EDT) (envelope-from zodiac@holoweb.net) Message-ID: <3ADB27BE.A528C26F@holoweb.net> Date: Mon, 16 Apr 2001 13:11:26 -0400 From: Laurie Harper X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.5-15 i686) X-Accept-Language: en MIME-Version: 1.0 To: w3c-dist-auth@w3.org References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [zodiac@holoweb.net: Re: Issue: PROP_ATTR] Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4808 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit "Julian F. Reschke" wrote: > But by using XML as transport layer *and* by having examples of DAV: > properties that *do* have XML content (for instance , I > think there's a strong indication that it actually *is* XML. No, there's a strong indication that the *representation* is XML but the semantics of the value are wholy outside of the scope of WebDAV. That means it's important not to impose artifacts of the transport encoding on the meaning of the term property value. > > server *as* XML, meaning that byte-for-byte equivalence between the input > > and the stored value is unlikely to be easily achievable. > Which shouldn't be an issue. If a client wants to set a dead property and > get it back *exactly* as it is, it should send it as a properly escaped text > node. Exactly, yes. That leaves the issue of defining what will and what will not be preserved in the case where the value is encoded as an XML fragment. If it's not going to be a byte-for-byte equivalence, what *is* it going to be? > That doesn't need to be defined at all. All the server will see is a > property with one (or more) text nodes. For instance > a) ]]> > isn't different from > b) <collection /> > but is completely different from > c) > For a) and b), PROPFIND will return an escaped string as value, and I > wouldn't expect the server to preserve whether it was escaped by CDATA or > not. I agree, w.r.t. a) and b). What I'm after is clarification for case c), preferably based on the Infoset definitions. > Whether those attributes are part of the property's value is exactly the > question that needs to be decided. I think both views are valid, we need to > choose one. > I agree, but the same remains true if we include the attribute nodes... I'm suggesting that they are part of the XML encoding of the property, not part of the property value -- an artifact of the encoding that can be resolved by exclusion. I also wasn't clear or explicit enough in identifying my other issue -- defining what a property's value is when expressed as 'in line' XML. L. -- http: www.holoweb.net/~zodiac/ | jabber: zodiac(@)jabber!org email: zodiac(@)holoweb!net | icq: #78724820 ----------------------------------------------------------------- condom: general protection error, child process produced. From w3c-dist-auth-request@w3.org Mon Apr 16 13:28:47 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA09241 for ; Mon, 16 Apr 2001 13:28:43 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA09252; Mon, 16 Apr 2001 13:16:32 -0400 (EDT) Resent-Date: Mon, 16 Apr 2001 13:16:32 -0400 (EDT) Resent-Message-Id: <200104161716.NAA09252@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id NAA09232 for ; Mon, 16 Apr 2001 13:16:27 -0400 (EDT) Received: from cats.ucsc.edu (rumpleteazer.ucsc.edu [128.114.129.45]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id NAA26107 for ; Mon, 16 Apr 2001 13:16:26 -0400 Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177]) by cats.ucsc.edu (8.9.3/8.8.4.cats-athena) with SMTP id KAA25623 for ; Mon, 16 Apr 2001 10:16:27 -0700 (PDT) From: "Jim Whitehead" To: "WebDAV WG" Date: Mon, 16 Apr 2001 10:14:56 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <3906C56A7BD1F54593344C05BD1374B102A75F13@SUS-MA1IT01> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Subject: RE: Issue: WRITE_DAV_PROP Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4809 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: Greg Stein [mailto:gstein@lyra.org] > > I'm also a bit leery of the getcontentlanguage and getcontenttype > being a MUST. I'd prefer those be a MAY, and displayname and source > remain as MUST. The basic problem with the language/type is > needing to look them up for each GET from the server. That can > seriously impact server performance. > Geoff Clemm responds: > Another client might have deleted the resource and created a new one > in the same location > (with different contentlanguage and contenttype) between the two > GET's, so whether or not getcontentlanguage and getcontenttype > or mutable is irrelevant for this issue, isn't it? My understanding is that some servers calculate the GET response Content-Type on the fly, often by examining the filename extension. If, instead, you need to substitute a database read to retrieve the getcontentlength property value (which would be necessary if the getcontentlength property was writeable), this would presumably have a negative effect on GET performance as compared to calculating the Content-Type on the fly. Since GET is by far the most commonly called method, implementors are typicaly loathe to impact GET performance. So, Greg, what does mod_dav do with the Content-Type submitted with a PUT? - Jim From w3c-dist-auth-request@w3.org Mon Apr 16 14:03:15 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA10134 for ; Mon, 16 Apr 2001 14:03:13 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA10246; Mon, 16 Apr 2001 13:54:57 -0400 (EDT) Resent-Date: Mon, 16 Apr 2001 13:54:57 -0400 (EDT) Resent-Message-Id: <200104161754.NAA10246@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id NAA10226 for ; Mon, 16 Apr 2001 13:54:53 -0400 (EDT) Received: from cats.ucsc.edu (rumpleteazer.ucsc.edu [128.114.129.45]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id NAA29197 for ; Mon, 16 Apr 2001 13:54:53 -0400 Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177]) by cats.ucsc.edu (8.9.3/8.8.4.cats-athena) with SMTP id KAA06645 for ; Mon, 16 Apr 2001 10:54:54 -0700 (PDT) From: "Jim Whitehead" To: "WebDAV WG" Date: Mon, 16 Apr 2001 10:53:22 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Subject: PROP_ATTR: consensus points Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4810 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit OK, let me see if I can summarize the points of rough consensus in this discussion of the PROP_ATTR issue. From reading this thread, there were several distinct issues raised: * Should the server persistently store XML attribute information: (a) on the property contents, and (b) on the property name element. * Is XML a marshalling format, or MUST the server store property information as XML? * What is the behavior of the server on round-tripping XML attribute information of all kinds (including XML namespaces, xml:lang, and other standard, and user-defined attributes). I believe we have come to consensus on the first two issues: 1. The server MUST persistently store XML attribute information stored on XML elements contained by the XML element whose name is the name of the property. (A simpler way to describe this is: The server MUST persistently store XML attribute information stored on XML elements in a property's value. But, since we haven't agreed yet on what the "value" of a property is, I wanted to express the consensus point without using the "value" term). 2. I believe there is *rough* consensus that XML attributes on the property name element MAY be persistently stored, unless explicitly noted as an exception in the protocol specification (i.e., XML namespaces and xml:lang.) 3. XML is a marshalling format for the name and value of a property; the server is free to use whatever persistent storage format it desires. I was not able to detect consensus on the round-tripping issues. However, this is far enough away from the original scope of PROP_ATTR that I have created a new issue for this, called PROP_ROUNDTRIP. - Jim From w3c-dist-auth-request@w3.org Mon Apr 16 15:17:06 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA11917 for ; Mon, 16 Apr 2001 15:17:06 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id KAA29017; Mon, 16 Apr 2001 10:30:53 -0400 (EDT) Resent-Date: Mon, 16 Apr 2001 10:30:53 -0400 (EDT) Resent-Message-Id: <200104161430.KAA29017@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id KAA28997 for ; Mon, 16 Apr 2001 10:30:48 -0400 (EDT) Received: from megapathdsl.net (snowbird.megapath.net [216.200.176.7]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id KAA11605 for ; Mon, 16 Apr 2001 10:30:47 -0400 Received: from [216.36.75.57] (HELO ZERG) by megapathdsl.net (CommuniGate Pro SMTP 3.4.3) with SMTP id 19512928; Mon, 16 Apr 2001 07:30:16 -0700 From: "Kevin Wiggen" To: "Greg Stein" , "WebDAV WG" Date: Mon, 16 Apr 2001 07:30:17 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-reply-to: <20010415135400.D31832@lyra.org> Subject: RE: Issue: PROP_ATTR Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4806 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit >> Maybe we need to collect all issues regarding this topic before going back >> to this one. For instance, if somebody would want to store an XSLT or an XSD >> schema as a property value, he probably would expect that namespace prefix >> information is preserved as well... >They're SOL with (at least) mod_dav. It doesn't preserve prefixes. That is >potentially another issue for the RFC 2518 issues list (I have an opinion, >but that can occur under a separate issue thread). DAV servers cannot preserve the namespace prefix. What would happen if two proppatch's told the same resource to store properties with the same prefixes but differing namespaces? When the server went to output info on a propfind, it would not be consistent. and Kevin -----Original Message----- From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Greg Stein Sent: Sunday, April 15, 2001 1:54 PM To: WebDAV WG Subject: Re: Issue: PROP_ATTR On Sun, Apr 15, 2001 at 11:14:33AM +0200, Julian F. Reschke wrote: >... > As I said, both point of views are possible. However, your position seems to > be: > > value = Infoset of all child elements *plus* the optional xml:lang attribute Yes, because the xml:lang value is scoped, and the property value occurs within that scope. And this isn't just because xml:lang occurs on the property name element; it could be three levels higher in scope. > How do you put the value of xml:lang into the serialization of the element's > contents? Sure, that's again an implementation issue, but including the > element itself certainly makes it easier. Nope. It could occur higher in scope, so it might not be on the property name element at all. Thus, serializing the name isn't going to help with preserving the xml:lang value. I store the xml:lang and the (serialized) value as two items of data in the property database. > > My point is that it is more difficult for server implementors if > > you want to > > state that the attributes on the name element are part of the property > > value, and (thus) need to be stored. > > While my point is that it makes absolutely no difference at all :-) As an implementor of a server, I would disagree :-) I just want to see the language state something to the effect of: all attributes on elements, which are children of the name element, MUST be preserved; attributes on the name element MAY be preserved. [ plus the language about xml:lang ] > Maybe we need to collect all issues regarding this topic before going back > to this one. For instance, if somebody would want to store an XSLT or an XSD > schema as a property value, he probably would expect that namespace prefix > information is preserved as well... They're SOL with (at least) mod_dav. It doesn't preserve prefixes. That is potentially another issue for the RFC 2518 issues list (I have an opinion, but that can occur under a separate issue thread). Cheers, -g -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Mon Apr 16 15:35:35 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA12295 for ; Mon, 16 Apr 2001 15:35:33 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA15166; Mon, 16 Apr 2001 15:22:23 -0400 (EDT) Resent-Date: Mon, 16 Apr 2001 15:22:23 -0400 (EDT) Resent-Message-Id: <200104161922.PAA15166@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id PAA15146 for ; Mon, 16 Apr 2001 15:22:19 -0400 (EDT) Received: from cats.ucsc.edu (rumpleteazer.ucsc.edu [128.114.129.45]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id PAA05197 for ; Mon, 16 Apr 2001 15:22:19 -0400 Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177]) by cats.ucsc.edu (8.9.3/8.8.4.cats-athena) with SMTP id MAA09375 for ; Mon, 16 Apr 2001 12:22:20 -0700 (PDT) From: "Jim Whitehead" To: "WebDAV WG" Date: Mon, 16 Apr 2001 12:20:48 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <3906C56A7BD1F54593344C05BD1374B102A75F13@SUS-MA1IT01> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Subject: WRITE_DAV_PROP: Summary of consensus Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4811 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Let me see if I can summarize the points of consensus on this issue: Consensus: - protected (i.e. properties that MUST NOT be modifiable with PROPPATCH) creationdate getcontentlength getetag lockdiscovery supportedlock resourcetype - not protected (i.e. properties that MUST be modifiable by PROPPATCH) displayname source Still under discussion: getlastmodified getcontenttype getcontentlanguage There are two open issues: 1. Changing get* properties requires the server to perform a property lookup when processing a GET method request, and this is a performance hit for some servers. 2. It is unclear why getlastmodified needs to be writeable. Let's see if we can resolve these remaining issues over the next 1-2 days, so we can wrap this one up. - Jim From w3c-dist-auth-request@w3.org Mon Apr 16 15:35:35 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA12296 for ; Mon, 16 Apr 2001 15:35:33 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA15330; Mon, 16 Apr 2001 15:26:01 -0400 (EDT) Resent-Date: Mon, 16 Apr 2001 15:26:01 -0400 (EDT) Resent-Message-Id: <200104161926.PAA15330@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id PAA15302 for ; Mon, 16 Apr 2001 15:25:51 -0400 (EDT) Received: from cats.ucsc.edu (rumpleteazer.ucsc.edu [128.114.129.45]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id PAA05423 for ; Mon, 16 Apr 2001 15:25:50 -0400 Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177]) by cats.ucsc.edu (8.9.3/8.8.4.cats-athena) with SMTP id MAA10273; Mon, 16 Apr 2001 12:25:50 -0700 (PDT) From: "Jim Whitehead" To: "John Glavin" , "WebDAV WG" Date: Mon, 16 Apr 2001 12:24:17 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <001b01c0c465$dc1ca660$6701a8c0@win2k> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Subject: RE: Issue: WRITE_DAV_PROP Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4812 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit John Glavin writes: > I agree about the "getlastmodified" property. I would love to be able to > set this so that file synchronization software will work properly. My > product maps a network drive to a DAV server and unless I can set the > "getlastmodified" property file synch software won't work right. I only > know of one server that allows this now, it would be nice if this could be > standardized. Hmm, it's not at all obvious to me why writing to getlastmodified helps synchronization. Naively I would think the synchronization algorithm on resource R would be: - retrieve getlastmodified and getetag properties on R - IF local copy of R unchanged AND ((getlastmodified > R file timestamp) OR (getetag != stored value of R's etag from when it was originally downloaded)) THEN get file from server & update cached etag value ELSE leave local copy of R unchanged (it is the latest version) - IF local copy of R is changed THEN - IF (getlastmodified > value of getlastmodified from last download of the resource) OR (getetag != stored value of R's etag from when it was originally downloaded) THEN note a conflict, since the file has been updated on the client and the server - ELSE write the client file to the server, since the client file has been changed, and the server file hasn't I don't ever see a case here where changing the value of getlastmodified helps. When writing the client file to the server using PUT, the server automatically updates getlastmodified. This synch algorithm does assume that two pieces of metadata are stored for each resource, on the client side: - value of getlastmodified from the last download of the resource - value of getetag from the last download of the resource - Jim From w3c-dist-auth-request@w3.org Mon Apr 16 16:39:35 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA13417 for ; Mon, 16 Apr 2001 16:39:34 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA18478; Mon, 16 Apr 2001 16:32:51 -0400 (EDT) Resent-Date: Mon, 16 Apr 2001 16:32:51 -0400 (EDT) Resent-Message-Id: <200104162032.QAA18478@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id QAA18458 for ; Mon, 16 Apr 2001 16:32:47 -0400 (EDT) Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id QAA11065 for ; Mon, 16 Apr 2001 16:32:36 -0400 Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e21.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id QAA102244 for ; Mon, 16 Apr 2001 16:26:54 -0500 Received: from d04nm303.raleigh.ibm.com (d04nm303.raleigh.ibm.com [9.67.228.168]) by southrelay02.raleigh.ibm.com (8.11.1/NCO v4.96) with ESMTP id f3GKWOh88406 for ; Mon, 16 Apr 2001 16:32:25 -0400 To: w3c-dist-auth@w3c.org X-Mailer: Lotus Notes Release 5.0.6a January 17, 2001 Message-ID: From: "Jim Amsden" Date: Mon, 16 Apr 2001 16:26:43 -0400 X-MIMETrack: Serialize by Router on D04NM303/04/M/IBM(Release 5.0.6 |December 14, 2000) at 04/16/2001 04:32:24 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: Re: WRITE_DAV_PROP: Summary of consensus Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4813 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: getlastmodified needs to be updatable to do a UNIX-like touch command. Sets the modified date on a resource so dependent relationships are processed by builders or make. "Jim Whitehead" To: "WebDAV WG" Sent by: cc: w3c-dist-auth-requ Subject: WRITE_DAV_PROP: Summary of consensus est@w3.org 04/16/2001 03:20 PM Let me see if I can summarize the points of consensus on this issue: Consensus: - protected (i.e. properties that MUST NOT be modifiable with PROPPATCH) creationdate getcontentlength getetag lockdiscovery supportedlock resourcetype - not protected (i.e. properties that MUST be modifiable by PROPPATCH) displayname source Still under discussion: getlastmodified getcontenttype getcontentlanguage There are two open issues: 1. Changing get* properties requires the server to perform a property lookup when processing a GET method request, and this is a performance hit for some servers. 2. It is unclear why getlastmodified needs to be writeable. Let's see if we can resolve these remaining issues over the next 1-2 days, so we can wrap this one up. - Jim From w3c-dist-auth-request@w3.org Mon Apr 16 17:00:10 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA13666 for ; Mon, 16 Apr 2001 17:00:09 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA21147; Mon, 16 Apr 2001 16:53:57 -0400 (EDT) Resent-Date: Mon, 16 Apr 2001 16:53:57 -0400 (EDT) Resent-Message-Id: <200104162053.QAA21147@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id QAA21126 for ; Mon, 16 Apr 2001 16:53:54 -0400 (EDT) Received: from cats.ucsc.edu (rumpleteazer.ucsc.edu [128.114.129.45]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id QAA12891 for ; Mon, 16 Apr 2001 16:53:51 -0400 Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177]) by cats.ucsc.edu (8.9.3/8.8.4.cats-athena) with SMTP id NAA12534; Mon, 16 Apr 2001 13:53:52 -0700 (PDT) From: "Jim Whitehead" To: "Jim Amsden" , Date: Mon, 16 Apr 2001 13:52:19 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Subject: RE: WRITE_DAV_PROP: Summary of consensus Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4815 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > > getlastmodified needs to be updatable to do a UNIX-like touch > command. Sets > the modified date on a resource so dependent relationships are > processed by > builders or make. > There are two choices for building - client side and server side. In client side builds, the files are locally cached on client machine, and so the existing "touch" command coul djust be used. For server-side builds, the existence of a rich property mechanism means that we can do much better than the "touch" hack. This isn't a compelling scenario for me. - Jim From w3c-dist-auth-request@w3.org Mon Apr 16 17:03:49 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA13718 for ; Mon, 16 Apr 2001 17:03:44 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA21068; Mon, 16 Apr 2001 16:51:23 -0400 (EDT) Resent-Date: Mon, 16 Apr 2001 16:51:23 -0400 (EDT) Resent-Message-Id: <200104162051.QAA21068@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id QAA21044 for ; Mon, 16 Apr 2001 16:51:19 -0400 (EDT) Received: from sus-ma1it00.rational.com (ext-37140.rational.com [192.229.37.140]) by tux.w3.org (8.9.3/8.9.3) with SMTP id QAA12627 for ; Mon, 16 Apr 2001 16:51:19 -0400 Received: from 192.168.215.70 by sus-ma1it00.rational.com (InterScan E-Mail VirusWall NT); Mon, 16 Apr 2001 16:52:39 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Mon, 16 Apr 2001 16:52:39 -0400 Message-ID: <3906C56A7BD1F54593344C05BD1374B1018E2364@SUS-MA1IT01> From: "Clemm, Geoff" To: w3c-dist-auth@w3c.org Date: Mon, 16 Apr 2001 16:50:31 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: RE: WRITE_DAV_PROP: Summary of consensus Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4814 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Note though that updating getlastmodified is a significantly more powerful operation than "touch". Touch just says to act as if you wrote the same content over again, i.e. the only effect it has on getlastmodified is to reset it to the "current" date. On the other hand, updating getlastmodified lets you roll backward in time, thereby potentially breaking the various caching schemes that depend on a one-way movement of the getlastmodified value. Note also that even if you intended on just "rolling time forward", a client can't really get the time "right", so it will set the time either "too early" (i.e. earlier than "current") or "too late" (i.e. sometime in the future). Either of these situations can break the caching uses of getlastmodified. In particular, suppose you are writing a "too early" time ... if someone previously wrote to the resource, which updated the getlastmodified time to a time later than your "too early" time, then you will roll back the time (potentially breaking some caching). Now suppose you write a "too late" time. Then someone does an update, which sets the getlastmodified time to a "current" which is earlier than the time you set. Again, a "time rollback" has occurred, and you can break some caching. So, although I am in favor of "touch" functionality, I am (strongly) against providing it via a writeable "getlastmodified". Cheers, Geoff -----Original Message----- From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: Monday, April 16, 2001 4:27 PM To: w3c-dist-auth@w3c.org Subject: Re: WRITE_DAV_PROP: Summary of consensus getlastmodified needs to be updatable to do a UNIX-like touch command. Sets the modified date on a resource so dependent relationships are processed by builders or make. "Jim Whitehead" To: "WebDAV WG" Sent by: cc: w3c-dist-auth-requ Subject: WRITE_DAV_PROP: Summary of consensus est@w3.org 04/16/2001 03:20 PM Let me see if I can summarize the points of consensus on this issue: Consensus: - protected (i.e. properties that MUST NOT be modifiable with PROPPATCH) creationdate getcontentlength getetag lockdiscovery supportedlock resourcetype - not protected (i.e. properties that MUST be modifiable by PROPPATCH) displayname source Still under discussion: getlastmodified getcontenttype getcontentlanguage There are two open issues: 1. Changing get* properties requires the server to perform a property lookup when processing a GET method request, and this is a performance hit for some servers. 2. It is unclear why getlastmodified needs to be writeable. Let's see if we can resolve these remaining issues over the next 1-2 days, so we can wrap this one up. - Jim From w3c-dist-auth-request@w3.org Mon Apr 16 17:15:11 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA13972 for ; Mon, 16 Apr 2001 17:15:10 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA21655; Mon, 16 Apr 2001 17:06:54 -0400 (EDT) Resent-Date: Mon, 16 Apr 2001 17:06:54 -0400 (EDT) Resent-Message-Id: <200104162106.RAA21655@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id RAA21635 for ; Mon, 16 Apr 2001 17:06:51 -0400 (EDT) Received: from inet-mail4.oracle.com (inet-mail4.oracle.com [148.87.2.204]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id RAA13895 for ; Mon, 16 Apr 2001 17:06:51 -0400 Received: from gmgw03.oraclecorp.com (gmgw03.us.oracle.com [130.35.249.113]) by inet-mail4.oracle.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f3GL2O100607 for ; Mon, 16 Apr 2001 14:02:24 -0700 (PDT) Received: from esedlarlaptop (dhcp-4op7-4op8-east-130-35-171-33.us.oracle.com [130.35.171.33]) by gmgw03.oraclecorp.com (Switch-2.1.1/Switch-2.1.0) with SMTP id f3GL6A609740 for ; Mon, 16 Apr 2001 14:06:15 -0700 (PDT) From: "Eric Sedlar" To: Date: Mon, 16 Apr 2001 14:10:29 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <3906C56A7BD1F54593344C05BD1374B1018E2364@SUS-MA1IT01> Subject: RE: WRITE_DAV_PROP: Summary of consensus Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4816 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit How would you suggest that it be done--an empty PROPPATCH? -----Original Message----- From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff Sent: Monday, April 16, 2001 1:51 PM To: w3c-dist-auth@w3c.org Subject: RE: WRITE_DAV_PROP: Summary of consensus Note though that updating getlastmodified is a significantly more powerful operation than "touch". Touch just says to act as if you wrote the same content over again, i.e. the only effect it has on getlastmodified is to reset it to the "current" date. On the other hand, updating getlastmodified lets you roll backward in time, thereby potentially breaking the various caching schemes that depend on a one-way movement of the getlastmodified value. Note also that even if you intended on just "rolling time forward", a client can't really get the time "right", so it will set the time either "too early" (i.e. earlier than "current") or "too late" (i.e. sometime in the future). Either of these situations can break the caching uses of getlastmodified. In particular, suppose you are writing a "too early" time ... if someone previously wrote to the resource, which updated the getlastmodified time to a time later than your "too early" time, then you will roll back the time (potentially breaking some caching). Now suppose you write a "too late" time. Then someone does an update, which sets the getlastmodified time to a "current" which is earlier than the time you set. Again, a "time rollback" has occurred, and you can break some caching. So, although I am in favor of "touch" functionality, I am (strongly) against providing it via a writeable "getlastmodified". Cheers, Geoff -----Original Message----- From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: Monday, April 16, 2001 4:27 PM To: w3c-dist-auth@w3c.org Subject: Re: WRITE_DAV_PROP: Summary of consensus getlastmodified needs to be updatable to do a UNIX-like touch command. Sets the modified date on a resource so dependent relationships are processed by builders or make. "Jim Whitehead" To: "WebDAV WG" Sent by: cc: w3c-dist-auth-requ Subject: WRITE_DAV_PROP: Summary of consensus est@w3.org 04/16/2001 03:20 PM Let me see if I can summarize the points of consensus on this issue: Consensus: - protected (i.e. properties that MUST NOT be modifiable with PROPPATCH) creationdate getcontentlength getetag lockdiscovery supportedlock resourcetype - not protected (i.e. properties that MUST be modifiable by PROPPATCH) displayname source Still under discussion: getlastmodified getcontenttype getcontentlanguage There are two open issues: 1. Changing get* properties requires the server to perform a property lookup when processing a GET method request, and this is a performance hit for some servers. 2. It is unclear why getlastmodified needs to be writeable. Let's see if we can resolve these remaining issues over the next 1-2 days, so we can wrap this one up. - Jim From w3c-dist-auth-request@w3.org Mon Apr 16 18:00:57 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA14540 for ; Mon, 16 Apr 2001 18:00:55 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA23492; Mon, 16 Apr 2001 17:53:28 -0400 (EDT) Resent-Date: Mon, 16 Apr 2001 17:53:28 -0400 (EDT) Resent-Message-Id: <200104162153.RAA23492@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id RAA23469 for ; Mon, 16 Apr 2001 17:53:23 -0400 (EDT) Received: from cats.ucsc.edu (rumpleteazer.ucsc.edu [128.114.129.45]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id RAA17829 for ; Mon, 16 Apr 2001 17:53:22 -0400 Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177]) by cats.ucsc.edu (8.9.3/8.8.4.cats-athena) with SMTP id OAA00290; Mon, 16 Apr 2001 14:53:15 -0700 (PDT) From: "Jim Whitehead" To: "Laurie Harper" , Date: Mon, 16 Apr 2001 14:51:41 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <3ADB635D.148B488B@holoweb.net> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Subject: RE: WRITE_DAV_PROP: Summary of consensus Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4818 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > As remote-file-system type DAV clients become more widespread, I could > imagine lack of mutability of this property could become more > contentious... The typical uses of touch(1) are to force recompilation when using make, and to easily create new, empty files. Use of touch(1) for forcing recompilation is a hack -- since there is no general purpose property mechanism in Unix, there was no way to set the "force recompile" property, and so the timestamp was overloaded with these semantics. Are there other typical uses of touch(1) of which I'm unaware? - Jim From w3c-dist-auth-request@w3.org Mon Apr 16 18:01:58 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA14563 for ; Mon, 16 Apr 2001 18:01:58 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA23535; Mon, 16 Apr 2001 17:54:02 -0400 (EDT) Resent-Date: Mon, 16 Apr 2001 17:54:02 -0400 (EDT) Resent-Message-Id: <200104162154.RAA23535@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id RAA23515 for ; Mon, 16 Apr 2001 17:53:59 -0400 (EDT) Received: from sus-ma1it00.rational.com (ext-37140.rational.com [192.229.37.140]) by tux.w3.org (8.9.3/8.9.3) with SMTP id RAA17873 for ; Mon, 16 Apr 2001 17:53:59 -0400 Received: from 192.168.215.70 by sus-ma1it00.rational.com (InterScan E-Mail VirusWall NT); Mon, 16 Apr 2001 17:55:19 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Mon, 16 Apr 2001 17:55:19 -0400 Message-ID: <3906C56A7BD1F54593344C05BD1374B1018E2367@SUS-MA1IT01> From: "Clemm, Geoff" To: w3c-dist-auth@w3c.org Date: Mon, 16 Apr 2001 17:53:11 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: WRITE_DAV_PROP: Summary of consensus Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4819 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Actually, I didn't suggest how it should be done, just how it shouldn't be done (:-). An empty PROPPATCH is a possibility, but some servers do no have property modifications affect the getlastmodified time (only content modifications). Cheers, Geoff -----Original Message----- From: Eric Sedlar [mailto:eric.sedlar@oracle.com] Sent: Monday, April 16, 2001 5:10 PM To: w3c-dist-auth@w3c.org Subject: RE: WRITE_DAV_PROP: Summary of consensus How would you suggest that it be done--an empty PROPPATCH? -----Original Message----- From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff Sent: Monday, April 16, 2001 1:51 PM To: w3c-dist-auth@w3c.org Subject: RE: WRITE_DAV_PROP: Summary of consensus Note though that updating getlastmodified is a significantly more powerful operation than "touch". Touch just says to act as if you wrote the same content over again, i.e. the only effect it has on getlastmodified is to reset it to the "current" date. On the other hand, updating getlastmodified lets you roll backward in time, thereby potentially breaking the various caching schemes that depend on a one-way movement of the getlastmodified value. Note also that even if you intended on just "rolling time forward", a client can't really get the time "right", so it will set the time either "too early" (i.e. earlier than "current") or "too late" (i.e. sometime in the future). Either of these situations can break the caching uses of getlastmodified. In particular, suppose you are writing a "too early" time ... if someone previously wrote to the resource, which updated the getlastmodified time to a time later than your "too early" time, then you will roll back the time (potentially breaking some caching). Now suppose you write a "too late" time. Then someone does an update, which sets the getlastmodified time to a "current" which is earlier than the time you set. Again, a "time rollback" has occurred, and you can break some caching. So, although I am in favor of "touch" functionality, I am (strongly) against providing it via a writeable "getlastmodified". Cheers, Geoff -----Original Message----- From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: Monday, April 16, 2001 4:27 PM To: w3c-dist-auth@w3c.org Subject: Re: WRITE_DAV_PROP: Summary of consensus getlastmodified needs to be updatable to do a UNIX-like touch command. Sets the modified date on a resource so dependent relationships are processed by builders or make. "Jim Whitehead" To: "WebDAV WG" Sent by: cc: w3c-dist-auth-requ Subject: WRITE_DAV_PROP: Summary of consensus est@w3.org 04/16/2001 03:20 PM Let me see if I can summarize the points of consensus on this issue: Consensus: - protected (i.e. properties that MUST NOT be modifiable with PROPPATCH) creationdate getcontentlength getetag lockdiscovery supportedlock resourcetype - not protected (i.e. properties that MUST be modifiable by PROPPATCH) displayname source Still under discussion: getlastmodified getcontenttype getcontentlanguage There are two open issues: 1. Changing get* properties requires the server to perform a property lookup when processing a GET method request, and this is a performance hit for some servers. 2. It is unclear why getlastmodified needs to be writeable. Let's see if we can resolve these remaining issues over the next 1-2 days, so we can wrap this one up. - Jim From w3c-dist-auth-request@w3.org Mon Apr 16 18:14:44 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA14641 for ; Mon, 16 Apr 2001 18:14:43 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAA24249; Mon, 16 Apr 2001 18:03:45 -0400 (EDT) Resent-Date: Mon, 16 Apr 2001 18:03:45 -0400 (EDT) Resent-Message-Id: <200104162203.SAA24249@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id SAA24227 for ; Mon, 16 Apr 2001 18:03:41 -0400 (EDT) Received: from sus-ma1it00.rational.com (ext-37140.rational.com [192.229.37.140]) by tux.w3.org (8.9.3/8.9.3) with SMTP id SAA18696 for ; Mon, 16 Apr 2001 18:03:42 -0400 Received: from 192.168.215.70 by sus-ma1it00.rational.com (InterScan E-Mail VirusWall NT); Mon, 16 Apr 2001 18:05:10 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Mon, 16 Apr 2001 18:05:10 -0400 Message-ID: <3906C56A7BD1F54593344C05BD1374B1018E2369@SUS-MA1IT01> From: "Clemm, Geoff" To: w3c-dist-auth@w3.org Date: Mon, 16 Apr 2001 18:03:03 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: RE: WRITE_DAV_PROP: Summary of consensus Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4821 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Good point. I should have said "an operation that just sets the getlastmodified to be the current server time is OK, but an operation that sets getlastmodified to a client specified value has the following problems ...". As you say, touch(1) does in fact let you set the dates to arbitrary client-specified values. Cheers, Geoff -----Original Message----- From: Laurie Harper [mailto:zodiac@holoweb.net] Sent: Monday, April 16, 2001 5:26 PM To: w3c-dist-auth@w3.org Cc: w3c-dist-auth@w3c.org Subject: Re: WRITE_DAV_PROP: Summary of consensus Note also that touch(1) is a significantly more powerful tool than the operation "touch" as you've defined it... As remote-file-system type DAV clients become more widespread, I could imagine lack of mutability of this property could become more contentious... L. "Clemm, Geoff" wrote: > > Note though that updating getlastmodified is a significantly > more powerful operation than "touch". Touch just says to act > as if you wrote the same content over again, i.e. the only > effect it has on getlastmodified is to reset it to the "current" > date. > > On the other hand, updating getlastmodified lets you roll > backward in time, thereby potentially breaking the various > caching schemes that depend on a one-way movement of the > getlastmodified value. Note also that even if you intended > on just "rolling time forward", a client can't really get > the time "right", so it will set the time either "too early" > (i.e. earlier than "current") or "too late" (i.e. sometime > in the future). Either of these situations can break the > caching uses of getlastmodified. In particular, suppose > you are writing a "too early" time ... if someone previously > wrote to the resource, which updated the getlastmodified > time to a time later than your "too early" time, > then you will roll back the time (potentially breaking > some caching). Now suppose you write a "too late" time. > Then someone does an update, which sets the getlastmodified > time to a "current" which is earlier than the time you set. > Again, a "time rollback" has occurred, and you can break > some caching. > > So, although I am in favor of "touch" functionality, I am > (strongly) against providing it via a writeable "getlastmodified". > > Cheers, > Geoff > > > -----Original Message----- > From: Jim Amsden [mailto:jamsden@us.ibm.com] > Sent: Monday, April 16, 2001 4:27 PM > To: w3c-dist-auth@w3c.org > Subject: Re: WRITE_DAV_PROP: Summary of consensus > > getlastmodified needs to be updatable to do a UNIX-like touch command. Sets > the modified date on a resource so dependent relationships are processed by > builders or make. > > > > "Jim Whitehead" > > To: "WebDAV WG" > > Sent by: cc: > > w3c-dist-auth-requ Subject: WRITE_DAV_PROP: > Summary of consensus > est@w3.org > > > > > > 04/16/2001 03:20 > > PM > > > > > > Let me see if I can summarize the points of consensus on this issue: > > Consensus: > > - protected (i.e. properties that MUST NOT be modifiable with PROPPATCH) > creationdate > getcontentlength > getetag > lockdiscovery > supportedlock > resourcetype > > - not protected (i.e. properties that MUST be modifiable by PROPPATCH) > displayname > source > > Still under discussion: > > getlastmodified > getcontenttype > getcontentlanguage > > There are two open issues: > > 1. Changing get* properties requires the server to perform a property > lookup > when processing a GET method request, and this is a performance hit for > some > servers. > > 2. It is unclear why getlastmodified needs to be writeable. > > Let's see if we can resolve these remaining issues over the next 1-2 days, > so we can wrap this one up. > > - Jim -- http: www.holoweb.net/~zodiac/ | jabber: zodiac(@)jabber!org email: zodiac(@)holoweb!net | icq: #78724820 ----------------------------------------------------------------- condom: general protection error, child process produced. From w3c-dist-auth-request@w3.org Mon Apr 16 18:44:49 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA14960 for ; Mon, 16 Apr 2001 18:44:48 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAA26462; Mon, 16 Apr 2001 18:29:07 -0400 (EDT) Resent-Date: Mon, 16 Apr 2001 18:29:07 -0400 (EDT) Resent-Message-Id: <200104162229.SAA26462@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id SAA26422 for ; Mon, 16 Apr 2001 18:29:02 -0400 (EDT) Received: from megapathdsl.net (snowbird.megapath.net [216.200.176.7]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id SAA20589 for ; Mon, 16 Apr 2001 18:29:02 -0400 Received: from [216.36.75.57] (HELO beaver) by megapathdsl.net (CommuniGate Pro SMTP 3.4.3) with SMTP id 19576034; Mon, 16 Apr 2001 15:28:28 -0700 From: "Lisa Dusseault" To: "Clemm, Geoff" , Date: Mon, 16 Apr 2001 15:27:47 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <3906C56A7BD1F54593344C05BD1374B1018E2367@SUS-MA1IT01> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Subject: When to modify getlastmodified (Was: RE: WRITE_DAV_PROP: Summary of consensus Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4822 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit And that, in itself, is another issue. Can there be any consensus on what operations should affect getlastmodified automatically? - Body updates surely... - Update of dead properties? - Conversion of resource to versioned resource or other drastic change? Similarly, what does getlastmodified on a collection mean? > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff > Sent: Monday, April 16, 2001 2:53 PM > To: w3c-dist-auth@w3c.org > Subject: RE: WRITE_DAV_PROP: Summary of consensus > > > Actually, I didn't suggest how it should be done, > just how it shouldn't be done (:-). An empty > PROPPATCH is a possibility, but some servers do > no have property modifications affect the getlastmodified > time (only content modifications). > > Cheers, > Geoff > > -----Original Message----- > From: Eric Sedlar [mailto:eric.sedlar@oracle.com] > Sent: Monday, April 16, 2001 5:10 PM > To: w3c-dist-auth@w3c.org > Subject: RE: WRITE_DAV_PROP: Summary of consensus > > > How would you suggest that it be done--an empty PROPPATCH? > > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff > Sent: Monday, April 16, 2001 1:51 PM > To: w3c-dist-auth@w3c.org > Subject: RE: WRITE_DAV_PROP: Summary of consensus > > > Note though that updating getlastmodified is a significantly > more powerful operation than "touch". Touch just says to act > as if you wrote the same content over again, i.e. the only > effect it has on getlastmodified is to reset it to the "current" > date. > > On the other hand, updating getlastmodified lets you roll > backward in time, thereby potentially breaking the various > caching schemes that depend on a one-way movement of the > getlastmodified value. Note also that even if you intended > on just "rolling time forward", a client can't really get > the time "right", so it will set the time either "too early" > (i.e. earlier than "current") or "too late" (i.e. sometime > in the future). Either of these situations can break the > caching uses of getlastmodified. In particular, suppose > you are writing a "too early" time ... if someone previously > wrote to the resource, which updated the getlastmodified > time to a time later than your "too early" time, > then you will roll back the time (potentially breaking > some caching). Now suppose you write a "too late" time. > Then someone does an update, which sets the getlastmodified > time to a "current" which is earlier than the time you set. > Again, a "time rollback" has occurred, and you can break > some caching. > > So, although I am in favor of "touch" functionality, I am > (strongly) against providing it via a writeable "getlastmodified". > > Cheers, > Geoff > > > -----Original Message----- > From: Jim Amsden [mailto:jamsden@us.ibm.com] > Sent: Monday, April 16, 2001 4:27 PM > To: w3c-dist-auth@w3c.org > Subject: Re: WRITE_DAV_PROP: Summary of consensus > > > getlastmodified needs to be updatable to do a UNIX-like touch > command. Sets > the modified date on a resource so dependent relationships are > processed by > builders or make. > > > > > > "Jim Whitehead" > > To: "WebDAV WG" > > Sent by: cc: > > w3c-dist-auth-requ Subject: WRITE_DAV_PROP: > Summary of consensus > est@w3.org > > > > > > 04/16/2001 03:20 > > PM > > > > > > > > > Let me see if I can summarize the points of consensus on this issue: > > Consensus: > > - protected (i.e. properties that MUST NOT be modifiable with PROPPATCH) > creationdate > getcontentlength > getetag > lockdiscovery > supportedlock > resourcetype > > - not protected (i.e. properties that MUST be modifiable by PROPPATCH) > displayname > source > > Still under discussion: > > getlastmodified > getcontenttype > getcontentlanguage > > There are two open issues: > > 1. Changing get* properties requires the server to perform a property > lookup > when processing a GET method request, and this is a performance hit for > some > servers. > > 2. It is unclear why getlastmodified needs to be writeable. > > Let's see if we can resolve these remaining issues over the next 1-2 days, > so we can wrap this one up. > > - Jim > > From w3c-dist-auth-request@w3.org Mon Apr 16 21:11:37 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA15867 for ; Mon, 16 Apr 2001 21:11:35 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id TAA29397; Mon, 16 Apr 2001 19:50:13 -0400 (EDT) Resent-Date: Mon, 16 Apr 2001 19:50:13 -0400 (EDT) Resent-Message-Id: <200104162350.TAA29397@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id TAA29373 for ; Mon, 16 Apr 2001 19:50:09 -0400 (EDT) Received: from ladon.host4u.net (ladon.host4u.net [216.71.64.24]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id TAA27273 for ; Mon, 16 Apr 2001 19:50:08 -0400 Received: from win2k (CBL120.pool007.CH001-riverside.dhcp.hs.earthlink.net [24.41.38.120]) by ladon.host4u.net (8.8.5/8.8.5) with SMTP id SAA19804 for ; Mon, 16 Apr 2001 18:43:31 -0500 Message-ID: <006c01c0c6d1$61ab1380$6701a8c0@win2k> From: "John Glavin" To: References: Date: Mon, 16 Apr 2001 17:00:14 -0700 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.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Subject: Re: WRITE_DAV_PROP: Summary of consensus Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4824 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit It doesn't really matter to me if the getlastmodified time can be written to as long as there is some mechanism in DAV for allowing 1) A time stamp property that gets updated by the server whenever the file contents are changed. I suppose it could be debated about what other changes to the file/properties might cause this property to change. 2) Allow the time stamp property to be modified by a client. John Glavin RiverFront Software john@webdrive.com http://www.webdrive.com ----- Original Message ----- From: "Jim Whitehead" To: "Jim Amsden" ; Sent: Monday, April 16, 2001 1:52 PM Subject: RE: WRITE_DAV_PROP: Summary of consensus > > > > getlastmodified needs to be updatable to do a UNIX-like touch > > command. Sets > > the modified date on a resource so dependent relationships are > > processed by > > builders or make. > > > > There are two choices for building - client side and server side. In client > side builds, the files are locally cached on client machine, and so the > existing "touch" command coul djust be used. > > For server-side builds, the existence of a rich property mechanism means > that we can do much better than the "touch" hack. > > This isn't a compelling scenario for me. > > - Jim From w3c-dist-auth-request@w3.org Mon Apr 16 22:20:11 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA17236 for ; Mon, 16 Apr 2001 22:20:09 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id TAA28692; Mon, 16 Apr 2001 19:38:10 -0400 (EDT) Resent-Date: Mon, 16 Apr 2001 19:38:10 -0400 (EDT) Resent-Message-Id: <200104162338.TAA28692@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id TAA28663 for ; Mon, 16 Apr 2001 19:38:05 -0400 (EDT) Received: from ladon.host4u.net (ladon.host4u.net [216.71.64.24]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id TAA26388 for ; Mon, 16 Apr 2001 19:38:04 -0400 Received: from win2k (CBL120.pool007.CH001-riverside.dhcp.hs.earthlink.net [24.41.38.120]) by ladon.host4u.net (8.8.5/8.8.5) with SMTP id SAA17009; Mon, 16 Apr 2001 18:31:20 -0500 Message-ID: <001c01c0c6cf$adfe54b0$6701a8c0@win2k> From: "John Glavin" To: "Jim Whitehead" , "John Glavin" , "WebDAV WG" References: Date: Mon, 16 Apr 2001 16:48:03 -0700 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.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Subject: Re: Issue: WRITE_DAV_PROP Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4823 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Jim Whitehead" To: "John Glavin" ; "WebDAV WG" Sent: Monday, April 16, 2001 12:24 PM Subject: RE: Issue: WRITE_DAV_PROP > John Glavin writes: > > I agree about the "getlastmodified" property. I would love to be able to > > set this so that file synchronization software will work properly. My > > product maps a network drive to a DAV server and unless I can set the > > "getlastmodified" property file synch software won't work right. I only > > know of one server that allows this now, it would be nice if this could be > > standardized. > > Hmm, it's not at all obvious to me why writing to getlastmodified helps > synchronization. Naively I would think the synchronization algorithm on > resource R would be: > > - retrieve getlastmodified and getetag properties on R > - IF local copy of R unchanged AND ((getlastmodified > R file timestamp) OR > (getetag != stored value of R's etag from when it was originally > downloaded)) THEN get file from server & update cached etag value ELSE leave > local copy of R unchanged (it is the latest version) > - IF local copy of R is changed THEN > - IF (getlastmodified > value of getlastmodified from last download of the > resource) OR (getetag != stored value of R's etag from when it was > originally downloaded) THEN note a conflict, since the file has been updated > on the client and the server > - ELSE write the client file to the server, since the client file has been > changed, and the server file hasn't > > > I don't ever see a case here where changing the value of getlastmodified > helps. When writing the client file to the server using PUT, the server > automatically updates getlastmodified. > This is where the problem lies. If you PUT a file to the server, the server will update getlastmodified. The way that existing Windows applications synchronize files is to copy the file to the server and then set the modified time to match the existing modified time of the file that is say on the users hard disk. This way when it next checks to see if the file is in synch it will just check the last modified property. I know that DAV isn't specific to Windows or any file system in particular, but it would be nice if there was a way in DAV to allow existing file synchronization software to work. A simple way to do this is to allow the getlastmodified property to be set. The algorithm mentioned above by Jim would work fine if the synchronization software was written with DAV in mind. My product maps a network drive under Windows to a DAV server, so I can't really change the method that applications use to synchronize files, nor could I expose these additional DAV properties to them. The DAV server for www.mydocsonline.com does this and it works very well with my product and some other products out there that count on this for file synchronization. Thanks, John Glavin RiverFront Software http://www.webdrive.com From w3c-dist-auth-request@w3.org Mon Apr 16 22:20:12 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA17246 for ; Mon, 16 Apr 2001 22:20:12 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA22192; Mon, 16 Apr 2001 17:21:46 -0400 (EDT) Resent-Date: Mon, 16 Apr 2001 17:21:46 -0400 (EDT) Resent-Message-Id: <200104162121.RAA22192@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id RAA22172 for ; Mon, 16 Apr 2001 17:21:42 -0400 (EDT) Received: from dirk.holoweb.net (dirk2.holoweb.net [216.94.134.20]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id RAA15130 for ; Mon, 16 Apr 2001 17:21:43 -0400 Received: from holoweb.net ([216.94.134.192]) by dirk.holoweb.net (8.9.3/8.9.3) with ESMTP id RAA66320 for ; Mon, 16 Apr 2001 17:21:35 -0400 (EDT) (envelope-from zodiac@holoweb.net) Message-ID: <3ADB635D.148B488B@holoweb.net> Date: Mon, 16 Apr 2001 17:25:49 -0400 From: Laurie Harper X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.5-15 i686) X-Accept-Language: en MIME-Version: 1.0 CC: w3c-dist-auth@w3c.org References: <3906C56A7BD1F54593344C05BD1374B1018E2364@SUS-MA1IT01> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: WRITE_DAV_PROP: Summary of consensus To: w3c-dist-auth@w3.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4817 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Note also that touch(1) is a significantly more powerful tool than the operation "touch" as you've defined it... As remote-file-system type DAV clients become more widespread, I could imagine lack of mutability of this property could become more contentious... L. "Clemm, Geoff" wrote: > > Note though that updating getlastmodified is a significantly > more powerful operation than "touch". Touch just says to act > as if you wrote the same content over again, i.e. the only > effect it has on getlastmodified is to reset it to the "current" > date. > > On the other hand, updating getlastmodified lets you roll > backward in time, thereby potentially breaking the various > caching schemes that depend on a one-way movement of the > getlastmodified value. Note also that even if you intended > on just "rolling time forward", a client can't really get > the time "right", so it will set the time either "too early" > (i.e. earlier than "current") or "too late" (i.e. sometime > in the future). Either of these situations can break the > caching uses of getlastmodified. In particular, suppose > you are writing a "too early" time ... if someone previously > wrote to the resource, which updated the getlastmodified > time to a time later than your "too early" time, > then you will roll back the time (potentially breaking > some caching). Now suppose you write a "too late" time. > Then someone does an update, which sets the getlastmodified > time to a "current" which is earlier than the time you set. > Again, a "time rollback" has occurred, and you can break > some caching. > > So, although I am in favor of "touch" functionality, I am > (strongly) against providing it via a writeable "getlastmodified". > > Cheers, > Geoff > > > -----Original Message----- > From: Jim Amsden [mailto:jamsden@us.ibm.com] > Sent: Monday, April 16, 2001 4:27 PM > To: w3c-dist-auth@w3c.org > Subject: Re: WRITE_DAV_PROP: Summary of consensus > > getlastmodified needs to be updatable to do a UNIX-like touch command. Sets > the modified date on a resource so dependent relationships are processed by > builders or make. > > > > "Jim Whitehead" > > To: "WebDAV WG" > > Sent by: cc: > > w3c-dist-auth-requ Subject: WRITE_DAV_PROP: > Summary of consensus > est@w3.org > > > > > > 04/16/2001 03:20 > > PM > > > > > > Let me see if I can summarize the points of consensus on this issue: > > Consensus: > > - protected (i.e. properties that MUST NOT be modifiable with PROPPATCH) > creationdate > getcontentlength > getetag > lockdiscovery > supportedlock > resourcetype > > - not protected (i.e. properties that MUST be modifiable by PROPPATCH) > displayname > source > > Still under discussion: > > getlastmodified > getcontenttype > getcontentlanguage > > There are two open issues: > > 1. Changing get* properties requires the server to perform a property > lookup > when processing a GET method request, and this is a performance hit for > some > servers. > > 2. It is unclear why getlastmodified needs to be writeable. > > Let's see if we can resolve these remaining issues over the next 1-2 days, > so we can wrap this one up. > > - Jim -- http: www.holoweb.net/~zodiac/ | jabber: zodiac(@)jabber!org email: zodiac(@)holoweb!net | icq: #78724820 ----------------------------------------------------------------- condom: general protection error, child process produced. From w3c-dist-auth-request@w3.org Mon Apr 16 23:19:17 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA18444 for ; Mon, 16 Apr 2001 23:18:52 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id VAA04326; Mon, 16 Apr 2001 21:53:27 -0400 (EDT) Resent-Date: Mon, 16 Apr 2001 21:53:27 -0400 (EDT) Resent-Message-Id: <200104170153.VAA04326@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id VAA04306 for ; Mon, 16 Apr 2001 21:53:23 -0400 (EDT) Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id VAA04137 for ; Mon, 16 Apr 2001 21:53:24 -0400 Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e21.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id VAA92114 for ; Mon, 16 Apr 2001 21:47:46 -0500 Received: from d04nm303.raleigh.ibm.com (d04nm303.raleigh.ibm.com [9.67.228.168]) by southrelay02.raleigh.ibm.com (8.11.1/NCO v4.96) with ESMTP id f3H1rHh109420 for ; Mon, 16 Apr 2001 21:53:17 -0400 To: w3c-dist-auth@w3c.org X-Mailer: Lotus Notes Release 5.0.6a January 17, 2001 Message-ID: From: "Jim Amsden" Date: Mon, 16 Apr 2001 21:48:46 -0400 X-MIMETrack: Serialize by Router on D04NM303/04/M/IBM(Release 5.0.6 |December 14, 2000) at 04/16/2001 09:53:17 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: Re: When to modify getlastmodified (Was: RE: WRITE_DAV_PROP: Summary of consensus Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4825 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Let's not try to overload getlastmodified with eTag semantics. There will be times when live properties change due to side-effects of other operations. These changes will not result in a new version, but clearly some clients may want caches to become stale depending on the semantics of the property and how they might be using it. So they might result in a new eTag, even if the getlastmodified property didn't change. Implicit in getlastmodified is often by whom. I suppose the server could be considered a principal in this regard though. "Lisa Dusseault" To: "Clemm, Geoff" , Sent by: w3c-dist-auth-requ cc: est@w3.org Subject: When to modify getlastmodified (Was: RE: WRITE_DAV_PROP: Summary of consensus 04/16/2001 06:27 PM And that, in itself, is another issue. Can there be any consensus on what operations should affect getlastmodified automatically? - Body updates surely... - Update of dead properties? - Conversion of resource to versioned resource or other drastic change? Similarly, what does getlastmodified on a collection mean? > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff > Sent: Monday, April 16, 2001 2:53 PM > To: w3c-dist-auth@w3c.org > Subject: RE: WRITE_DAV_PROP: Summary of consensus > > > Actually, I didn't suggest how it should be done, > just how it shouldn't be done (:-). An empty > PROPPATCH is a possibility, but some servers do > no have property modifications affect the getlastmodified > time (only content modifications). > > Cheers, > Geoff > > -----Original Message----- > From: Eric Sedlar [mailto:eric.sedlar@oracle.com] > Sent: Monday, April 16, 2001 5:10 PM > To: w3c-dist-auth@w3c.org > Subject: RE: WRITE_DAV_PROP: Summary of consensus > > > How would you suggest that it be done--an empty PROPPATCH? > > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff > Sent: Monday, April 16, 2001 1:51 PM > To: w3c-dist-auth@w3c.org > Subject: RE: WRITE_DAV_PROP: Summary of consensus > > > Note though that updating getlastmodified is a significantly > more powerful operation than "touch". Touch just says to act > as if you wrote the same content over again, i.e. the only > effect it has on getlastmodified is to reset it to the "current" > date. > > On the other hand, updating getlastmodified lets you roll > backward in time, thereby potentially breaking the various > caching schemes that depend on a one-way movement of the > getlastmodified value. Note also that even if you intended > on just "rolling time forward", a client can't really get > the time "right", so it will set the time either "too early" > (i.e. earlier than "current") or "too late" (i.e. sometime > in the future). Either of these situations can break the > caching uses of getlastmodified. In particular, suppose > you are writing a "too early" time ... if someone previously > wrote to the resource, which updated the getlastmodified > time to a time later than your "too early" time, > then you will roll back the time (potentially breaking > some caching). Now suppose you write a "too late" time. > Then someone does an update, which sets the getlastmodified > time to a "current" which is earlier than the time you set. > Again, a "time rollback" has occurred, and you can break > some caching. > > So, although I am in favor of "touch" functionality, I am > (strongly) against providing it via a writeable "getlastmodified". > > Cheers, > Geoff > > > -----Original Message----- > From: Jim Amsden [mailto:jamsden@us.ibm.com] > Sent: Monday, April 16, 2001 4:27 PM > To: w3c-dist-auth@w3c.org > Subject: Re: WRITE_DAV_PROP: Summary of consensus > > > getlastmodified needs to be updatable to do a UNIX-like touch > command. Sets > the modified date on a resource so dependent relationships are > processed by > builders or make. > > > > > > "Jim Whitehead" > > To: "WebDAV WG" > > Sent by: cc: > > w3c-dist-auth-requ Subject: WRITE_DAV_PROP: > Summary of consensus > est@w3.org > > > > > > 04/16/2001 03:20 > > PM > > > > > > > > > Let me see if I can summarize the points of consensus on this issue: > > Consensus: > > - protected (i.e. properties that MUST NOT be modifiable with PROPPATCH) > creationdate > getcontentlength > getetag > lockdiscovery > supportedlock > resourcetype > > - not protected (i.e. properties that MUST be modifiable by PROPPATCH) > displayname > source > > Still under discussion: > > getlastmodified > getcontenttype > getcontentlanguage > > There are two open issues: > > 1. Changing get* properties requires the server to perform a property > lookup > when processing a GET method request, and this is a performance hit for > some > servers. > > 2. It is unclear why getlastmodified needs to be writeable. > > Let's see if we can resolve these remaining issues over the next 1-2 days, > so we can wrap this one up. > > - Jim > > From w3c-dist-auth-request@w3.org Tue Apr 17 00:01:05 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA19114 for ; Tue, 17 Apr 2001 00:01:05 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id XAA07128; Mon, 16 Apr 2001 23:14:27 -0400 (EDT) Resent-Date: Mon, 16 Apr 2001 23:14:27 -0400 (EDT) Resent-Message-Id: <200104170314.XAA07128@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id XAA07108 for ; Mon, 16 Apr 2001 23:14:23 -0400 (EDT) Received: from sus-ma1it00.rational.com (ext-37140.rational.com [192.229.37.140]) by tux.w3.org (8.9.3/8.9.3) with SMTP id XAA09678 for ; Mon, 16 Apr 2001 23:14:24 -0400 Received: from 192.168.215.70 by sus-ma1it00.rational.com (InterScan E-Mail VirusWall NT); Mon, 16 Apr 2001 23:15:52 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Mon, 16 Apr 2001 23:15:52 -0400 Message-ID: <3906C56A7BD1F54593344C05BD1374B102B8FC16@SUS-MA1IT01> From: "Clemm, Geoff" To: WebDAV WG Date: Mon, 16 Apr 2001 23:13:49 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Issue: WRITE_DAV_PROP Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4826 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: From: John Glavin [mailto:john@riverfrontsoftware.com] ... If you PUT a file to the server, the server will update getlastmodified. The way that existing Windows applications synchronize files is to copy the file to the server and then set the modified time to match the existing modified time of the file that is say on the users hard disk. This way when it next checks to see if the file is in synch it will just check the last modified property. I know that DAV isn't specific to Windows or any file system in particular, but it would be nice if there was a way in DAV to allow existing file synchronization software to work. A simple way to do this is to allow the getlastmodified property to be set. Given the choice between having HTTP/1.1 caching work and having a certain kind of Windows file synchronization work, I'd have to vote for HTTP/1.1 caching (it is an HTTP protocol after all :-). In particular, RFC 2616 says: An origin server SHOULD obtain the Last-Modified value of the entity as close as possible to the time that it generates the Date value of its response. This allows a recipient to make an accurate assessment of the entity's modification time, especially if the entity changes near the time that the response is generated. So this says that it should be the server's idea of the current time, not some client's idea of the time. So it would be fine to allocate some new property value to mean "file-system's idea of the time", but we shouldn't use getlastmodified to do so, because the value of getlastmodified being synchronized with the server's idea of the current date is required for the HTTP/1.1 If-Modified-Since header semantics. Cheers, Geoff From w3c-dist-auth-request@w3.org Tue Apr 17 01:46:35 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA24852 for ; Tue, 17 Apr 2001 01:46:32 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id BAA11304; Tue, 17 Apr 2001 01:33:27 -0400 (EDT) Resent-Date: Tue, 17 Apr 2001 01:33:27 -0400 (EDT) Resent-Message-Id: <200104170533.BAA11304@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id BAA11284 for ; Tue, 17 Apr 2001 01:33:23 -0400 (EDT) Received: from kurgan.lyra.org (test.webdav.org [198.144.203.199]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id BAA19196 for ; Tue, 17 Apr 2001 01:33:20 -0400 Received: (from gstein@localhost) by kurgan.lyra.org (8.9.3/8.9.3) id WAA01600 for w3c-dist-auth@w3c.org; Mon, 16 Apr 2001 22:35:03 -0700 X-Authentication-Warning: kurgan.lyra.org: gstein set sender to gstein@lyra.org using -f Date: Mon, 16 Apr 2001 22:35:03 -0700 From: Greg Stein To: w3c-dist-auth@w3c.org Message-ID: <20010416223503.T31832@lyra.org> Mail-Followup-To: w3c-dist-auth@w3c.org References: <3906C56A7BD1F54593344C05BD1374B1018E2367@SUS-MA1IT01> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <3906C56A7BD1F54593344C05BD1374B1018E2367@SUS-MA1IT01>; from gclemm@rational.com on Mon, Apr 16, 2001 at 05:53:11PM -0400 X-URL: http://www.lyra.org/greg/ Subject: Re: WRITE_DAV_PROP: Summary of consensus Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4827 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Per Geoff's point: mod_dav does *not* update the getlastmodified value when a property is changed (for the default software config, where stuff is stored into the filesystem; if you have a custom backend, then who knows). And all the get* properties are readonly. We determine Content-Language and Content-Type using standard Apache mechanisms (which don't have to hit a property database every time). Cheers, -g On Mon, Apr 16, 2001 at 05:53:11PM -0400, Clemm, Geoff wrote: > Actually, I didn't suggest how it should be done, > just how it shouldn't be done (:-). An empty > PROPPATCH is a possibility, but some servers do > no have property modifications affect the getlastmodified > time (only content modifications). > > Cheers, > Geoff > > -----Original Message----- > From: Eric Sedlar [mailto:eric.sedlar@oracle.com] > Sent: Monday, April 16, 2001 5:10 PM > To: w3c-dist-auth@w3c.org > Subject: RE: WRITE_DAV_PROP: Summary of consensus > > > How would you suggest that it be done--an empty PROPPATCH? > > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff > Sent: Monday, April 16, 2001 1:51 PM > To: w3c-dist-auth@w3c.org > Subject: RE: WRITE_DAV_PROP: Summary of consensus > > > Note though that updating getlastmodified is a significantly > more powerful operation than "touch". Touch just says to act > as if you wrote the same content over again, i.e. the only > effect it has on getlastmodified is to reset it to the "current" > date. > > On the other hand, updating getlastmodified lets you roll > backward in time, thereby potentially breaking the various > caching schemes that depend on a one-way movement of the > getlastmodified value. Note also that even if you intended > on just "rolling time forward", a client can't really get > the time "right", so it will set the time either "too early" > (i.e. earlier than "current") or "too late" (i.e. sometime > in the future). Either of these situations can break the > caching uses of getlastmodified. In particular, suppose > you are writing a "too early" time ... if someone previously > wrote to the resource, which updated the getlastmodified > time to a time later than your "too early" time, > then you will roll back the time (potentially breaking > some caching). Now suppose you write a "too late" time. > Then someone does an update, which sets the getlastmodified > time to a "current" which is earlier than the time you set. > Again, a "time rollback" has occurred, and you can break > some caching. > > So, although I am in favor of "touch" functionality, I am > (strongly) against providing it via a writeable "getlastmodified". > > Cheers, > Geoff > > > -----Original Message----- > From: Jim Amsden [mailto:jamsden@us.ibm.com] > Sent: Monday, April 16, 2001 4:27 PM > To: w3c-dist-auth@w3c.org > Subject: Re: WRITE_DAV_PROP: Summary of consensus > > > getlastmodified needs to be updatable to do a UNIX-like touch command. Sets > the modified date on a resource so dependent relationships are processed by > builders or make. > > > > > > "Jim Whitehead" > > To: "WebDAV WG" > > Sent by: cc: > > w3c-dist-auth-requ Subject: WRITE_DAV_PROP: > Summary of consensus > est@w3.org > > > > > > 04/16/2001 03:20 > > PM > > > > > > > > > Let me see if I can summarize the points of consensus on this issue: > > Consensus: > > - protected (i.e. properties that MUST NOT be modifiable with PROPPATCH) > creationdate > getcontentlength > getetag > lockdiscovery > supportedlock > resourcetype > > - not protected (i.e. properties that MUST be modifiable by PROPPATCH) > displayname > source > > Still under discussion: > > getlastmodified > getcontenttype > getcontentlanguage > > There are two open issues: > > 1. Changing get* properties requires the server to perform a property > lookup > when processing a GET method request, and this is a performance hit for > some > servers. > > 2. It is unclear why getlastmodified needs to be writeable. > > Let's see if we can resolve these remaining issues over the next 1-2 days, > so we can wrap this one up. > > - Jim > -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Tue Apr 17 03:08:40 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA03968 for ; Tue, 17 Apr 2001 03:08:40 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAA24078; Mon, 16 Apr 2001 18:01:47 -0400 (EDT) Resent-Date: Mon, 16 Apr 2001 18:01:47 -0400 (EDT) Resent-Message-Id: <200104162201.SAA24078@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id SAA24055 for ; Mon, 16 Apr 2001 18:01:41 -0400 (EDT) Received: from mail.gmx.net (pop.gmx.net [194.221.183.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id SAA18552 for ; Mon, 16 Apr 2001 18:01:41 -0400 Received: (qmail 17060 invoked by uid 0); 16 Apr 2001 22:01:08 -0000 Received: from pd950c1c7.dip.t-dialin.net (HELO lisa) (217.80.193.199) by mail.gmx.net (mp024-rz3) with SMTP; 16 Apr 2001 22:01:08 -0000 From: "Julian F. Reschke" To: "Jim Whitehead" , "WebDAV WG" Date: Tue, 17 Apr 2001 00:01:06 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000 Subject: RE: PROP_ATTR: consensus points Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4820 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jim Whitehead > Sent: Monday, April 16, 2001 7:53 PM > To: WebDAV WG > Subject: PROP_ATTR: consensus points > > > OK, let me see if I can summarize the points of rough consensus in this > discussion of the PROP_ATTR issue. From reading this thread, there were > several distinct issues raised: > > * Should the server persistently store XML attribute information: > (a) on the > property contents, and (b) on the property name element. > > * Is XML a marshalling format, or MUST the server store property > information > as XML? > > * What is the behavior of the server on round-tripping XML attribute > information of all kinds (including XML namespaces, xml:lang, and other > standard, and user-defined attributes). > > I believe we have come to consensus on the first two issues: > > 1. The server MUST persistently store XML attribute information stored on > XML elements contained by the XML element whose name is the name of the > property. > > (A simpler way to describe this is: The server MUST persistently store XML > attribute information stored on XML elements in a property's value. But, > since we haven't agreed yet on what the "value" of a property is, I wanted > to express the consensus point without using the "value" term). Yes. > 2. I believe there is *rough* consensus that XML attributes on > the property > name element MAY be persistently stored, unless explicitly noted as an > exception in the protocol specification (i.e., XML namespaces and > xml:lang.) I think we should try to use a consistent vocabulary. If we use the XML infoset (or the XPath) data model, XML namespace declarations are "namespace nodes". They just happen to be expressed as attributes in the serializiation... > 3. XML is a marshalling format for the name and value of a property; the > server is free to use whatever persistent storage format it desires. ...but it will have to use a format that allows him to recreate the XML infoset of the property element's contents (or a to-be-defined subset of it). > I was not able to detect consensus on the round-tripping issues. However, > this is far enough away from the original scope of PROP_ATTR that I have > created a new issue for this, called PROP_ROUNDTRIP. Fine with me. From w3c-dist-auth-request@w3.org Tue Apr 17 09:06:21 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA06783 for ; Tue, 17 Apr 2001 09:06:20 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id HAA00609; Tue, 17 Apr 2001 07:48:02 -0400 (EDT) Resent-Date: Tue, 17 Apr 2001 07:48:02 -0400 (EDT) Resent-Message-Id: <200104171148.HAA00609@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id HAA00586 for ; Tue, 17 Apr 2001 07:47:57 -0400 (EDT) Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id HAA17739 for ; Tue, 17 Apr 2001 07:47:57 -0400 Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e21.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id HAA59496 for ; Tue, 17 Apr 2001 07:42:19 -0500 Received: from d04mc200.raleigh.ibm.com (d04mc200.raleigh.ibm.com [9.67.228.62]) by southrelay02.raleigh.ibm.com (8.11.1/NCO v4.96) with ESMTP id f3HBloQ35150 for ; Tue, 17 Apr 2001 07:47:50 -0400 Importance: Normal To: w3c-dist-auth@w3.org X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "Steve K Speicher" Date: Tue, 17 Apr 2001 07:50:11 -0400 X-MIMETrack: Serialize by Router on D04MC200/04/M/IBM(Release 5.0.6 |December 14, 2000) at 04/17/2001 07:47:51 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: RE: WRITE_DAV_PROP: Summary of consensus Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4828 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: "Jim Whitehead" wrote: > Are there other typical uses of touch(1) of which I'm unaware? FWIW: I've used touch(1) to NOT allow the recompilation using make. I have used touch(1) to set the modification time of a file back to what it was previous to a modification, was when it affected a source file in a build tree that was on a shared file system (DFS) for multiple platform builds. Since only a few C++ compilers on some platforms would fail on a certain file, if I was to fix that one header file then all platform builds would be out-of-date and need to be rebuilt (or at least be rerun with "make -t"). To solve this, I would just do a 'touch ' on the header file and make all the prebuilt trees appear to be up-to-date again. I'm not necessarily advocating supporting this *hack*, I'm just answering JimW's question. To get similar behavior like this in DAV, I guess I'd just have to do something similar to "make -t" to make the builds up-to-date. Steve From w3c-dist-auth-request@w3.org Wed Apr 18 16:58:13 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA17843 for ; Wed, 18 Apr 2001 16:58:10 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA17290; Wed, 18 Apr 2001 16:46:34 -0400 (EDT) Resent-Date: Wed, 18 Apr 2001 16:46:34 -0400 (EDT) Resent-Message-Id: <200104182046.QAA17290@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id QAA17270 for ; Wed, 18 Apr 2001 16:46:23 -0400 (EDT) Received: from cats.ucsc.edu (rumpleteazer.ucsc.edu [128.114.129.45]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id QAA03526 for ; Wed, 18 Apr 2001 16:46:23 -0400 Received: from Tycho (dhcp-55-189.cse.ucsc.edu [128.114.55.189]) by cats.ucsc.edu (8.9.3/8.8.4.cats-athena) with SMTP id NAA13804 for ; Wed, 18 Apr 2001 13:46:24 -0700 (PDT) From: "Jim Whitehead" To: "WebDAV WG" Date: Wed, 18 Apr 2001 13:44:48 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: Issue: OPTION_WITH_DEPTH Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4829 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Originally raised in Mark D. Anderson's epic post to the WebDAV mailing list: http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0234.html The description of this issue in this issues list is: "Should the Depth header be usable with OPTIONS to perform a query of the capabilities of all resources in a hierarchy?" To me, the underlying issue is: Do clients need to be able to query the capabilities of all resources in a collection hierarchy in one network round trip? - Jim From w3c-dist-auth-request@w3.org Wed Apr 18 17:02:13 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA17902 for ; Wed, 18 Apr 2001 17:02:12 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA17672; Wed, 18 Apr 2001 16:52:47 -0400 (EDT) Resent-Date: Wed, 18 Apr 2001 16:52:47 -0400 (EDT) Resent-Message-Id: <200104182052.QAA17672@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id QAA17652 for ; Wed, 18 Apr 2001 16:52:43 -0400 (EDT) Received: from cats.ucsc.edu (rumpleteazer.ucsc.edu [128.114.129.45]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id QAA04660 for ; Wed, 18 Apr 2001 16:52:43 -0400 Received: from Tycho (dhcp-55-189.cse.ucsc.edu [128.114.55.189]) by cats.ucsc.edu (8.9.3/8.8.4.cats-athena) with SMTP id NAA15290 for ; Wed, 18 Apr 2001 13:52:45 -0700 (PDT) From: "Jim Whitehead" To: "WebDAV WG" Date: Wed, 18 Apr 2001 13:51:08 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: Issue: NEED_FOR_PUTL Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4830 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit This issue was originally raised by Sanford Barr: http://lists.w3.org/Archives/Public/w3c-dist-auth/1998JanMar/0186.html The description of the issue is: Is there a need for a PUTL (put which succeeds only if the resource is locked) method to avoid certain classes of overwrite conflicts, or a need to restrict the behavior of PUT on WebDAV servers to only accept writes if the resource is locked? Additional background rationale is provided in Section 6.7 ("Usage Considerations") of RFC 2518: Two clients A and B are interested in editing the resource ' index.html'. Client A is an HTTP client rather than a WebDAV client, and so does not know how to perform locking. Client A doesn't lock the document, but does a GET and begins editing. Client B does LOCK, performs a GET and begins editing. Client B finishes editing, performs a PUT, then an UNLOCK. Client A performs a PUT, overwriting and losing all of B's changes. There are several reasons why the WebDAV protocol itself cannot prevent this situation. First, it cannot force all clients to use locking because it must be compatible with HTTP clients that do not comprehend locking. Second, it cannot require servers to support locking because of the variety of repository implementations, some of which rely on reservations and merging rather than on locking. Finally, being stateless, it cannot enforce a sequence of operations like LOCK / GET / PUT / UNLOCK. WebDAV servers that support locking can reduce the likelihood that clients will accidentally overwrite each other's changes by requiring clients to lock resources before modifying them. Such servers would effectively prevent HTTP 1.0 and HTTP 1.1 clients from modifying resources. WebDAV clients can be good citizens by using a lock / retrieve / write /unlock sequence of operations (at least by default) whenever they interact with a WebDAV server that supports locking. HTTP 1.1 clients can be good citizens, avoiding overwriting other clients' changes, by using entity tags in If-Match headers with any requests that would modify resources. - Jim From w3c-dist-auth-request@w3.org Thu Apr 19 05:37:40 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA09281 for ; Thu, 19 Apr 2001 05:37:39 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id FAA20070; Thu, 19 Apr 2001 05:34:57 -0400 (EDT) Resent-Date: Thu, 19 Apr 2001 05:34:57 -0400 (EDT) Resent-Message-Id: <200104190934.FAA20070@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id FAA20050 for ; Thu, 19 Apr 2001 05:34:52 -0400 (EDT) Received: from hotmail.com (f41.law3.hotmail.com [209.185.241.41]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id FAA06196 for ; Thu, 19 Apr 2001 05:34:51 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 19 Apr 2001 02:34:50 -0700 Received: from 194.39.131.40 by lw3fd.law3.hotmail.msn.com with HTTP; Thu, 19 Apr 2001 09:34:50 GMT X-Originating-IP: [194.39.131.40] From: "sai reddy" To: w3c-dist-auth@w3.org Cc: ejw@cse.ucsc.edu Date: Thu, 19 Apr 2001 09:34:50 -0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 19 Apr 2001 09:34:50.0516 (UTC) FILETIME=[FB2DD540:01C0C8B3] Subject: Copying a file from local computer to the server in visual basic with xml Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4831 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Hi, I'm building an internet application using visual basic and xml HTTP Server and mod_dav. In this application the user has a form in the browser, she enters a path to the file on her local computer and some data describing this file. What I need to do on submit action is to send the data from the form and copy attached file from the local computer to the proper directory on the server. Does anyone have a piece of code in vb doing anything like that? Thanks in advance for any answers. sai _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. From w3c-dist-auth-request@w3.org Thu Apr 19 17:40:37 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA18851 for ; Thu, 19 Apr 2001 17:40:37 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA16611; Thu, 19 Apr 2001 15:23:14 -0400 (EDT) Resent-Date: Thu, 19 Apr 2001 15:23:14 -0400 (EDT) Resent-Message-Id: <200104191923.PAA16611@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id PAA16588 for ; Thu, 19 Apr 2001 15:23:10 -0400 (EDT) Received: from lsmail.office.lightsurf.com (lsmail.office.lightsurf.com [204.30.31.25]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id PAA14724 for ; Thu, 19 Apr 2001 15:23:10 -0400 Received: from urchin (urchin.office.lightsurf.com [10.10.10.133]) by lsmail.office.lightsurf.com (Mirapoint) with SMTP id AAK05555; Thu, 19 Apr 2001 12:23:06 -0700 (PDT) Reply-To: From: "Adam Freeman" To: Date: Thu, 19 Apr 2001 12:23:11 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Subject: Issue: BIND and MKRESOURCE Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4832 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi, I am a new subscriber to this list and have just started checking out WebDAV. I've been reviewing the memos for BIND and MKRESOURCE for redirecting references. What I would like to do with WebDAV is create a new resource that references an original resource but with different metadata (MKRESOURCE can be used to do this). The problem is MKRESOURCE will make it so that a redirect (302) is sent back to the client but I would like to send back the original resource bits. This is pretty much what BIND is supposed to do except that BIND also returns back the same metadata information for the bound uri as the original. It makes sense to me that a DAV server could *either* send back a 302 or the original bits given the resourcetype of the resource ... ? I managed to hack this by creating a soft link on the server using ln -s and then I could have different metadata for the reference than the original but have both return the original bits. For example, wh24.jpg wh24.ref -> wh24.jpg where wh24.jpg and wh24.ref have different metadata on the DAV server. Also, is the property supposed to do what I am trying to do. If so, I couldn't figure out how to use it properly. I tried placing the property in the root collection like this --> http://server/wh24.jpghttp://server/wh24 .ref but when I try to access wh24.ref on the server I get a 404. Thanks, Adam From w3c-dist-auth-request@w3.org Fri Apr 20 21:21:27 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA20814 for ; Fri, 20 Apr 2001 21:21:23 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id VAA11147; Fri, 20 Apr 2001 21:15:53 -0400 (EDT) Resent-Date: Fri, 20 Apr 2001 21:15:53 -0400 (EDT) Resent-Message-Id: <200104210115.VAA11147@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id VAA11124 for ; Fri, 20 Apr 2001 21:15:47 -0400 (EDT) Received: from e1.ny.us.ibm.com ([32.97.182.101]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id VAA22965 for ; Fri, 20 Apr 2001 21:15:47 -0400 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id VAA324284; Fri, 20 Apr 2001 21:13:46 -0400 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.117.200.72]) by northrelay02.pok.ibm.com (8.8.8m3/NCO v4.96) with ESMTP id VAA58858; Fri, 20 Apr 2001 21:10:19 -0400 Importance: Normal To: "Jim Whitehead" Cc: "WebDAV WG" X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "Jason Crawford" Date: Fri, 20 Apr 2001 20:55:11 -0400 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 5.0.7 |March 21, 2001) at 04/20/2001 09:15:10 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: Re: Issue: NEED_FOR_PUTL Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4834 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: << http://lists.w3.org/Archives/Public/w3c-dist-auth/1998JanMar/0186.html The description of the issue is: Is there a need for a PUTL (put which succeeds only if the resource is locked) method to avoid certain classes of overwrite conflicts, or a need to restrict the behavior of PUT on WebDAV servers to only accept writes if the resource is locked? >> Once again, just to get discussion going... I'll note that there hasn't seemed to be a lot of people asking for this so I'd suggest in the interest of keeping the spec simple that we defer this proposal until there appears to be more demand. The proposal actually provided for an option that didn't require a change to the functional spec so that remains an option for those that might later discover that this is important. I guess I'd consider a proposal to recomend that people lock resources before they do PUT on them. I'd actually prefer to not even do that though. I think we've made the issues clear enough in the spec. People can chose to put a lock on the resource if they want. Other opinions? J. From w3c-dist-auth-request@w3.org Fri Apr 20 23:57:38 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA24124 for ; Fri, 20 Apr 2001 23:57:38 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id UAA10679; Fri, 20 Apr 2001 20:56:02 -0400 (EDT) Resent-Date: Fri, 20 Apr 2001 20:56:02 -0400 (EDT) Resent-Message-Id: <200104210056.UAA10679@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id UAA10656 for ; Fri, 20 Apr 2001 20:55:57 -0400 (EDT) Received: from e1.ny.us.ibm.com ([32.97.182.101]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id UAA21655 for ; Fri, 20 Apr 2001 20:55:57 -0400 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id UAA157456; Fri, 20 Apr 2001 20:53:47 -0400 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.117.200.72]) by northrelay02.pok.ibm.com (8.8.8m3/NCO v4.96) with ESMTP id UAA18898; Fri, 20 Apr 2001 20:50:15 -0400 Importance: Normal To: "Jim Whitehead" Cc: "WebDAV WG" X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "Jason Crawford" Date: Fri, 20 Apr 2001 20:43:03 -0400 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 5.0.7 |March 21, 2001) at 04/20/2001 08:55:11 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: Re: Issue: OPTION_WITH_DEPTH Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4833 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Since noone else has spoken up, I'll respond just to try to get discussion going. << "Should the Depth header be usable with OPTIONS to perform a query of the capabilities of all resources in a hierarchy?" To me, the underlying issue is: Do clients need to be able to query the capabilities of all resources in a collection hierarchy in one network round trip? >> Unless someone speaks out vigorously in favor of OPTIONS with depth header, I suggest that we remain silent on that (to leave ourselves this option in the future) and leave it on the issues list. From w3c-dist-auth-request@w3.org Sat Apr 21 09:35:22 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA10126 for ; Sat, 21 Apr 2001 09:35:19 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id JAA27286; Sat, 21 Apr 2001 09:29:37 -0400 (EDT) Resent-Date: Sat, 21 Apr 2001 09:29:37 -0400 (EDT) Resent-Message-Id: <200104211329.JAA27286@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id JAA27254 for ; Sat, 21 Apr 2001 09:29:32 -0400 (EDT) Received: from sus-ma1it00.rational.com (ext-37140.rational.com [192.229.37.140]) by tux.w3.org (8.9.3/8.9.3) with SMTP id JAA05984 for ; Sat, 21 Apr 2001 09:29:33 -0400 Received: from 192.168.215.70 by sus-ma1it00.rational.com (InterScan E-Mail VirusWall NT); Sat, 21 Apr 2001 09:31:31 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Sat, 21 Apr 2001 09:31:31 -0400 Message-ID: <3906C56A7BD1F54593344C05BD1374B102B9086B@SUS-MA1IT01> From: "Clemm, Geoff" To: WebDAV WG Date: Sat, 21 Apr 2001 09:31:30 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: RE: Issue: NEED_FOR_PUTL Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4835 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: We certainly should not restrict the behavior of PUT to only accept writes if the resource is locked (for the reason given in 2518, namely interoperability with non-locking clients). The If header allows you to specify that a PUT should only succeed if the resource is locked, so I see no reason to add a PUTL method. So I agree with Jason's conclusions (i.e. reject this proposal). Cheers, Geoff -----Original Message----- From: Jason Crawford [mailto:ccjason@us.ibm.com] << http://lists.w3.org/Archives/Public/w3c-dist-auth/1998JanMar/0186.html The description of the issue is: Is there a need for a PUTL (put which succeeds only if the resource is locked) method to avoid certain classes of overwrite conflicts, or a need to restrict the behavior of PUT on WebDAV servers to only accept writes if the resource is locked? >> Once again, just to get discussion going... I'll note that there hasn't seemed to be a lot of people asking for this so I'd suggest in the interest of keeping the spec simple that we defer this proposal until there appears to be more demand. The proposal actually provided for an option that didn't require a change to the functional spec so that remains an option for those that might later discover that this is important. I guess I'd consider a proposal to recomend that people lock resources before they do PUT on them. I'd actually prefer to not even do that though. I think we've made the issues clear enough in the spec. People can chose to put a lock on the resource if they want. Other opinions? J. From w3c-dist-auth-request@w3.org Sat Apr 21 09:39:43 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA10136 for ; Sat, 21 Apr 2001 09:35:23 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id JAA27302; Sat, 21 Apr 2001 09:29:45 -0400 (EDT) Resent-Date: Sat, 21 Apr 2001 09:29:45 -0400 (EDT) Resent-Message-Id: <200104211329.JAA27302@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id JAA27256 for ; Sat, 21 Apr 2001 09:29:32 -0400 (EDT) Received: from sus-ma1it00.rational.com (ext-37140.rational.com [192.229.37.140]) by tux.w3.org (8.9.3/8.9.3) with SMTP id JAA05985 for ; Sat, 21 Apr 2001 09:29:33 -0400 Received: from 192.168.215.70 by sus-ma1it00.rational.com (InterScan E-Mail VirusWall NT); Sat, 21 Apr 2001 09:31:31 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Sat, 21 Apr 2001 09:31:31 -0400 Message-ID: <3906C56A7BD1F54593344C05BD1374B102B9086A@SUS-MA1IT01> From: "Clemm, Geoff" To: WebDAV WG Date: Sat, 21 Apr 2001 09:31:28 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: RE: Issue: OPTION_WITH_DEPTH Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4836 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: I agree with Jason. Until a pressing need is identified for this feature, I would not introduce it in the next rev. of the spec. In the versioning protocol, we have been using live properties to reflect information that varies from resource to resource, while using OPTIONS only for information about "capabilities of the server", i.e. information that is the same for all resources implemented by a given server. Cheers, Geoff -----Original Message----- From: Jason Crawford [mailto:ccjason@us.ibm.com] Sent: Friday, April 20, 2001 8:43 PM To: Jim Whitehead Cc: WebDAV WG Subject: Re: Issue: OPTION_WITH_DEPTH Since noone else has spoken up, I'll respond just to try to get discussion going. << "Should the Depth header be usable with OPTIONS to perform a query of the capabilities of all resources in a hierarchy?" To me, the underlying issue is: Do clients need to be able to query the capabilities of all resources in a collection hierarchy in one network round trip? >> Unless someone speaks out vigorously in favor of OPTIONS with depth header, I suggest that we remain silent on that (to leave ourselves this option in the future) and leave it on the issues list. From w3c-dist-auth-request@w3.org Sat Apr 21 15:10:15 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA11867 for ; Sat, 21 Apr 2001 15:10:12 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA09239; Sat, 21 Apr 2001 15:03:50 -0400 (EDT) Resent-Date: Sat, 21 Apr 2001 15:03:50 -0400 (EDT) Resent-Message-Id: <200104211903.PAA09239@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id PAA09210 for ; Sat, 21 Apr 2001 15:03:44 -0400 (EDT) Received: from sus-ma1it00.rational.com (ext-37140.rational.com [192.229.37.140]) by tux.w3.org (8.9.3/8.9.3) with SMTP id PAA01481 for ; Sat, 21 Apr 2001 15:03:45 -0400 Received: from 192.168.215.70 by sus-ma1it00.rational.com (InterScan E-Mail VirusWall NT); Sat, 21 Apr 2001 15:05:34 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Sat, 21 Apr 2001 15:05:33 -0400 Message-ID: <3906C56A7BD1F54593344C05BD1374B102B9088C@SUS-MA1IT01> From: "Clemm, Geoff" To: w3c-dist-auth@w3.org Date: Sat, 21 Apr 2001 15:05:06 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Issue: BIND and MKRESOURCE Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4837 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Redirecting GET and not PROPFIND would produce some rather surprising results, since a variety of live properties describe aspects of the content (e.g. DAV:getcontentlength, DAV:resourcetype), which is why a redirect reference is defined as acting uniformly across all operations. The DAV:source property is just informative ... setting or modifying it on a resource does not modify the result of operations applied to that resource. So there is currently no interoperable way to produce the result you have in mind. Cheers, Geoff -----Original Message----- From: Adam Freeman [mailto:afreeman@lightsurf.com] Sent: Thursday, April 19, 2001 3:23 PM To: w3c-dist-auth@w3.org Subject: Issue: BIND and MKRESOURCE Hi, I am a new subscriber to this list and have just started checking out WebDAV. I've been reviewing the memos for BIND and MKRESOURCE for redirecting references. What I would like to do with WebDAV is create a new resource that references an original resource but with different metadata (MKRESOURCE can be used to do this). The problem is MKRESOURCE will make it so that a redirect (302) is sent back to the client but I would like to send back the original resource bits. This is pretty much what BIND is supposed to do except that BIND also returns back the same metadata information for the bound uri as the original. It makes sense to me that a DAV server could *either* send back a 302 or the original bits given the resourcetype of the resource ... ? I managed to hack this by creating a soft link on the server using ln -s and then I could have different metadata for the reference than the original but have both return the original bits. For example, wh24.jpg wh24.ref -> wh24.jpg where wh24.jpg and wh24.ref have different metadata on the DAV server. Also, is the property supposed to do what I am trying to do. If so, I couldn't figure out how to use it properly. I tried placing the property in the root collection like this --> http://server/wh24.jpghttp://server/wh24 .ref but when I try to access wh24.ref on the server I get a 404. Thanks, Adam From w3c-dist-auth-request@w3.org Sat Apr 21 23:31:00 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA15518 for ; Sat, 21 Apr 2001 23:30:59 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id XAA20256; Sat, 21 Apr 2001 23:07:56 -0400 (EDT) Resent-Date: Sat, 21 Apr 2001 23:07:56 -0400 (EDT) Resent-Message-Id: <200104220307.XAA20256@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id XAA20232 for ; Sat, 21 Apr 2001 23:07:48 -0400 (EDT) Received: from lsmail.office.lightsurf.com (lsmail.office.lightsurf.com [204.30.31.25]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id XAA32089 for ; Sat, 21 Apr 2001 23:07:44 -0400 Received: from urchin (urchin.office.lightsurf.com [10.10.10.133]) by lsmail.office.lightsurf.com (Mirapoint) with SMTP id AAK09224; Sat, 21 Apr 2001 20:06:25 -0700 (PDT) Reply-To: From: "Adam Freeman" To: "Clemm, Geoff" , Date: Sat, 21 Apr 2001 20:06:25 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal In-Reply-To: <3906C56A7BD1F54593344C05BD1374B102B9088C@SUS-MA1IT01> Subject: RE: Issue: BIND and MKRESOURCE Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4838 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi, I guess what I am asking then is if something can be added to the spec that will basically create a link from the copy to the original whose sole purpose is to have different metadata associated with the link than the original resource. There may be a problem here with live properties but maybe it's up to the people who would be using this property. I guess it would look something like this --> >> Request: MKRESOURCE /~whitehead/dav/spec08.ref HTTP/1.1 Host: www.ics.uci.edu Content-Type: text/xml; charset="utf-8" Content-Length: xxx /i-d/draft-webdav-protocol-08.txt >> Response: HTTP/1.1 201 Created A specific case I can think of where this would be useful is if you had image data but had different operations on this image data depending on the resource. Like you might want to have different scaling operations applied to the image data so you could look at it at different resolutions for each of the different resources. (In this case, the live property DAV:getContentLength might be changed to reflect the different content that was being returned, or maybe not depending on what the user of the property wants). What do you think? - Adam -----Original Message----- From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff Sent: Saturday, April 21, 2001 12:05 PM To: w3c-dist-auth@w3.org Subject: RE: Issue: BIND and MKRESOURCE Redirecting GET and not PROPFIND would produce some rather surprising results, since a variety of live properties describe aspects of the content (e.g. DAV:getcontentlength, DAV:resourcetype), which is why a redirect reference is defined as acting uniformly across all operations. The DAV:source property is just informative ... setting or modifying it on a resource does not modify the result of operations applied to that resource. So there is currently no interoperable way to produce the result you have in mind. Cheers, Geoff -----Original Message----- From: Adam Freeman [mailto:afreeman@lightsurf.com] Sent: Thursday, April 19, 2001 3:23 PM To: w3c-dist-auth@w3.org Subject: Issue: BIND and MKRESOURCE Hi, I am a new subscriber to this list and have just started checking out WebDAV. I've been reviewing the memos for BIND and MKRESOURCE for redirecting references. What I would like to do with WebDAV is create a new resource that references an original resource but with different metadata (MKRESOURCE can be used to do this). The problem is MKRESOURCE will make it so that a redirect (302) is sent back to the client but I would like to send back the original resource bits. This is pretty much what BIND is supposed to do except that BIND also returns back the same metadata information for the bound uri as the original. It makes sense to me that a DAV server could *either* send back a 302 or the original bits given the resourcetype of the resource ... ? I managed to hack this by creating a soft link on the server using ln -s and then I could have different metadata for the reference than the original but have both return the original bits. For example, wh24.jpg wh24.ref -> wh24.jpg where wh24.jpg and wh24.ref have different metadata on the DAV server. Also, is the property supposed to do what I am trying to do. If so, I couldn't figure out how to use it properly. I tried placing the property in the root collection like this --> http://server/wh24.jpghttp://server/wh24 .ref but when I try to access wh24.ref on the server I get a 404. Thanks, Adam From w3c-dist-auth-request@w3.org Sun Apr 22 00:07:49 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA15892 for ; Sun, 22 Apr 2001 00:07:46 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id XAA20969; Sat, 21 Apr 2001 23:55:02 -0400 (EDT) Resent-Date: Sat, 21 Apr 2001 23:55:02 -0400 (EDT) Resent-Message-Id: <200104220355.XAA20969@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id XAA20943 for ; Sat, 21 Apr 2001 23:54:57 -0400 (EDT) Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id XAA02646 for ; Sat, 21 Apr 2001 23:54:57 -0400 Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e21.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id XAA270808 for ; Sat, 21 Apr 2001 23:49:08 -0500 Received: from d04nm203nm303.raleigh.ibm.com (d04nm303.raleigh.ibm.com [9.67.228.168]) by southrelay02.raleigh.ibm.com (8.11.1/NCO v4.96) with ESMTP id f3M3slh29108 for ; Sat, 21 Apr 2001 23:54:47 -0400 To: w3c-dist-auth@w3c.org X-Mailer: Lotus Notes Release 5.0.6a January 17, 2001 Message-ID: From: "Jim Amsden" Date: Sat, 21 Apr 2001 23:48:32 -0400 X-MIMETrack: Serialize by Router on D04NM303/04/M/IBM(Release 5.0.6 |December 14, 2000) at 04/21/2001 11:54:47 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: RE: Issue: BIND and MKRESOURCE Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4839 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: It sounds like you're trying to create a relationship between two different resources that happen to have the same content. This is application dependent behavior that should be enabled, but not necessarily supported by WebDAV. To do this you could create an empty resource for your new properties and establish a link between the resources using application specific properties. The protocol lets you do all of this, and your application can maintian the semantics as needed. "Adam Freeman" , f.com> Sent by: cc: w3c-dist-auth-requ Subject: RE: Issue: BIND and MKRESOURCE est@w3.org 04/21/2001 11:06 PM Please respond to afreeman Hi, I guess what I am asking then is if something can be added to the spec that will basically create a link from the copy to the original whose sole purpose is to have different metadata associated with the link than the original resource. There may be a problem here with live properties but maybe it's up to the people who would be using this property. I guess it would look something like this --> >> Request: MKRESOURCE /~whitehead/dav/spec08.ref HTTP/1.1 Host: www.ics.uci.edu Content-Type: text/xml; charset="utf-8" Content-Length: xxx /i-d/draft-webdav-protocol-08.txt >> Response: HTTP/1.1 201 Created A specific case I can think of where this would be useful is if you had image data but had different operations on this image data depending on the resource. Like you might want to have different scaling operations applied to the image data so you could look at it at different resolutions for each of the different resources. (In this case, the live property DAV:getContentLength might be changed to reflect the different content that was being returned, or maybe not depending on what the user of the property wants). What do you think? - Adam -----Original Message----- From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff Sent: Saturday, April 21, 2001 12:05 PM To: w3c-dist-auth@w3.org Subject: RE: Issue: BIND and MKRESOURCE Redirecting GET and not PROPFIND would produce some rather surprising results, since a variety of live properties describe aspects of the content (e.g. DAV:getcontentlength, DAV:resourcetype), which is why a redirect reference is defined as acting uniformly across all operations. The DAV:source property is just informative ... setting or modifying it on a resource does not modify the result of operations applied to that resource. So there is currently no interoperable way to produce the result you have in mind. Cheers, Geoff -----Original Message----- From: Adam Freeman [mailto:afreeman@lightsurf.com] Sent: Thursday, April 19, 2001 3:23 PM To: w3c-dist-auth@w3.org Subject: Issue: BIND and MKRESOURCE Hi, I am a new subscriber to this list and have just started checking out WebDAV. I've been reviewing the memos for BIND and MKRESOURCE for redirecting references. What I would like to do with WebDAV is create a new resource that references an original resource but with different metadata (MKRESOURCE can be used to do this). The problem is MKRESOURCE will make it so that a redirect (302) is sent back to the client but I would like to send back the original resource bits. This is pretty much what BIND is supposed to do except that BIND also returns back the same metadata information for the bound uri as the original. It makes sense to me that a DAV server could *either* send back a 302 or the original bits given the resourcetype of the resource ... ? I managed to hack this by creating a soft link on the server using ln -s and then I could have different metadata for the reference than the original but have both return the original bits. For example, wh24.jpg wh24.ref -> wh24.jpg where wh24.jpg and wh24.ref have different metadata on the DAV server. Also, is the property supposed to do what I am trying to do. If so, I couldn't figure out how to use it properly. I tried placing the property in the root collection like this --> http://server/wh24.jpghttp://server/wh24 .ref but when I try to access wh24.ref on the server I get a 404. Thanks, Adam From w3c-dist-auth-request@w3.org Sun Apr 22 01:00:41 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA16082 for ; Sun, 22 Apr 2001 01:00:40 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id AAA22142; Sun, 22 Apr 2001 00:47:18 -0400 (EDT) Resent-Date: Sun, 22 Apr 2001 00:47:18 -0400 (EDT) Resent-Message-Id: <200104220447.AAA22142@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id AAA22122 for ; Sun, 22 Apr 2001 00:47:14 -0400 (EDT) Received: from lsmail.office.lightsurf.com (lsmail.office.lightsurf.com [204.30.31.25]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id AAA06295 for ; Sun, 22 Apr 2001 00:47:14 -0400 Received: from urchin (urchin.office.lightsurf.com [10.10.10.133]) by lsmail.office.lightsurf.com (Mirapoint) with SMTP id AAK09257; Sat, 21 Apr 2001 21:46:51 -0700 (PDT) Reply-To: From: "Adam Freeman" To: "Jim Amsden" , Date: Sat, 21 Apr 2001 21:46:51 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal In-Reply-To: Subject: RE: Issue: BIND and MKRESOURCE Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4840 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi, To me, the metadata is the "view" for the "model" and you might want to have more than one view for your data. I could put up a zero byte file as the resource and then have my application-specific stuff return the "real href of this resource" in the properties of the resource. Or I could use the XLink language to send back a chunk of xml or store a .url file or do a soft link on the server or possibly a variety of other things. It just seems to me like this might be a real future need for other applications as well (any application that wants to have more than one set of metadata for a given data source). Instead of forcing users to do some weird hacks, why not address the need and stick it into web-dav. So the web-dav server interprets the resource and sends back the appropriate data. - Adam -----Original Message----- From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jim Amsden Sent: Saturday, April 21, 2001 8:49 PM To: w3c-dist-auth@w3c.org Subject: RE: Issue: BIND and MKRESOURCE It sounds like you're trying to create a relationship between two different resources that happen to have the same content. This is application dependent behavior that should be enabled, but not necessarily supported by WebDAV. To do this you could create an empty resource for your new properties and establish a link between the resources using application specific properties. The protocol lets you do all of this, and your application can maintian the semantics as needed. "Adam Freeman" , f.com> Sent by: cc: w3c-dist-auth-requ Subject: RE: Issue: BIND and MKRESOURCE est@w3.org 04/21/2001 11:06 PM Please respond to afreeman Hi, I guess what I am asking then is if something can be added to the spec that will basically create a link from the copy to the original whose sole purpose is to have different metadata associated with the link than the original resource. There may be a problem here with live properties but maybe it's up to the people who would be using this property. I guess it would look something like this --> >> Request: MKRESOURCE /~whitehead/dav/spec08.ref HTTP/1.1 Host: www.ics.uci.edu Content-Type: text/xml; charset="utf-8" Content-Length: xxx /i-d/draft-webdav-protocol-08.txt >> Response: HTTP/1.1 201 Created A specific case I can think of where this would be useful is if you had image data but had different operations on this image data depending on the resource. Like you might want to have different scaling operations applied to the image data so you could look at it at different resolutions for each of the different resources. (In this case, the live property DAV:getContentLength might be changed to reflect the different content that was being returned, or maybe not depending on what the user of the property wants). What do you think? - Adam -----Original Message----- From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff Sent: Saturday, April 21, 2001 12:05 PM To: w3c-dist-auth@w3.org Subject: RE: Issue: BIND and MKRESOURCE Redirecting GET and not PROPFIND would produce some rather surprising results, since a variety of live properties describe aspects of the content (e.g. DAV:getcontentlength, DAV:resourcetype), which is why a redirect reference is defined as acting uniformly across all operations. The DAV:source property is just informative ... setting or modifying it on a resource does not modify the result of operations applied to that resource. So there is currently no interoperable way to produce the result you have in mind. Cheers, Geoff -----Original Message----- From: Adam Freeman [mailto:afreeman@lightsurf.com] Sent: Thursday, April 19, 2001 3:23 PM To: w3c-dist-auth@w3.org Subject: Issue: BIND and MKRESOURCE Hi, I am a new subscriber to this list and have just started checking out WebDAV. I've been reviewing the memos for BIND and MKRESOURCE for redirecting references. What I would like to do with WebDAV is create a new resource that references an original resource but with different metadata (MKRESOURCE can be used to do this). The problem is MKRESOURCE will make it so that a redirect (302) is sent back to the client but I would like to send back the original resource bits. This is pretty much what BIND is supposed to do except that BIND also returns back the same metadata information for the bound uri as the original. It makes sense to me that a DAV server could *either* send back a 302 or the original bits given the resourcetype of the resource ... ? I managed to hack this by creating a soft link on the server using ln -s and then I could have different metadata for the reference than the original but have both return the original bits. For example, wh24.jpg wh24.ref -> wh24.jpg where wh24.jpg and wh24.ref have different metadata on the DAV server. Also, is the property supposed to do what I am trying to do. If so, I couldn't figure out how to use it properly. I tried placing the property in the root collection like this --> http://server/wh24.jpghttp://server/wh24 .ref but when I try to access wh24.ref on the server I get a 404. Thanks, Adam From w3c-dist-auth-request@w3.org Sun Apr 22 09:39:10 2001 Received: from www19.w3.org ([18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA08485 for ; Sun, 22 Apr 2001 09:39:10 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id JAA05594; Sun, 22 Apr 2001 09:26:44 -0400 (EDT) Resent-Date: Sun, 22 Apr 2001 09:26:44 -0400 (EDT) Resent-Message-Id: <200104221326.JAA05594@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id JAA05574 for ; Sun, 22 Apr 2001 09:26:31 -0400 (EDT) Received: from e1.ny.us.ibm.com ([32.97.182.101]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id JAA11117 for ; Sun, 22 Apr 2001 09:26:31 -0400 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id JAA49852; Sun, 22 Apr 2001 09:24:08 -0400 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.117.200.72]) by northrelay02.pok.ibm.com (8.8.8m3/NCO v4.96) with ESMTP id JAA62552; Sun, 22 Apr 2001 09:20:41 -0400 Importance: Normal To: Cc: "Clemm, Geoff" , X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "Jason Crawford" Date: Sun, 22 Apr 2001 00:41:26 -0400 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 5.0.7 |March 21, 2001) at 04/22/2001 09:25:34 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: RE: Issue: BIND and MKRESOURCE Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4841 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: I think it's important to know your intent. Here's just another stab in the dark... A given server can do this if it supports a live resource that can be used to map to another resource behind the scenes. You set it's source property and it could return that content for get request... yet it would have it's own properties. Of course I don't know if this fulfills your intent. The advanced collections redirect reference probably do what you just described, but of course they don't hide it from the client. And I think you said you didn't want a redirect. So unless you're willing to do a redirect or set up a live resource on the server, you can't do this right now. J. ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com From w3c-dist-auth-request@w3.org Sun Apr 22 16:31:56 2001 Received: from www19.w3.org ([18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA13314 for ; Sun, 22 Apr 2001 16:31:54 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA17180; Sun, 22 Apr 2001 16:13:07 -0400 (EDT) Resent-Date: Sun, 22 Apr 2001 16:13:07 -0400 (EDT) Resent-Message-Id: <200104222013.QAA17180@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id QAA17156 for ; Sun, 22 Apr 2001 16:13:02 -0400 (EDT) Received: from mail.gmx.net (pop.gmx.net [194.221.183.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id QAA07469 for ; Sun, 22 Apr 2001 16:13:01 -0400 Received: (qmail 14083 invoked by uid 0); 22 Apr 2001 20:12:26 -0000 Received: from p3ee24790.dip.t-dialin.net (HELO lisa) (62.226.71.144) by mail.gmx.net (mp003-rz3) with SMTP; 22 Apr 2001 20:12:26 -0000 From: "Julian Reschke" To: "WebDAV WG" Date: Sun, 22 Apr 2001 22:12:25 +0200 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C0CB79.4F88CA60" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: AW: Issue: PROP_ATTR Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4842 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C0CB79.4F88CA60 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Hi, I've spent some time looking at the current RFC, and what needs to be done to get this subject defined more precisely. The wording on property names seems to be OK (if the appendix about the non W3C-complaint name matching is removed). It probably could be less vague on what it means by a "schema", though. In addition, I would propose to have the section about property names moved *in front* of the section about property values (so 4.4 and 4.5 would be exchanged). I've also tried to add text to 4.4 that specifies the current consensus on how XML attributes in the property element are treated... Here's my attempt (comments are welcome): 4.4. Property Values The value of a property when expressed in XML MUST be well formed. XML has been chosen because it is a flexible, self-describing, structured data format that supports rich schema definitions, and because of its support for multiple character sets. XML's self- describing nature allows any property's value to be extended by adding new elements. Older clients will not break when they encounter extensions because they will still have the data specified in the original schema and will ignore elements they do not understand. XML's support for multiple character sets allows any human-readable property to be encoded and read in a character set familiar to the user. XML's support for multiple human languages, using the "xml:lang" attribute, handles cases where the same character set is employed by multiple human languages. TEXT BELOW WAS ADDED... The value of a property is defined in terms of the W3C recommendation "XML Information Set" [XML-INFOSET] and "Canonical XML" [RFC3076]. It consists of a subset of the property element's information items, of which some are optional (that is, a server MAY choose not to persist them). [prefix] (optional) The namespace prefix part of the element-type name. [children] (required) An ordered list of child information items, in document order. Note that the full Information Set of each child is part of the value. [attributes] (optional) An unordered set of attribute information items. [namespace attributes] (optional) An unordered set of attribute information items, one for each of the namespace declarations. [in-scope namespaces] (optional) An unordered set of namespace information items, one for each of the namespaces in effect for this element. [base URI] (optional) The base URI of the element, as computed by the method of XML Base. In addition, attributes from the XML namespace (http://www.w3.org/XML/1998/namespace) are inherited by means of section 2.4 of [RFC3076]: xml:lang (required) other attributes from the XML namespace (optional) 4.4.1. Examples for property values Set request: xyz Inheritance of attributes from XML namespaces as defined in section 2.4 of [RFC3076]: xyz The value of the property named ("http://foo.bar.com", "bar") thus is: [prefix] "foo" [children] 3 character information items [attributes] attribute information items, describing "attr", "xml:lang" and "x:space" [namespace attributes] (empty) [in-scope namespaces] the namespace information items (no value, "DAV:"), ("foo", "http://foo.bar.com"), ("x", "http://www.w3.org/XML/1998/namespace"), ("xml", "http://www.w3.org/XML/1998/namespace") [base URI] no value Removal of optional information: xyz The value of the property named ("http://foo.bar.com", "bar") then becomes: [children] 3 character information items [attributes] attribute information item, describing "xml:lang" ------=_NextPart_000_0001_01C0CB79.4F88CA60 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Hi,

I've spent some time = looking at the=20 current RFC, and what needs to be done to get this subject defined more=20 precisely.

The wording on property = names seems to=20 be OK (if the appendix about the non W3C-complaint name matching is = removed). It=20 probably could be less vague on what it means by a "schema", though. In=20 addition, I would propose to have the section about property names moved = *in=20 front* of the section about property values (so 4.4 and 4.5 would be=20 exchanged).

I've also tried to add = text to 4.4 that=20 specifies the current consensus on how XML attributes in the property = element=20 are treated... Here's my attempt (comments are welcome):

4.4.  Property Values

The value of a property when expressed = in XML=20 MUST be well formed.

XML has been chosen because it is a = flexible,=20 self-describing, structured data format that supports rich schema = definitions,=20 and because of its support for multiple character sets. XML's self- = describing=20 nature allows any property's value to be extended by adding new = elements. Older=20 clients will not break when they encounter extensions because they will = still=20 have the data specified in the original schema and will ignore elements = they do=20 not understand. XML's support for multiple character sets allows any=20 human-readable property to be encoded and read in a character set = familiar to=20 the user. XML's support for multiple human languages, using the = "xml:lang"=20 attribute, handles cases where the same character set is employed by = multiple=20 human languages.

TEXT BELOW WAS ADDED...

The value of a property is defined in = terms of=20 the W3C recommendation "XML Information Set" [XM= L-INFOSET]=20 and "Canonical XML" [RFC307= 6].=20 It consists of a subset of the property element's information = items,=20 of which some are optional (that is, a server MAY choose not to persist = them).=20

[prefix]=20
(optional) The namespace prefix part of the element-type name.=20
[children]=20
(required) An ordered list of child information items, in = document=20 order. Note that the full Information Set of each child is part of = the=20 value.=20
[attributes]=20
(optional) An unordered set of attribute information items.=20
[namespace attributes]=20
(optional) An unordered set of attribute information items, one = for each=20 of the namespace declarations.=20
[in-scope namespaces]=20
(optional) An unordered set of namespace information items, one = for each=20 of the namespaces in effect for this element.=20
[base URI]=20
(optional) The base URI of the element, as computed by the = method of XML=20 Base.

In addition, attributes from the XML = namespace=20 (http://www.w3.org/XML/1998/= namespace)=20 are inherited by means of section 2.4 of [RFC307= 6]:=20

xml:lang=20
(required)=20
other attributes from the XML namespace=20
(optional)

4.4.1.  Examples for property = values

Set request:

  <propertyupdate
	  xmlns=3D"DAV:" xmlns:foo=3D"http://foo.bar.com" =
xmlns:x=3D"http://www.w3.org/XML/1998/namespace"
		xml:lang=3D"en" x:space=3D"preserve">
	  <set>
	    <foo:bar attr=3D"test">xyz</foo:bar>
	  </set>
  </propertyupdate>

Inheritance of attributes from XML namespaces as defined in section = 2.4 of [RFC307= 6]:

  <propertyupdate
	  xmlns=3D"DAV:" xmlns:foo=3D"http://foo.bar.com" =
xmlns:=3D"http://www.w3.org/XML/1998/namespace"
		xml:lang=3D"en" x:space=3D"preserve">
	  <set>
	    <foo:bar attr=3D"test" xml:lang=3D"en" =
x:space=3D"preserve">xyz</foo:bar>
	  </set>
  </propertyupdate>

The value of the property named=20 ("http://foo.bar.com", "bar") thus is:=20

[prefix]=20
"foo"=20
[children]=20
3 character information items=20
[attributes]=20
attribute information items, describing "attr", "xml:lang" and = "x:space"=20
[namespace attributes]=20
(empty)=20
[in-scope namespaces]=20
the namespace information items (no value, "DAV:"), ("foo",=20 "http://foo.bar.com"), ("x", = "http://www.w3.org/XML/1998/namespace"),=20 ("xml", "http://www.w3.org/XML/1998/namespace")=20
[base URI]=20
no value

Removal of optional information:

  <propertyupdate
	  xmlns=3D"DAV:" xmlns:foo=3D"http://foo.bar.com" =
xmlns:x=3D"http://www.w3.org/XML/1998/namespace"
		xml:lang=3D"en" x:space=3D"preserve">
	  <set>
	    <foo:bar xml:lang=3D"en">xyz</foo:bar>
	  </set>
  </propertyupdate>

The value of the property named=20 ("http://foo.bar.com", "bar") then becomes:=20

[children]=20
3 character information items=20
[attributes]=20
attribute information item, describing = "xml:lang"

 ------=_NextPart_000_0001_01C0CB79.4F88CA60-- From w3c-dist-auth-request@w3.org Mon Apr 23 09:44:59 2001 Received: from www19.w3.org ([18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA04424 for ; Mon, 23 Apr 2001 09:44:59 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id JAA03713; Mon, 23 Apr 2001 09:30:27 -0400 (EDT) Resent-Date: Mon, 23 Apr 2001 09:30:27 -0400 (EDT) Resent-Message-Id: <200104231330.JAA03713@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id JAA03669 for ; Mon, 23 Apr 2001 09:30:22 -0400 (EDT) Received: from exzh001.alcatel.ch (exzh001.alcatel.ch [130.198.1.105]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id JAA30888 for ; Mon, 23 Apr 2001 09:30:21 -0400 Received: from merlin.alcatel.ch ([130.198.1.111]) by exzh001.alcatel.ch with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id JPTT9BB2; Mon, 23 Apr 2001 15:29:45 +0200 Received: from ssdsv100.alcatel.ch (ssdsv100.alcatel.ch [130.198.42.54]) by merlin.alcatel.ch (8.9.3+Sun/8.9.3) with ESMTP id PAA06769 for ; Mon, 23 Apr 2001 15:29:44 +0200 (MEST) Received: from alcatel.ch (s12ux14.alcatel.ch [130.198.42.157]) by ssdsv100.alcatel.ch (8.8.8+Sun/8.8.8) with ESMTP id PAA04698 for ; Mon, 23 Apr 2001 15:29:43 +0200 (MET DST) Message-ID: <3AE42FBA.6F026D15@alcatel.ch> Date: Mon, 23 Apr 2001 15:35:54 +0200 From: Anirvan Basu Organization: Alcatel Schweiz AG X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: w3c-dist-auth@w3.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [w3c-dist-auth] Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4843 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit unsubscribe From w3c-dist-auth-request@w3.org Mon Apr 23 10:50:23 2001 Received: from www19.w3.org ([18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA05058 for ; Mon, 23 Apr 2001 10:50:23 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id KAA09807; Mon, 23 Apr 2001 10:36:01 -0400 (EDT) Resent-Date: Mon, 23 Apr 2001 10:36:01 -0400 (EDT) Resent-Message-Id: <200104231436.KAA09807@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id KAA09772 for ; Mon, 23 Apr 2001 10:35:55 -0400 (EDT) Received: from smtpmta2.i2.com (smtpmta2.i2.com [64.26.226.11]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id KAA06210 for ; Mon, 23 Apr 2001 10:35:52 -0400 From: Viktor_Lioutyi@i2.com Received: from i2burlington.i2.com ([10.76.2.7]) by smtpmta2.i2.com (Lotus Domino Release 5.0.5) with ESMTP id 2001042309354782:108490 ; Mon, 23 Apr 2001 09:35:47 -0500 To: w3c-dist-auth@w3.org X-Mailer: Lotus Notes Release 5.0.4 June 8, 2000 Message-ID: Date: Mon, 23 Apr 2001 10:35:46 -0400 MIME-Version: 1.0 X-MIMETrack: Serialize by Router on i2Burlington/Servers/i2Tech(Release 5.0.5 |September 22, 2000) at 04/23/2001 10:35:47 AM, Itemize by SMTP Server on SMTPMTA2/i2Tech(Release 5.0.5 |September 22, 2000) at 04/23/2001 09:35:47 AM, Serialize by Router on SMTPMTA2/i2Tech(Release 5.0.5 |September 22, 2000) at 04/23/2001 09:35:52 AM, Serialize complete at 04/23/2001 09:35:52 AM Content-type: text/plain; charset=us-ascii Subject: [w3c-dist-auth] Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4844 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: unsubscribe From w3c-dist-auth-request@w3.org Mon Apr 23 11:26:12 2001 Received: from www19.w3.org ([18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA05492 for ; Mon, 23 Apr 2001 11:26:11 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id LAA13406; Mon, 23 Apr 2001 11:11:20 -0400 (EDT) Resent-Date: Mon, 23 Apr 2001 11:11:20 -0400 (EDT) Resent-Message-Id: <200104231511.LAA13406@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id LAA13386 for ; Mon, 23 Apr 2001 11:11:16 -0400 (EDT) Received: from d06lmsgate.uk.ibm.COM (d06lmsgate.uk.ibm.com [195.212.29.1]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id LAA11404 for ; Mon, 23 Apr 2001 11:11:17 -0400 From: Tim_Ellison@uk.ibm.com Received: from d06relay02.portsmouth.uk.ibm.com (d06relay02.portsmouth.uk.ibm.com [9.166.84.148]) by d06lmsgate.uk.ibm.COM (1.0.0) with ESMTP id PAA153636; Mon, 23 Apr 2001 15:53:44 +0100 Received: from d06mta07.portsmouth.uk.ibm.com (d06mta07_cs0 [9.180.35.5]) by d06relay02.portsmouth.uk.ibm.com (8.8.8m3/NCO v4.96) with SMTP id QAA232458; Mon, 23 Apr 2001 16:10:35 +0100 Received: by d06mta07.portsmouth.uk.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 80256A37.00535973 ; Mon, 23 Apr 2001 16:10:23 +0100 X-Lotus-FromDomain: IBMGB To: Viktor_Lioutyi@i2.com cc: w3c-dist-auth@w3.org Message-ID: <80256A37.00535809.00@d06mta07.portsmouth.uk.ibm.com> Date: Mon, 23 Apr 2001 16:09:58 +0100 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Re: [w3c-dist-auth] Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4845 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Viktor, Try sending your request to w3c-dist-auth-request@w3.org From w3c-dist-auth-request@w3.org Mon Apr 23 16:02:06 2001 Received: from www19.w3.org ([18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA11694 for ; Mon, 23 Apr 2001 16:02:05 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA01109; Mon, 23 Apr 2001 15:46:15 -0400 (EDT) Resent-Date: Mon, 23 Apr 2001 15:46:15 -0400 (EDT) Resent-Message-Id: <200104231946.PAA01109@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id PAA01089 for ; Mon, 23 Apr 2001 15:46:10 -0400 (EDT) Received: from cats.ucsc.edu (rumpleteazer.ucsc.edu [128.114.129.45]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id PAA12884 for ; Mon, 23 Apr 2001 15:46:10 -0400 Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177]) by cats.ucsc.edu (8.9.3/8.8.4.cats-athena) with SMTP id MAA13583 for ; Mon, 23 Apr 2001 12:46:08 -0700 (PDT) From: "Jim Whitehead" To: "WebDAV WG" Date: Mon, 23 Apr 2001 12:44:28 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: FW: RE: Issue: NEED_FOR_PUTL Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4846 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Accidentally caught by the spam filter. I've added Ron Jacob's email address to the accept2 list. - Jim -----Original Message----- From: Ron Jacobs [mailto:rjacobs@gforce.com] Sent: Monday, April 23, 2001 11:18 AM To: WebDAV WG Subject: [Moderator Action] RE: Issue: NEED_FOR_PUTL Is there, or should there be, anything in WebDAV that prevents a server from refusing to process any PUT requests for an unlocked resource? Seems to me that this issue fits cleanly into the set of decisions that are left to the server implementer and that can be decided without impacting WebDAV compliance. Thanks, Ron -----Original Message----- From: Clemm, Geoff [mailto:gclemm@rational.com] Sent: Saturday, April 21, 2001 6:32 AM To: WebDAV WG Subject: RE: Issue: NEED_FOR_PUTL We certainly should not restrict the behavior of PUT to only accept writes if the resource is locked (for the reason given in 2518, namely interoperability with non-locking clients). The If header allows you to specify that a PUT should only succeed if the resource is locked, so I see no reason to add a PUTL method. So I agree with Jason's conclusions (i.e. reject this proposal). Cheers, Geoff -----Original Message----- From: Jason Crawford [mailto:ccjason@us.ibm.com] << http://lists.w3.org/Archives/Public/w3c-dist-auth/1998JanMar/0186.html The description of the issue is: Is there a need for a PUTL (put which succeeds only if the resource is locked) method to avoid certain classes of overwrite conflicts, or a need to restrict the behavior of PUT on WebDAV servers to only accept writes if the resource is locked? >> Once again, just to get discussion going... I'll note that there hasn't seemed to be a lot of people asking for this so I'd suggest in the interest of keeping the spec simple that we defer this proposal until there appears to be more demand. The proposal actually provided for an option that didn't require a change to the functional spec so that remains an option for those that might later discover that this is important. I guess I'd consider a proposal to recomend that people lock resources before they do PUT on them. I'd actually prefer to not even do that though. I think we've made the issues clear enough in the spec. People can chose to put a lock on the resource if they want. Other opinions? J. From w3c-dist-auth-request@w3.org Wed Apr 25 14:12:42 2001 Received: from www19.w3.org ([18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA25040 for ; Wed, 25 Apr 2001 14:12:41 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA15124; Wed, 25 Apr 2001 13:53:17 -0400 (EDT) Resent-Date: Wed, 25 Apr 2001 13:53:17 -0400 (EDT) Resent-Message-Id: <200104251753.NAA15124@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id NAA15092 for ; Wed, 25 Apr 2001 13:53:12 -0400 (EDT) Received: from cats.ucsc.edu (rumpleteazer.ucsc.edu [128.114.129.45]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id NAA10549 for ; Wed, 25 Apr 2001 13:53:12 -0400 Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177]) by cats.ucsc.edu (8.9.3/8.8.4.cats-athena) with SMTP id KAA05008 for ; Wed, 25 Apr 2001 10:53:11 -0700 (PDT) From: "Jim Whitehead" To: "WebDAV WG" Date: Wed, 25 Apr 2001 10:51:32 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: Resolved: OPTION_WITH_DEPTH Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4847 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Since there have been two voices against, and none in favor, I'm going to record this issue as resolved. The status quo will continue, the specification will be silent on this issue, neither providing support for OPTION with Depth, nor forbidding it. - Jim Jason Crawford writes: > Unless someone speaks out vigorously in favor of OPTIONS with > depth header, > I suggest that we remain silent on that (to leave ourselves this option in > the future) and leave it on the issues list. Geoff Clemm writes: > I agree with Jason. Until a pressing need is identified for this > feature, I would not introduce it in the next rev. of the spec. > In the versioning protocol, we have been using live properties to > reflect information that varies from resource to resource, while > using OPTIONS only for information about "capabilities of the server", > i.e. information that is the same for all resources implemented > by a given server. From w3c-dist-auth-request@w3.org Wed Apr 25 14:30:13 2001 Received: from www19.w3.org ([18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA25857 for ; Wed, 25 Apr 2001 14:30:11 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA16899; Wed, 25 Apr 2001 14:21:38 -0400 (EDT) Resent-Date: Wed, 25 Apr 2001 14:21:38 -0400 (EDT) Resent-Message-Id: <200104251821.OAA16899@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id OAA16879 for ; Wed, 25 Apr 2001 14:21:34 -0400 (EDT) Received: from cats.ucsc.edu (rumpleteazer.ucsc.edu [128.114.129.45]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id OAA13152 for ; Wed, 25 Apr 2001 14:21:34 -0400 Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177]) by cats.ucsc.edu (8.9.3/8.8.4.cats-athena) with SMTP id LAA12384 for ; Wed, 25 Apr 2001 11:21:33 -0700 (PDT) From: "Jim Whitehead" To: "WebDAV WG" Date: Wed, 25 Apr 2001 11:19:54 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: Issue: ALLPROP_AND_COMPUTED Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4849 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit This issue is currently stated as: If a server has some computed properties which are expensive to compute, then PROPFIND allprop, especially PROPFIND allprop with Depth infinity can be an expensive operation. There should be an implementation note added to the document noting this problem. Suggestion that servers might want to be conservative in their implementation of such compute expensive properties. Clients should only perform PROPFIND allprop when necessary, not by default. It was raised by Ken Coar at the Advanced Collections breakout at the Orlando IETF meeting. But, since that time there has been a substantive discussion of this issue, begun by Lisa Dusseault, starting at: http://lists.w3.org/Archives/Public/w3c-dist-auth/2000OctDec/0034.html My understanding of the rough sentiment of the working group is: 1) PROPFIND allprop requests with Depth infinity should be deprecated. That is, PROPFIND allprop with Depth infinity will remain in the WebDAV Distributed Authoring Protocol, but there will be a requirements added that new clients MUST NOT use this capability. When existing clients are revised, they SHOULD be rewritten to avoid using PROPFIND allprop Depth infinity requests. This will only apply to PROPFIND allprop with Depth infinity -- PROPFIND allprop for Depth 0 and 1 will still be OK. 2) The default behavior of PROPFIND will be changed so it is Depth 0, not Depth infinity. - Jim From w3c-dist-auth-request@w3.org Wed Apr 25 14:48:36 2001 Received: from www19.w3.org ([18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA26664 for ; Wed, 25 Apr 2001 14:48:34 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA17577; Wed, 25 Apr 2001 14:34:40 -0400 (EDT) Resent-Date: Wed, 25 Apr 2001 14:34:40 -0400 (EDT) Resent-Message-Id: <200104251834.OAA17577@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id OAA17557 for ; Wed, 25 Apr 2001 14:34:36 -0400 (EDT) Received: from sus-ma1it00.rational.com (ext-37140.rational.com [192.229.37.140]) by tux.w3.org (8.9.3/8.9.3) with SMTP id OAA14456 for ; Wed, 25 Apr 2001 14:34:34 -0400 Received: from 192.168.215.70 by sus-ma1it00.rational.com (InterScan E-Mail VirusWall NT); Wed, 25 Apr 2001 14:36:33 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Wed, 25 Apr 2001 14:36:33 -0400 Message-ID: <3906C56A7BD1F54593344C05BD1374B1018E2386@SUS-MA1IT01> From: "Clemm, Geoff" To: WebDAV WG Date: Wed, 25 Apr 2001 14:36:39 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Issue: ALLPROP_AND_COMPUTED Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4851 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: I believe it is simpler and more desireable to deprecate the use of allprop in all situations, not just Depth:infinity. Cheers, Geoff -----Original Message----- From: Jim Whitehead [mailto:ejw@cse.ucsc.edu] Sent: Wednesday, April 25, 2001 2:20 PM To: WebDAV WG Subject: Issue: ALLPROP_AND_COMPUTED This issue is currently stated as: If a server has some computed properties which are expensive to compute, then PROPFIND allprop, especially PROPFIND allprop with Depth infinity can be an expensive operation. There should be an implementation note added to the document noting this problem. Suggestion that servers might want to be conservative in their implementation of such compute expensive properties. Clients should only perform PROPFIND allprop when necessary, not by default. It was raised by Ken Coar at the Advanced Collections breakout at the Orlando IETF meeting. But, since that time there has been a substantive discussion of this issue, begun by Lisa Dusseault, starting at: http://lists.w3.org/Archives/Public/w3c-dist-auth/2000OctDec/0034.html My understanding of the rough sentiment of the working group is: 1) PROPFIND allprop requests with Depth infinity should be deprecated. That is, PROPFIND allprop with Depth infinity will remain in the WebDAV Distributed Authoring Protocol, but there will be a requirements added that new clients MUST NOT use this capability. When existing clients are revised, they SHOULD be rewritten to avoid using PROPFIND allprop Depth infinity requests. This will only apply to PROPFIND allprop with Depth infinity -- PROPFIND allprop for Depth 0 and 1 will still be OK. 2) The default behavior of PROPFIND will be changed so it is Depth 0, not Depth infinity. - Jim From w3c-dist-auth-request@w3.org Wed Apr 25 14:55:16 2001 Received: from www19.w3.org ([18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA26914 for ; Wed, 25 Apr 2001 14:55:08 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA18331; Wed, 25 Apr 2001 14:46:06 -0400 (EDT) Resent-Date: Wed, 25 Apr 2001 14:46:06 -0400 (EDT) Resent-Message-Id: <200104251846.OAA18331@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id OAA18299 for ; Wed, 25 Apr 2001 14:45:54 -0400 (EDT) Received: from sus-ma1it00.rational.com (ext-37140.rational.com [192.229.37.140]) by tux.w3.org (8.9.3/8.9.3) with SMTP id OAA15562 for ; Wed, 25 Apr 2001 14:45:54 -0400 Received: from 192.168.215.70 by sus-ma1it00.rational.com (InterScan E-Mail VirusWall NT); Wed, 25 Apr 2001 14:48:00 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Wed, 25 Apr 2001 14:48:00 -0400 Message-ID: <3906C56A7BD1F54593344C05BD1374B1018E2388@SUS-MA1IT01> From: "Clemm, Geoff" To: WebDAV WG Date: Wed, 25 Apr 2001 14:48:06 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Issue: XML_LANG_CLARIFY Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4853 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Unless someone has a good argument against having the lang attribute appear on the property node, I agree with JimW that it should appear on the property node. Cheers, Geoff -----Original Message----- From: Jim Whitehead [mailto:ejw@cse.ucsc.edu] Sent: Wednesday, April 25, 2001 2:29 PM To: WebDAV WG Subject: Issue: XML_LANG_CLARIFY This issue is another way of attacking the XML property round-trip behavior problem. The issue was originally raised by Jim Davis: http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0203.html Jim Davis writes: It is unclear from the spec (12.13.2) where exactly the xml:lang attribute must appear in the XML request body in order to be stored. May it appear anywhere in the XML tree (even, eg as an attribute of the DAV:propstore element)? Or must is appear on a child of the property element within the DAV:prop? The XML spec says clearly that xml:lang may appear anywhere, and that is has scope over all children: "The intent declared with xml:lang is considered to apply to all elements within the content of the element where it is specified, unless overridden with another instance of xml:lang." On the other hand the DAV spec says: "Language tagging information in the property's value (in the "xml:lang" attribute, if present) MUST be persistently stored along with the property, and MUST be subsequently retrievable using PROPFIND." At least one implementor has interpreted this to mean it must be on the child. We need clarity on this, as it affects interoperability. To elaborate, can I say Kikkers in de koek Or do I have to push the attribute down into the child, as in Kikkers in de koek Note that the latter interpretation has two very bad consequences: 1) Since the client has to invent a placeholder element, and there's no obvious choice for the name of the element, it shoots interoperability. No two clients will use the same element name for this placeholder, and hence the values won't be comparable. 2) Since the current DASL base search protocol can't search properties whose values are structures (ie. are elements, on the wire) no language tagged property value will be searchable. So I think this interpretation must be wrong. Do you agree? ---- Section 12.13.2 of RFC 2518 currently states: Language tagging information in the property's value (in the "xml:lang" attribute, if present) MUST be persistently stored along with the property, and MUST be subsequently retrievable using PROPFIND. - Jim From w3c-dist-auth-request@w3.org Wed Apr 25 15:28:13 2001 Received: from www19.w3.org ([18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA28054 for ; Wed, 25 Apr 2001 15:28:11 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA15141; Wed, 25 Apr 2001 13:53:26 -0400 (EDT) Resent-Date: Wed, 25 Apr 2001 13:53:26 -0400 (EDT) Resent-Message-Id: <200104251753.NAA15141@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id NAA15094 for ; Wed, 25 Apr 2001 13:53:12 -0400 (EDT) Received: from cats.ucsc.edu (rumpleteazer.ucsc.edu [128.114.129.45]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id NAA10548 for ; Wed, 25 Apr 2001 13:53:12 -0400 Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177]) by cats.ucsc.edu (8.9.3/8.8.4.cats-athena) with SMTP id KAA05005 for ; Wed, 25 Apr 2001 10:53:10 -0700 (PDT) From: "Jim Whitehead" To: "WebDAV WG" Date: Wed, 25 Apr 2001 10:51:31 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: Resolved: NEED_FOR_PUTL Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4848 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Since there are no voices in favor of the PUTL proposal, I'm going to mark this issue as resolved. No specification changes will be made. - Jim From w3c-dist-auth-request@w3.org Wed Apr 25 16:03:18 2001 Received: from www19.w3.org ([18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA29400 for ; Wed, 25 Apr 2001 16:03:18 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA23257; Wed, 25 Apr 2001 15:55:35 -0400 (EDT) Resent-Date: Wed, 25 Apr 2001 15:55:35 -0400 (EDT) Resent-Message-Id: <200104251955.PAA23257@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id PAA23223 for ; Wed, 25 Apr 2001 15:55:27 -0400 (EDT) Received: from e1.ny.us.ibm.com ([32.97.182.101]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id PAA22522 for ; Wed, 25 Apr 2001 15:55:24 -0400 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id PAA253402; Wed, 25 Apr 2001 15:53:16 -0400 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.117.200.72]) by northrelay02.pok.ibm.com (8.8.8m3/NCO v4.96) with ESMTP id PAA70616; Wed, 25 Apr 2001 15:49:47 -0400 Importance: Normal To: "Clemm, Geoff" Cc: WebDAV WG X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "Jason Crawford" Date: Wed, 25 Apr 2001 15:44:19 -0400 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 5.0.7 |March 21, 2001) at 04/25/2001 03:54:42 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: RE: Issue: XML_LANG_CLARIFY Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4854 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: To be persistant, I think we all agree the xml:lang attribute can be on the property node and doesn't have to be on a child. Do we agree that it can even be on the parent of the property node and still be persistant? Should we discourage the client from doing this though? Kikkers in de koek ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com From w3c-dist-auth-request@w3.org Wed Apr 25 16:58:26 2001 Received: from www19.w3.org ([18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA00959 for ; Wed, 25 Apr 2001 16:58:24 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA25110; Wed, 25 Apr 2001 16:44:51 -0400 (EDT) Resent-Date: Wed, 25 Apr 2001 16:44:51 -0400 (EDT) Resent-Message-Id: <200104252044.QAA25110@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id QAA25090 for ; Wed, 25 Apr 2001 16:44:35 -0400 (EDT) Received: from sus-ma1it00.rational.com (ext-37140.rational.com [192.229.37.140]) by tux.w3.org (8.9.3/8.9.3) with SMTP id QAA26829 for ; Wed, 25 Apr 2001 16:44:36 -0400 Received: from 192.168.215.70 by sus-ma1it00.rational.com (InterScan E-Mail VirusWall NT); Wed, 25 Apr 2001 16:46:37 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Wed, 25 Apr 2001 16:46:37 -0400 Message-ID: <3906C56A7BD1F54593344C05BD1374B1018E238E@SUS-MA1IT01> From: "Clemm, Geoff" To: WebDAV WG Date: Wed, 25 Apr 2001 16:46:41 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: RE: Issue: XML_LANG_CLARIFY Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4855 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: To keep things simple, I would just disallow the xml:lang attribute on the D:prop node. In fact, I would indicate that all attributes on the D:prop node are ignored unless explicitly defined by the protocol as being allowed there. This allows a client to ignore attributes on the D:prop node, and just store all attributes on the property node, without having to understand the inheritance semantics of those attributes. Cheers, Geoff -----Original Message----- From: Jason Crawford [mailto:ccjason@us.ibm.com] Sent: Wednesday, April 25, 2001 3:44 PM To: Clemm, Geoff Cc: WebDAV WG Subject: RE: Issue: XML_LANG_CLARIFY To be persistant, I think we all agree the xml:lang attribute can be on the property node and doesn't have to be on a child. Do we agree that it can even be on the parent of the property node and still be persistant? Should we discourage the client from doing this though? Kikkers in de koek ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com From w3c-dist-auth-request@w3.org Wed Apr 25 17:01:19 2001 Received: from www19.w3.org ([18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA01052 for ; Wed, 25 Apr 2001 17:01:18 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA26958; Wed, 25 Apr 2001 16:54:29 -0400 (EDT) Resent-Date: Wed, 25 Apr 2001 16:54:29 -0400 (EDT) Resent-Message-Id: <200104252054.QAA26958@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id QAA26929 for ; Wed, 25 Apr 2001 16:54:24 -0400 (EDT) Received: from mail.gmx.net (pop.gmx.net [194.221.183.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id QAA27726 for ; Wed, 25 Apr 2001 16:54:23 -0400 Received: (qmail 11408 invoked by uid 0); 25 Apr 2001 20:54:18 -0000 Received: from p3ee2479b.dip.t-dialin.net (HELO lisa) (62.226.71.155) by mail.gmx.net (mail02) with SMTP; 25 Apr 2001 20:54:18 -0000 From: "Julian Reschke" To: "Jason Crawford" , "Clemm, Geoff" Cc: "WebDAV WG" Date: Wed, 25 Apr 2001 22:54:16 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: Subject: AW: Issue: XML_LANG_CLARIFY Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4857 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit No, Canonical XML is very clear in that *all* attributes in the XML namespace are inherited when XML fragments are persisted/serialized. Thus: a) xml:lang may appear in the prop element or on any ancestor, b) what needs to be clarified is the behaviour for *other* attributes from the XML namespace, such as xml:space and xml:base. See also -----Ursprungliche Nachricht----- Von: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]Im Auftrag von Jason Crawford Gesendet: Mittwoch, 25. April 2001 21:44 An: Clemm, Geoff Cc: WebDAV WG Betreff: RE: Issue: XML_LANG_CLARIFY To be persistant, I think we all agree the xml:lang attribute can be on the property node and doesn't have to be on a child. Do we agree that it can even be on the parent of the property node and still be persistant? Should we discourage the client from doing this though? Kikkers in de koek ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com From w3c-dist-auth-request@w3.org Wed Apr 25 17:22:23 2001 Received: from www19.w3.org ([18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA01592 for ; Wed, 25 Apr 2001 17:22:22 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA27982; Wed, 25 Apr 2001 17:15:24 -0400 (EDT) Resent-Date: Wed, 25 Apr 2001 17:15:24 -0400 (EDT) Resent-Message-Id: <200104252115.RAA27982@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id RAA27962 for ; Wed, 25 Apr 2001 17:15:20 -0400 (EDT) Received: from sus-ma1it00.rational.com (ext-37140.rational.com [192.229.37.140]) by tux.w3.org (8.9.3/8.9.3) with SMTP id RAA29742 for ; Wed, 25 Apr 2001 17:15:21 -0400 Received: from 192.168.215.70 by sus-ma1it00.rational.com (InterScan E-Mail VirusWall NT); Wed, 25 Apr 2001 17:17:26 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Wed, 25 Apr 2001 17:17:26 -0400 Message-ID: <3906C56A7BD1F54593344C05BD1374B1018E2390@SUS-MA1IT01> From: "Clemm, Geoff" To: WebDAV WG Date: Wed, 25 Apr 2001 17:17:31 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-MIME-Autoconverted: from quoted-printable to 8bit by www19.w3.org id RAA27962 Subject: RE: Issue: XML_LANG_CLARIFY Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4859 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: X-MIME-Autoconverted: from 8bit to quoted-printable by www19.w3.org id RAA27982 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id RAA01592 From: Julian Reschke [mailto:julian.reschke@gmx.de] I don't see any advantage as long as the inheritence rules are clearly specified, such as in This doesn't help a server that encounters an attribute type that it doesn't understand (for example, a custom attribute or an attribute introduced since that server was written). If we only allow attributes on the property node and below, a server can at least save and return those attributes. If we allow attributes on the DAV:prop node, the server would need to know the inheritance characteristics of that attribute in order to know how/whether to persist it. I don't think we want to just say "all attributes are inherited". We could make an exception for xml:lang, but I don't see a compelling benefit for doing so (I'm not saying there isn't one, but rather just that I don't see it). But whatever we do with xml:lang, I believe we should say something in general about the handling of attributes on DAV:prop nodes (saying there can't be any is about the simplest thing we could say :-). Cheers, Geoff -----Ursprüngliche Nachricht----- Von: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]Im Auftrag von Clemm, Geoff Gesendet: Mittwoch, 25. April 2001 22:47 An: WebDAV WG Betreff: RE: Issue: XML_LANG_CLARIFY To keep things simple, I would just disallow the xml:lang attribute on the D:prop node. In fact, I would indicate that all attributes on the D:prop node are ignored unless explicitly defined by the protocol as being allowed there. This allows a client to ignore attributes on the D:prop node, and just store all attributes on the property node, without having to understand the inheritance semantics of those attributes. Cheers, Geoff -----Original Message----- From: Jason Crawford [mailto:ccjason@us.ibm.com] Sent: Wednesday, April 25, 2001 3:44 PM To: Clemm, Geoff Cc: WebDAV WG Subject: RE: Issue: XML_LANG_CLARIFY To be persistant, I think we all agree the xml:lang attribute can be on the property node and doesn't have to be on a child. Do we agree that it can even be on the parent of the property node and still be persistant? Should we discourage the client from doing this though? Kikkers in de koek ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com From w3c-dist-auth-request@w3.org Wed Apr 25 17:59:17 2001 Received: from www19.w3.org ([18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA02470 for ; Wed, 25 Apr 2001 17:59:15 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA28869; Wed, 25 Apr 2001 17:42:16 -0400 (EDT) Resent-Date: Wed, 25 Apr 2001 17:42:16 -0400 (EDT) Resent-Message-Id: <200104252142.RAA28869@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id RAA28849 for ; Wed, 25 Apr 2001 17:42:12 -0400 (EDT) Received: from cats.ucsc.edu (rumpleteazer.ucsc.edu [128.114.129.45]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id RAA32339 for ; Wed, 25 Apr 2001 17:42:12 -0400 Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177]) by cats.ucsc.edu (8.9.3/8.8.4.cats-athena) with SMTP id OAA02731 for ; Wed, 25 Apr 2001 14:42:12 -0700 (PDT) From: "Jim Whitehead" To: "WebDAV WG" Date: Wed, 25 Apr 2001 14:40:32 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <3AE7393D.2C9DD274@holoweb.net> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: RE: Issue: XML_LANG_CLARIFY Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4860 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > Jim Whitehead wrote: > > So I think this interpretation must be wrong. Do you agree? Just a minor clarification: these words were written by Jim *Davis*, in his original post on the subject. I recommend re-reading the original thread. - Jim From w3c-dist-auth-request@w3.org Wed Apr 25 20:46:59 2001 Received: from www19.w3.org ([18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA04959 for ; Wed, 25 Apr 2001 20:46:59 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA17640; Wed, 25 Apr 2001 14:36:46 -0400 (EDT) Resent-Date: Wed, 25 Apr 2001 14:36:46 -0400 (EDT) Resent-Message-Id: <200104251836.OAA17640@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id OAA17617 for ; Wed, 25 Apr 2001 14:36:36 -0400 (EDT) Received: from cats.ucsc.edu (rumpleteazer.ucsc.edu [128.114.129.45]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id OAA14595 for ; Wed, 25 Apr 2001 14:36:34 -0400 Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177]) by cats.ucsc.edu (8.9.3/8.8.4.cats-athena) with SMTP id LAA16195 for ; Wed, 25 Apr 2001 11:36:37 -0700 (PDT) From: "Jim Whitehead" To: "WebDAV WG" Date: Wed, 25 Apr 2001 11:34:58 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: Updated issues list Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4852 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit As we discuss and resolve the issues on the WebDAV Distributed Authoring Protocol, I will be updating the issues list with pointers to the email messages where the final group consensus is recorded (in a new issues list column, titled, "Resolution"). The issues list is available at: http://www.ics.uci.edu/pub/ietf/webdav/protocol/issues.html - Jim From w3c-dist-auth-request@w3.org Wed Apr 25 21:07:29 2001 Received: from www19.w3.org ([18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA05217 for ; Wed, 25 Apr 2001 21:07:29 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA17306; Wed, 25 Apr 2001 14:30:48 -0400 (EDT) Resent-Date: Wed, 25 Apr 2001 14:30:48 -0400 (EDT) Resent-Message-Id: <200104251830.OAA17306@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id OAA17286 for ; Wed, 25 Apr 2001 14:30:44 -0400 (EDT) Received: from cats.ucsc.edu (rumpleteazer.ucsc.edu [128.114.129.45]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id OAA13950 for ; Wed, 25 Apr 2001 14:30:43 -0400 Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177]) by cats.ucsc.edu (8.9.3/8.8.4.cats-athena) with SMTP id LAA14653 for ; Wed, 25 Apr 2001 11:30:46 -0700 (PDT) From: "Jim Whitehead" To: "WebDAV WG" Date: Wed, 25 Apr 2001 11:29:07 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: Issue: XML_LANG_CLARIFY Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4850 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit This issue is another way of attacking the XML property round-trip behavior problem. The issue was originally raised by Jim Davis: http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0203.html Jim Davis writes: It is unclear from the spec (12.13.2) where exactly the xml:lang attribute must appear in the XML request body in order to be stored. May it appear anywhere in the XML tree (even, eg as an attribute of the DAV:propstore element)? Or must is appear on a child of the property element within the DAV:prop? The XML spec says clearly that xml:lang may appear anywhere, and that is has scope over all children: "The intent declared with xml:lang is considered to apply to all elements within the content of the element where it is specified, unless overridden with another instance of xml:lang." On the other hand the DAV spec says: "Language tagging information in the property's value (in the "xml:lang" attribute, if present) MUST be persistently stored along with the property, and MUST be subsequently retrievable using PROPFIND." At least one implementor has interpreted this to mean it must be on the child. We need clarity on this, as it affects interoperability. To elaborate, can I say Kikkers in de koek Or do I have to push the attribute down into the child, as in Kikkers in de koek Note that the latter interpretation has two very bad consequences: 1) Since the client has to invent a placeholder element, and there's no obvious choice for the name of the element, it shoots interoperability. No two clients will use the same element name for this placeholder, and hence the values won't be comparable. 2) Since the current DASL base search protocol can't search properties whose values are structures (ie. are elements, on the wire) no language tagged property value will be searchable. So I think this interpretation must be wrong. Do you agree? ---- Section 12.13.2 of RFC 2518 currently states: Language tagging information in the property's value (in the "xml:lang" attribute, if present) MUST be persistently stored along with the property, and MUST be subsequently retrievable using PROPFIND. - Jim From w3c-dist-auth-request@w3.org Wed Apr 25 22:46:39 2001 Received: from www19.w3.org ([18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA08506 for ; Wed, 25 Apr 2001 22:46:39 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA26918; Wed, 25 Apr 2001 16:54:20 -0400 (EDT) Resent-Date: Wed, 25 Apr 2001 16:54:20 -0400 (EDT) Resent-Message-Id: <200104252054.QAA26918@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id QAA26898 for ; Wed, 25 Apr 2001 16:54:14 -0400 (EDT) Received: from dirk.holoweb.net (dirk2.holoweb.net [216.94.134.20]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id QAA27721 for ; Wed, 25 Apr 2001 16:54:11 -0400 Received: from holoweb.net ([216.94.134.192]) by dirk.holoweb.net (8.9.3/8.9.3) with ESMTP id QAA15045; Wed, 25 Apr 2001 16:53:55 -0400 (EDT) (envelope-from zodiac@holoweb.net) Message-ID: <3AE7393D.2C9DD274@holoweb.net> Date: Wed, 25 Apr 2001 16:53:17 -0400 From: Laurie Harper X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.5-15 i686) X-Accept-Language: en MIME-Version: 1.0 To: Jim Whitehead CC: WebDAV WG References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: Issue: XML_LANG_CLARIFY Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4856 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Jim Whitehead wrote: > So I think this interpretation must be wrong. Do you agree? I'd say it was doubly wrong, since the effect of an xml:lang attr on any ancestor element of the property should equally be persisted. L. -- http: www.holoweb.net/~zodiac/ | jabber: zodiac(@)jabber!org email: zodiac(@)holoweb!net | icq: #78724820 ----------------------------------------------------------------- condom: general protection error, child process produced. From w3c-dist-auth-request@w3.org Wed Apr 25 22:47:34 2001 Received: from www19.w3.org ([18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA08522 for ; Wed, 25 Apr 2001 22:47:33 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA27484; Wed, 25 Apr 2001 17:01:44 -0400 (EDT) Resent-Date: Wed, 25 Apr 2001 17:01:44 -0400 (EDT) Resent-Message-Id: <200104252101.RAA27484@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id RAA27460 for ; Wed, 25 Apr 2001 17:01:39 -0400 (EDT) Received: from mail.gmx.net (pop.gmx.net [194.221.183.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id RAA28424 for ; Wed, 25 Apr 2001 17:01:37 -0400 Received: (qmail 11078 invoked by uid 0); 25 Apr 2001 21:01:24 -0000 Received: from p3ee2479b.dip.t-dialin.net (HELO lisa) (62.226.71.155) by mail.gmx.net (mp007-rz3) with SMTP; 25 Apr 2001 21:01:24 -0000 From: "Julian Reschke" To: "Clemm, Geoff" , "WebDAV WG" Date: Wed, 25 Apr 2001 23:01:23 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: <3906C56A7BD1F54593344C05BD1374B1018E238E@SUS-MA1IT01> Subject: AW: Issue: XML_LANG_CLARIFY Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4858 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: X-MIME-Autoconverted: from 8bit to quoted-printable by www19.w3.org id RAA27484 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id WAA08522 I don't see any advantage as long as the inheritence rules are clearly specified, such as in -----Ursprüngliche Nachricht----- Von: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]Im Auftrag von Clemm, Geoff Gesendet: Mittwoch, 25. April 2001 22:47 An: WebDAV WG Betreff: RE: Issue: XML_LANG_CLARIFY To keep things simple, I would just disallow the xml:lang attribute on the D:prop node. In fact, I would indicate that all attributes on the D:prop node are ignored unless explicitly defined by the protocol as being allowed there. This allows a client to ignore attributes on the D:prop node, and just store all attributes on the property node, without having to understand the inheritance semantics of those attributes. Cheers, Geoff -----Original Message----- From: Jason Crawford [mailto:ccjason@us.ibm.com] Sent: Wednesday, April 25, 2001 3:44 PM To: Clemm, Geoff Cc: WebDAV WG Subject: RE: Issue: XML_LANG_CLARIFY To be persistant, I think we all agree the xml:lang attribute can be on the property node and doesn't have to be on a child. Do we agree that it can even be on the parent of the property node and still be persistant? Should we discourage the client from doing this though? Kikkers in de koek ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com From w3c-dist-auth-request@w3.org Thu Apr 26 01:51:41 2001 Received: from www19.w3.org ([18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA15513 for ; Thu, 26 Apr 2001 01:51:41 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id BAA19359; Thu, 26 Apr 2001 01:42:51 -0400 (EDT) Resent-Date: Thu, 26 Apr 2001 01:42:51 -0400 (EDT) Resent-Message-Id: <200104260542.BAA19359@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id BAA19339 for ; Thu, 26 Apr 2001 01:42:39 -0400 (EDT) Received: from kurgan.lyra.org (test.webdav.org [198.144.203.199]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id BAA07760 for ; Thu, 26 Apr 2001 01:42:39 -0400 Received: (from gstein@localhost) by kurgan.lyra.org (8.9.3/8.9.3) id VAA02206 for w3c-dist-auth@w3.org; Wed, 25 Apr 2001 21:42:15 -0700 X-Authentication-Warning: kurgan.lyra.org: gstein set sender to gstein@lyra.org using -f Date: Wed, 25 Apr 2001 21:42:15 -0700 From: Greg Stein To: WebDAV WG Message-ID: <20010425214215.G1374@lyra.org> Mail-Followup-To: WebDAV WG References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from julian.reschke@gmx.de on Wed, Apr 25, 2001 at 10:54:16PM +0200 X-URL: http://www.lyra.org/greg/ Subject: Re: Issue: XML_LANG_CLARIFY Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4861 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: I'm with Julian on this. The XML specification *clearly* states that xml:lang imposes its value on all its children. That is, it is scoped. Thus, any properties appear within a scope defined by any/all ancestors. The prefixes defined by the xmlns: attribute are similarly behaved. We persist those, without regard to where they may have occurred. xml:lang is exactly the same. We should *not* start reinterpreting the XML specifications to suit our perceptions of how things should work. We chose XML, so we need to abide by its rules. And one of those is that xml:lang is a scope. Cheers, -g On Wed, Apr 25, 2001 at 10:54:16PM +0200, Julian Reschke wrote: > No, > > Canonical XML is very clear in that *all* attributes in the XML namespace > are inherited when XML fragments are persisted/serialized. Thus: > > a) xml:lang may appear in the prop element or on any ancestor, > > b) what needs to be clarified is the behaviour for *other* attributes from > the XML namespace, such as xml:space and xml:base. > > See also > > > > > -----Ursprungliche Nachricht----- > Von: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]Im Auftrag von Jason Crawford > Gesendet: Mittwoch, 25. April 2001 21:44 > An: Clemm, Geoff > Cc: WebDAV WG > Betreff: RE: Issue: XML_LANG_CLARIFY > > > > > To be persistant, I think we all agree the xml:lang attribute can be on the > property node and doesn't have to be on a child. Do we agree that it can > even be on the parent of the property node and still be persistant? > Should we discourage the client from doing this though? > > > > Kikkers in de koek > > > > > ------------------------------------------ > Phone: 914-784-7569, ccjason@us.ibm.com -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Thu Apr 26 03:57:18 2001 Received: from www19.w3.org ([18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA25819 for ; Thu, 26 Apr 2001 03:57:16 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id CAA20651; Thu, 26 Apr 2001 02:18:49 -0400 (EDT) Resent-Date: Thu, 26 Apr 2001 02:18:49 -0400 (EDT) Resent-Message-Id: <200104260618.CAA20651@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id CAA20631 for ; Thu, 26 Apr 2001 02:18:40 -0400 (EDT) Received: from mail.gmx.net (pop.gmx.net [194.221.183.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id CAA10435 for ; Thu, 26 Apr 2001 02:18:40 -0400 Received: (qmail 26805 invoked by uid 0); 26 Apr 2001 06:18:05 -0000 Received: from pd950c1c2.dip.t-dialin.net (HELO lisa) (217.80.193.194) by mail.gmx.net (mail04) with SMTP; 26 Apr 2001 06:18:05 -0000 From: "Julian Reschke" To: "WebDAV WG" Date: Thu, 26 Apr 2001 08:18:03 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: <3906C56A7BD1F54593344C05BD1374B1018E2390@SUS-MA1IT01> Subject: AW: Issue: XML_LANG_CLARIFY Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4863 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: X-MIME-Autoconverted: from 8bit to quoted-printable by www19.w3.org id CAA20651 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA25819 Geoff, Canonical XML specifies the inheritance behaviour for all attributes in the XML namespace, that is with a namespaceUri of http://www.w3.org/XML/1998/namespace, so what a server needs to do is to check the namespace, that's all. There's a reason why the W3C is defining things like this -- if WebDAV is going to define it's own rules, it would better add a rationale to define why... In my proposal in http://lists.w3.org/Archives/Public/w3c-dist-auth/2001AprJun/0102.html I've tried to write down what seems to be the current consensus (no attributes except xml:lang), although just saying that RFC3076 (Canonical XML) applies (thus persisting *all* attributes on the property elements in addition to inherited attributes from the XML namespace) would make the *specification* simpler and more logical. Julian -----Ursprüngliche Nachricht----- Von: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]Im Auftrag von Clemm, Geoff Gesendet: Mittwoch, 25. April 2001 23:18 An: WebDAV WG Betreff: RE: Issue: XML_LANG_CLARIFY From: Julian Reschke [mailto:julian.reschke@gmx.de] I don't see any advantage as long as the inheritence rules are clearly specified, such as in This doesn't help a server that encounters an attribute type that it doesn't understand (for example, a custom attribute or an attribute introduced since that server was written). If we only allow attributes on the property node and below, a server can at least save and return those attributes. If we allow attributes on the DAV:prop node, the server would need to know the inheritance characteristics of that attribute in order to know how/whether to persist it. I don't think we want to just say "all attributes are inherited". We could make an exception for xml:lang, but I don't see a compelling benefit for doing so (I'm not saying there isn't one, but rather just that I don't see it). But whatever we do with xml:lang, I believe we should say something in general about the handling of attributes on DAV:prop nodes (saying there can't be any is about the simplest thing we could say :-). Cheers, Geoff -----Ursprüngliche Nachricht----- Von: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]Im Auftrag von Clemm, Geoff Gesendet: Mittwoch, 25. April 2001 22:47 An: WebDAV WG Betreff: RE: Issue: XML_LANG_CLARIFY To keep things simple, I would just disallow the xml:lang attribute on the D:prop node. In fact, I would indicate that all attributes on the D:prop node are ignored unless explicitly defined by the protocol as being allowed there. This allows a client to ignore attributes on the D:prop node, and just store all attributes on the property node, without having to understand the inheritance semantics of those attributes. Cheers, Geoff -----Original Message----- From: Jason Crawford [mailto:ccjason@us.ibm.com] Sent: Wednesday, April 25, 2001 3:44 PM To: Clemm, Geoff Cc: WebDAV WG Subject: RE: Issue: XML_LANG_CLARIFY To be persistant, I think we all agree the xml:lang attribute can be on the property node and doesn't have to be on a child. Do we agree that it can even be on the parent of the property node and still be persistant? Should we discourage the client from doing this though? Kikkers in de koek ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com From w3c-dist-auth-request@w3.org Thu Apr 26 03:57:30 2001 Received: from www19.w3.org ([18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA25830 for ; Thu, 26 Apr 2001 03:57:30 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id BAA19514; Thu, 26 Apr 2001 01:47:39 -0400 (EDT) Resent-Date: Thu, 26 Apr 2001 01:47:39 -0400 (EDT) Resent-Message-Id: <200104260547.BAA19514@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id BAA19487 for ; Thu, 26 Apr 2001 01:47:27 -0400 (EDT) Received: from kurgan.lyra.org (test.webdav.org [198.144.203.199]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id BAA08063 for ; Thu, 26 Apr 2001 01:47:25 -0400 Received: (from gstein@localhost) by kurgan.lyra.org (8.9.3/8.9.3) id VAA02215 for w3c-dist-auth@w3.org; Wed, 25 Apr 2001 21:47:07 -0700 X-Authentication-Warning: kurgan.lyra.org: gstein set sender to gstein@lyra.org using -f Date: Wed, 25 Apr 2001 21:47:06 -0700 From: Greg Stein To: WebDAV WG Message-ID: <20010425214706.H1374@lyra.org> Mail-Followup-To: WebDAV WG References: <3906C56A7BD1F54593344C05BD1374B1018E2386@SUS-MA1IT01> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <3906C56A7BD1F54593344C05BD1374B1018E2386@SUS-MA1IT01>; from gclemm@rational.com on Wed, Apr 25, 2001 at 02:36:39PM -0400 X-URL: http://www.lyra.org/greg/ Subject: Re: Issue: ALLPROP_AND_COMPUTED Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4862 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Nah, that is a bit too extreme. There are clients that may not be able to interpret all the properties, but still needs to retrieve them. These are clients that deal with arbitrary properties as blobs. allprop is needed to avoid a multiple-trip to fetch names then values. Let's also consider what would be needed if you're trying to do an allprop on a tree. You would need to issue a PROPFIND/propname with a Depth:1, then issue N PROPFINDs to get each set of properties from the resources. That is just *way* too burdensome. The alternative is a PROPFIND/allprop with Depth:1 as a single fetch for the properties of a collection and its members. Cheers, -g On Wed, Apr 25, 2001 at 02:36:39PM -0400, Clemm, Geoff wrote: > I believe it is simpler and more desireable to deprecate the use of allprop > in all situations, not just Depth:infinity. > > Cheers, > Geoff > > > -----Original Message----- > From: Jim Whitehead [mailto:ejw@cse.ucsc.edu] > Sent: Wednesday, April 25, 2001 2:20 PM > To: WebDAV WG > Subject: Issue: ALLPROP_AND_COMPUTED > > > This issue is currently stated as: > > If a server has some computed properties which are expensive to compute, > then PROPFIND allprop, especially PROPFIND allprop with Depth infinity can > be an expensive operation. There should be an implementation note added to > the document noting this problem. Suggestion that servers might want to be > conservative in their implementation of such compute expensive properties. > Clients should only perform PROPFIND allprop when necessary, not by default. > > It was raised by Ken Coar at the Advanced Collections breakout at the > Orlando IETF meeting. > > But, since that time there has been a substantive discussion of this issue, > begun by Lisa Dusseault, starting at: > > http://lists.w3.org/Archives/Public/w3c-dist-auth/2000OctDec/0034.html > > My understanding of the rough sentiment of the working group is: > > 1) PROPFIND allprop requests with Depth infinity should be deprecated. That > is, PROPFIND allprop with Depth infinity will remain in the WebDAV > Distributed Authoring Protocol, but there will be a requirements added that > new clients MUST NOT use this capability. When existing clients are > revised, they SHOULD be rewritten to avoid using PROPFIND allprop Depth > infinity requests. This will only apply to PROPFIND allprop with Depth > infinity -- PROPFIND allprop for Depth 0 and 1 will still be OK. > > 2) The default behavior of PROPFIND will be changed so it is Depth 0, not > Depth infinity. > > - Jim -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Thu Apr 26 09:26:35 2001 Received: from www19.w3.org ([18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA02899 for ; Thu, 26 Apr 2001 09:26:34 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id JAA17089; Thu, 26 Apr 2001 09:19:48 -0400 (EDT) Resent-Date: Thu, 26 Apr 2001 09:19:48 -0400 (EDT) Resent-Message-Id: <200104261319.JAA17089@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id JAA17066 for ; Thu, 26 Apr 2001 09:19:41 -0400 (EDT) Received: from sus-ma1it00.rational.com (ext-37140.rational.com [192.229.37.140]) by tux.w3.org (8.9.3/8.9.3) with SMTP id JAA12765 for ; Thu, 26 Apr 2001 09:19:41 -0400 Received: from 192.168.215.70 by sus-ma1it00.rational.com (InterScan E-Mail VirusWall NT); Thu, 26 Apr 2001 09:21:37 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Thu, 26 Apr 2001 09:21:37 -0400 Message-ID: <3906C56A7BD1F54593344C05BD1374B102CA756B@SUS-MA1IT01> From: "Clemm, Geoff" To: WebDAV WG Date: Thu, 26 Apr 2001 09:21:44 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: RE: Issue: ALLPROP_AND_COMPUTED Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4864 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: On Wed, Apr 25, 2001 at 02:36:39PM -0400, Clemm, Geoff wrote: > I believe it is simpler and more desireable to deprecate the use > of allprop in all situations, not just Depth:infinity. From: Greg Stein [mailto:gstein@lyra.org] Nah, that is a bit too extreme. There are clients that may not be able to interpret all the properties, but still needs to retrieve them. These are clients that deal with arbitrary properties as blobs. Yes, but that's what the DAV:propname does, while encouraging clients to be sensible if 5000 property names come back from the DAV:propname request. And in any case, clients are going to have to get used to the fact that the only way to get all the properties is to first use DAV:propname (both the versioning and the ACL spec explicitly allow a server to not return the versioning/acl live properties in response to a DAV:allprop request). allprop is needed to avoid a multiple-trip to fetch names then values. In this case "multiple" is "2", and given the cost of computing and transporting all properties on a resource, the cost of the extra round trip is insignificant. Let's also consider what would be needed if you're trying to do an allprop on a tree. You would need to issue a PROPFIND/propname with a Depth:1, then issue N PROPFINDs to get each set of properties from the resources. That is just *way* too burdensome. The client can just union the property names returned by PROPFIND/propname and make a single depth:1 PROPFIND request for that list (client side list union is both fast and easy). Commonly, the propname values for the members will be very similar, so the union of the property names will be not much longer than what is returned from a particular member. The alternative is a PROPFIND/allprop with Depth:1 as a single fetch for the properties of a collection and its members. Or a Depth:1 PROPFIND/propname, followed by a Depth:1 PROPFIND on the unioned list of property names. Cheers, Geoff From w3c-dist-auth-request@w3.org Thu Apr 26 09:27:02 2001 Received: from www19.w3.org ([18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA02910 for ; Thu, 26 Apr 2001 09:27:01 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id JAA17115; Thu, 26 Apr 2001 09:19:53 -0400 (EDT) Resent-Date: Thu, 26 Apr 2001 09:19:53 -0400 (EDT) Resent-Message-Id: <200104261319.JAA17115@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id JAA17094 for ; Thu, 26 Apr 2001 09:19:47 -0400 (EDT) Received: from sus-ma1it00.rational.com (ext-37140.rational.com [192.229.37.140]) by tux.w3.org (8.9.3/8.9.3) with SMTP id JAA12767 for ; Thu, 26 Apr 2001 09:19:45 -0400 Received: from 192.168.215.70 by sus-ma1it00.rational.com (InterScan E-Mail VirusWall NT); Thu, 26 Apr 2001 09:21:37 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Thu, 26 Apr 2001 09:21:37 -0400 Message-ID: <3906C56A7BD1F54593344C05BD1374B102CA756A@SUS-MA1IT01> From: "Clemm, Geoff" To: WebDAV WG Date: Thu, 26 Apr 2001 09:21:43 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: RE: Issue: XML_LANG_CLARIFY Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4865 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: The issue isn't whether the XML spec defines the scope and semantics of the xml:lang attribute (I agree that it does), but rather whether the XML spec requires that all XML nodes MUST support the xml:lang attribute. Perhaps someone could identify the section of the spec that makes this requirement? (It may well do so ... this isn't one of the specs I've memorized :-). So if the spec makes this requirement, then I agree that we must allow it anywhere. If the spec does *not* make this requirement, then we are free to state on what element types this attribute MUST NOT appear. But however we decide to treat the xml:lang attribute, or all attributes in the xml namespace, we do need to define how all the other attributes are handled. I believe the consensus is that all non xml: attributes MUST NOT appear on a DAV:prop element, so I'm happy with that. I personally think it is simpler to just say "no attributes on DAV:prop", rather than making a special case for xml:lang or other properties in the xml namespace (all you are saving is the few extra bytes it takes up to distribute those properties to the immediate children of DAV:prop), but I don't really care much about that, so if folks want to make xml:lang (or all properties in the xml namespace) special, I can live with that. Cheers, Geoff -----Original Message----- From: Greg Stein [mailto:gstein@lyra.org] Sent: Thursday, April 26, 2001 12:42 AM To: WebDAV WG Subject: Re: Issue: XML_LANG_CLARIFY I'm with Julian on this. The XML specification *clearly* states that xml:lang imposes its value on all its children. That is, it is scoped. Thus, any properties appear within a scope defined by any/all ancestors. The prefixes defined by the xmlns: attribute are similarly behaved. We persist those, without regard to where they may have occurred. xml:lang is exactly the same. We should *not* start reinterpreting the XML specifications to suit our perceptions of how things should work. We chose XML, so we need to abide by its rules. And one of those is that xml:lang is a scope. Cheers, -g On Wed, Apr 25, 2001 at 10:54:16PM +0200, Julian Reschke wrote: > No, > > Canonical XML is very clear in that *all* attributes in the XML namespace > are inherited when XML fragments are persisted/serialized. Thus: > > a) xml:lang may appear in the prop element or on any ancestor, > > b) what needs to be clarified is the behaviour for *other* attributes from > the XML namespace, such as xml:space and xml:base. > > See also > > > > > -----Ursprungliche Nachricht----- > Von: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]Im Auftrag von Jason Crawford > Gesendet: Mittwoch, 25. April 2001 21:44 > An: Clemm, Geoff > Cc: WebDAV WG > Betreff: RE: Issue: XML_LANG_CLARIFY > > > > > To be persistant, I think we all agree the xml:lang attribute can be on the > property node and doesn't have to be on a child. Do we agree that it can > even be on the parent of the property node and still be persistant? > Should we discourage the client from doing this though? > > > > Kikkers in de koek > > > > > ------------------------------------------ > Phone: 914-784-7569, ccjason@us.ibm.com -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Thu Apr 26 11:13:38 2001 Received: from www19.w3.org ([18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA07560 for ; Thu, 26 Apr 2001 11:13:38 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id KAA23105; Thu, 26 Apr 2001 10:59:28 -0400 (EDT) Resent-Date: Thu, 26 Apr 2001 10:59:28 -0400 (EDT) Resent-Message-Id: <200104261459.KAA23105@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id KAA23085 for ; Thu, 26 Apr 2001 10:59:24 -0400 (EDT) Received: from mail.gmx.net (pop.gmx.net [194.221.183.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id KAA23040 for ; Thu, 26 Apr 2001 10:59:24 -0400 Received: (qmail 26112 invoked by uid 0); 26 Apr 2001 14:58:41 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mp007-rz3) with SMTP; 26 Apr 2001 14:58:41 -0000 From: "Julian Reschke" To: "WebDAV WG" Date: Thu, 26 Apr 2001 16:58:41 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-reply-to: <3906C56A7BD1F54593344C05BD1374B102CA756A@SUS-MA1IT01> X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Subject: AW: Issue: XML_LANG_CLARIFY Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4866 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: X-MIME-Autoconverted: from 8bit to quoted-printable by www19.w3.org id KAA23105 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA07560 1) If you don't validate (and although the RFC shows DTD fragments, they can't be used for validation), any attribute can appear on any element. It's up the RFC to define what this means. 2) The current RFC current defines that xml:lang is to be persisted, no matter whether it appears on the property element or an ancestor. 3) Actually, I would prefer to state that *any* attribute can appear on the property element, and that they all should be persisted. It makes the spec easier and would conform with Canonical XML. -----Ursprüngliche Nachricht----- Von: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]Im Auftrag von Clemm, Geoff Gesendet: Donnerstag, 26. April 2001 15:22 An: WebDAV WG Betreff: RE: Issue: XML_LANG_CLARIFY The issue isn't whether the XML spec defines the scope and semantics of the xml:lang attribute (I agree that it does), but rather whether the XML spec requires that all XML nodes MUST support the xml:lang attribute. Perhaps someone could identify the section of the spec that makes this requirement? (It may well do so ... this isn't one of the specs I've memorized :-). So if the spec makes this requirement, then I agree that we must allow it anywhere. If the spec does *not* make this requirement, then we are free to state on what element types this attribute MUST NOT appear. But however we decide to treat the xml:lang attribute, or all attributes in the xml namespace, we do need to define how all the other attributes are handled. I believe the consensus is that all non xml: attributes MUST NOT appear on a DAV:prop element, so I'm happy with that. I personally think it is simpler to just say "no attributes on DAV:prop", rather than making a special case for xml:lang or other properties in the xml namespace (all you are saving is the few extra bytes it takes up to distribute those properties to the immediate children of DAV:prop), but I don't really care much about that, so if folks want to make xml:lang (or all properties in the xml namespace) special, I can live with that. Cheers, Geoff -----Original Message----- From: Greg Stein [mailto:gstein@lyra.org] Sent: Thursday, April 26, 2001 12:42 AM To: WebDAV WG Subject: Re: Issue: XML_LANG_CLARIFY I'm with Julian on this. The XML specification *clearly* states that xml:lang imposes its value on all its children. That is, it is scoped. Thus, any properties appear within a scope defined by any/all ancestors. The prefixes defined by the xmlns: attribute are similarly behaved. We persist those, without regard to where they may have occurred. xml:lang is exactly the same. We should *not* start reinterpreting the XML specifications to suit our perceptions of how things should work. We chose XML, so we need to abide by its rules. And one of those is that xml:lang is a scope. Cheers, -g On Wed, Apr 25, 2001 at 10:54:16PM +0200, Julian Reschke wrote: > No, > > Canonical XML is very clear in that *all* attributes in the XML namespace > are inherited when XML fragments are persisted/serialized. Thus: > > a) xml:lang may appear in the prop element or on any ancestor, > > b) what needs to be clarified is the behaviour for *other* attributes from > the XML namespace, such as xml:space and xml:base. > > See also > > > > > -----Ursprungliche Nachricht----- > Von: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]Im Auftrag von Jason Crawford > Gesendet: Mittwoch, 25. April 2001 21:44 > An: Clemm, Geoff > Cc: WebDAV WG > Betreff: RE: Issue: XML_LANG_CLARIFY > > > > > To be persistant, I think we all agree the xml:lang attribute can be on the > property node and doesn't have to be on a child. Do we agree that it can > even be on the parent of the property node and still be persistant? > Should we discourage the client from doing this though? > > > > Kikkers in de koek > > > > > ------------------------------------------ > Phone: 914-784-7569, ccjason@us.ibm.com -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Thu Apr 26 12:06:53 2001 Received: from www19.w3.org ([18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA09988 for ; Thu, 26 Apr 2001 12:06:40 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id LAA26412; Thu, 26 Apr 2001 11:57:09 -0400 (EDT) Resent-Date: Thu, 26 Apr 2001 11:57:09 -0400 (EDT) Resent-Message-Id: <200104261557.LAA26412@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id LAA26392 for ; Thu, 26 Apr 2001 11:57:01 -0400 (EDT) Received: from sus-ma1it00.rational.com (ext-37140.rational.com [192.229.37.140]) by tux.w3.org (8.9.3/8.9.3) with SMTP id LAA28443 for ; Thu, 26 Apr 2001 11:57:00 -0400 Received: from 192.168.215.70 by sus-ma1it00.rational.com (InterScan E-Mail VirusWall NT); Thu, 26 Apr 2001 11:58:55 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Thu, 26 Apr 2001 11:58:55 -0400 Message-ID: <3906C56A7BD1F54593344C05BD1374B1018E2399@SUS-MA1IT01> From: "Clemm, Geoff" To: WebDAV WG Date: Thu, 26 Apr 2001 11:59:04 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Issue: XML_LANG_CLARIFY Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4867 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: From: Julian Reschke [mailto:julian.reschke@gmx.de] 1) If you don't validate (and although the RFC shows DTD fragments, they can't be used for validation), any attribute can appear on any element. It's up the RFC to define what this means. The RFC is equally capable of declaring that an attribute on a paricular element type is syntactically illegal. Whether or not the XML "DTD validates" is not especially relevant or interesting (we have many syntactic constraints in the protocol that cannot be expressed conveniently in DTD form). 2) The current RFC current defines that xml:lang is to be persisted, no matter whether it appears on the property element or an ancestor. To be precise, RFC 2518 states: Language tagging information in the property's value (in the "xml:lang" attribute, if present) MUST be persistently stored along with the property, and MUST be subsequently retrievable using PROPFIND. This statement does not specify whether an xml:lang attribute can appear in the DAV:prop element, or just in the actual property value elements. In other words, a statement of the form "no attributes can be placed on a DAV:prop element" would not conflict with this language in RFC 2518. 3) Actually, I would prefer to state that *any* attribute can appear on the property element, and that they all should be persisted. It makes the spec easier and would conform with Canonical XML. Just to make sure we aren't talking past each other, I have very different opinions on what we should allow on the DAV:prop element (I prefer no attributes, but can live with "only xml:lang" or "only attributes in the xml namespace"), and what we allow on the property elements, e.g. DAV:displayname, DAV:getcontentlength, etc. (I prefer all attributes allowed, and must be maintained by the server). So when you say "any attribute can appear on a property element", if you are referring to elements like "DAV:displayname", I agree with you, but if you are referring to the DAV:prop element, I disagree. And the spec is free to disallow attributes on DAV:prop but allow attributes on elements like DAV:displayname. Cheers, Geoff From w3c-dist-auth-request@w3.org Thu Apr 26 12:24:30 2001 Received: from www19.w3.org ([18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA10778 for ; Thu, 26 Apr 2001 12:24:29 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA27357; Thu, 26 Apr 2001 12:17:52 -0400 (EDT) Resent-Date: Thu, 26 Apr 2001 12:17:52 -0400 (EDT) Resent-Message-Id: <200104261617.MAA27357@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id MAA27331 for ; Thu, 26 Apr 2001 12:17:47 -0400 (EDT) Received: from kurgan.lyra.org (test.webdav.org [198.144.203.199]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id MAA30346 for ; Thu, 26 Apr 2001 12:17:45 -0400 Received: (from gstein@localhost) by kurgan.lyra.org (8.9.3/8.9.3) id JAA03097 for w3c-dist-auth@w3.org; Thu, 26 Apr 2001 09:20:28 -0700 X-Authentication-Warning: kurgan.lyra.org: gstein set sender to gstein@lyra.org using -f Date: Thu, 26 Apr 2001 09:20:27 -0700 From: Greg Stein To: WebDAV WG Message-ID: <20010426092027.F1374@lyra.org> Mail-Followup-To: WebDAV WG References: <3906C56A7BD1F54593344C05BD1374B102CA756B@SUS-MA1IT01> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <3906C56A7BD1F54593344C05BD1374B102CA756B@SUS-MA1IT01>; from gclemm@rational.com on Thu, Apr 26, 2001 at 09:21:44AM -0400 X-URL: http://www.lyra.org/greg/ Subject: Re: Issue: ALLPROP_AND_COMPUTED Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4869 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Fine, you have a nifty answer of replacing one allprop with two requests. But what is the point of tossing allprop, then? If a client is going to get all the names, then fetch them all, they are still going to end up fetching the "time-consuming, computed" properties. The issue isn't tossing allprop, but providing a warning to clients about dealing with expensive computed properties. Removing allprop does not solve the computed problem. Since allprop *is* useful, then there is no reason to remove it. Cheers, -g On Thu, Apr 26, 2001 at 09:21:44AM -0400, Clemm, Geoff wrote: > On Wed, Apr 25, 2001 at 02:36:39PM -0400, Clemm, Geoff wrote: > > I believe it is simpler and more desireable to deprecate the use > > of allprop in all situations, not just Depth:infinity. > > From: Greg Stein [mailto:gstein@lyra.org] > > Nah, that is a bit too extreme. There are clients that may not be > able to interpret all the properties, but still needs to retrieve > them. These are clients that deal with arbitrary properties as > blobs. > > Yes, but that's what the DAV:propname does, while encouraging clients > to be sensible if 5000 property names come back from the DAV:propname > request. > > And in any case, clients are going to have to get used to the fact > that the only way to get all the properties is to first use > DAV:propname (both the versioning and the ACL spec explicitly allow a > server to not return the versioning/acl live properties in response to > a DAV:allprop request). > > allprop is needed to avoid a multiple-trip to fetch names then values. > > In this case "multiple" is "2", and given the cost of computing and > transporting all properties on a resource, the cost of the extra round > trip is insignificant. > > Let's > also consider what would be needed if you're trying to do an allprop on a > tree. You would need to issue a PROPFIND/propname with a Depth:1, then > issue > N PROPFINDs to get each set of properties from the resources. That is > just > *way* too burdensome. > > The client can just union the property names returned by > PROPFIND/propname and make a single depth:1 PROPFIND request for that > list (client side list union is both fast and easy). Commonly, the > propname values for the members will be very similar, so the union of > the property names will be not much longer than what is returned from > a particular member. > > The alternative is a PROPFIND/allprop with Depth:1 as a single fetch for > the > properties of a collection and its members. > > Or a Depth:1 PROPFIND/propname, followed by a Depth:1 PROPFIND > on the unioned list of property names. > > Cheers, > Geoff -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Thu Apr 26 12:29:02 2001 Received: from www19.w3.org ([18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA11060 for ; Thu, 26 Apr 2001 12:29:02 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA27866; Thu, 26 Apr 2001 12:21:59 -0400 (EDT) Resent-Date: Thu, 26 Apr 2001 12:21:59 -0400 (EDT) Resent-Message-Id: <200104261621.MAA27866@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id MAA27821 for ; Thu, 26 Apr 2001 12:21:50 -0400 (EDT) Received: from kurgan.lyra.org (test.webdav.org [198.144.203.199]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id MAA30781 for ; Thu, 26 Apr 2001 12:21:50 -0400 Received: (from gstein@localhost) by kurgan.lyra.org (8.9.3/8.9.3) id JAA03105 for w3c-dist-auth@w3.org; Thu, 26 Apr 2001 09:24:37 -0700 X-Authentication-Warning: kurgan.lyra.org: gstein set sender to gstein@lyra.org using -f Date: Thu, 26 Apr 2001 09:24:37 -0700 From: Greg Stein To: WebDAV WG Message-ID: <20010426092437.G1374@lyra.org> Mail-Followup-To: WebDAV WG References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from ejw@cse.ucsc.edu on Wed, Apr 25, 2001 at 11:19:54AM -0700 X-URL: http://www.lyra.org/greg/ Subject: Re: Issue: ALLPROP_AND_COMPUTED Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4870 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: On Wed, Apr 25, 2001 at 11:19:54AM -0700, Jim Whitehead wrote: >... > My understanding of the rough sentiment of the working group is: > > 1) PROPFIND allprop requests with Depth infinity should be deprecated. That > is, PROPFIND allprop with Depth infinity will remain in the WebDAV > Distributed Authoring Protocol, but there will be a requirements added that > new clients MUST NOT use this capability. When existing clients are > revised, they SHOULD be rewritten to avoid using PROPFIND allprop Depth > infinity requests. This will only apply to PROPFIND allprop with Depth > infinity -- PROPFIND allprop for Depth 0 and 1 will still be OK. Toss the timing stuff. The revised text should simply state that clients MUST NOT use the capability. Some existing clients will "not conform" for a bit, but that is not our problem, and it probably won't be an issue anyways. > 2) The default behavior of PROPFIND will be changed so it is Depth 0, not > Depth infinity. I agree with this one, but it could be a troublesome change. mod_dav normally disallows Depth:infinity PROPFINDs (unless the server is confiured to allow them), so maybe clients are used to sending a Depth:0 or 1. Hard to say. The point is that a client that doesn't send a depth header, and expects a depth of infinity is going to be very surprised by a Depth:0 response. Cheers, -g -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Thu Apr 26 12:32:40 2001 Received: from www19.w3.org ([18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA11256 for ; Thu, 26 Apr 2001 12:32:38 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA27188; Thu, 26 Apr 2001 12:15:31 -0400 (EDT) Resent-Date: Thu, 26 Apr 2001 12:15:31 -0400 (EDT) Resent-Message-Id: <200104261615.MAA27188@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id MAA27150 for ; Thu, 26 Apr 2001 12:15:22 -0400 (EDT) Received: from mail.gmx.net (pop.gmx.net [194.221.183.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id MAA30165 for ; Thu, 26 Apr 2001 12:15:21 -0400 Received: (qmail 6332 invoked by uid 0); 26 Apr 2001 16:14:45 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mail09) with SMTP; 26 Apr 2001 16:14:45 -0000 From: "Julian Reschke" To: "WebDAV WG" Date: Thu, 26 Apr 2001 18:14:44 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <3906C56A7BD1F54593344C05BD1374B1018E2399@SUS-MA1IT01> X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Subject: AW: Issue: XML_LANG_CLARIFY Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4868 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > Von: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]Im Auftrag von Clemm, Geoff > Gesendet: Donnerstag, 26. April 2001 17:59 > An: WebDAV WG > Betreff: RE: Issue: XML_LANG_CLARIFY > > > From: Julian Reschke [mailto:julian.reschke@gmx.de] > > 1) If you don't validate (and although the RFC shows DTD > fragments, they > can't be used for validation), any attribute can appear on any element. > It's > up the RFC to define what this means. > > The RFC is equally capable of declaring that an attribute on a > paricular element type is syntactically illegal. Whether or not the > XML "DTD validates" is not especially relevant or interesting (we have > many syntactic constraints in the protocol that cannot be expressed > conveniently in DTD form). I agree. I think this is what I said as well :-) > 2) The current RFC current defines that xml:lang is to be persisted, no > matter whether it appears on the property element or an ancestor. > > To be precise, RFC 2518 states: > > Language tagging information in the property's value (in the > "xml:lang" attribute, if present) MUST be persistently stored along > with the property, and MUST be subsequently retrievable using > PROPFIND. > > This statement does not specify whether an xml:lang attribute > can appear in the DAV:prop element, or just in the actual property > value elements. In other words, a statement of the form "no > attributes can be placed on a DAV:prop element" would not conflict > with this language in RFC 2518. Yes. The current wording isn't very precise because if refer's to the property's value without having defined what the property value actually is. However, I would claim that if intent was to say that xml:lang should be persisted only for child elements of the property element, this would have been redundant anyway (I thought we agree that attributes of child elements of the property element need to be persisted anyway, right?). > 3) Actually, I would prefer to state that *any* attribute can appear on > the > property element, and that they all should be persisted. It makes the > spec > easier and would conform with Canonical XML. > > Just to make sure we aren't talking past each other, I have very > different opinions on what we should allow on the DAV:prop element (I > prefer no attributes, but can live with "only xml:lang" or "only > attributes in the xml namespace"), and what we allow on the property > elements, e.g. DAV:displayname, DAV:getcontentlength, etc. (I prefer > all attributes allowed, and must be maintained by the server). > So when you say "any attribute can appear on a property element", if > you are referring to elements like "DAV:displayname", I agree with > you, but if you are referring to the DAV:prop element, I disagree. > And the spec is free to disallow attributes on DAV:prop but allow > attributes on elements like DAV:displayname. Seems that after all we agree :-) From w3c-dist-auth-request@w3.org Thu Apr 26 12:42:49 2001 Received: from www19.w3.org ([18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA11732 for ; Thu, 26 Apr 2001 12:42:44 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA28779; Thu, 26 Apr 2001 12:34:47 -0400 (EDT) Resent-Date: Thu, 26 Apr 2001 12:34:47 -0400 (EDT) Resent-Message-Id: <200104261634.MAA28779@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id MAA28759 for ; Thu, 26 Apr 2001 12:34:43 -0400 (EDT) Received: from sus-ma1it00.rational.com (ext-37140.rational.com [192.229.37.140]) by tux.w3.org (8.9.3/8.9.3) with SMTP id MAA32102 for ; Thu, 26 Apr 2001 12:34:43 -0400 Received: from 192.168.215.70 by sus-ma1it00.rational.com (InterScan E-Mail VirusWall NT); Thu, 26 Apr 2001 12:36:51 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Thu, 26 Apr 2001 12:36:51 -0400 Message-ID: <3906C56A7BD1F54593344C05BD1374B1018E239B@SUS-MA1IT01> From: "Clemm, Geoff" To: WebDAV WG Date: Thu, 26 Apr 2001 12:37:00 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: RE: Issue: ALLPROP_AND_COMPUTED Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4871 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: The reason I want to get rid of DAV:allprop is that I believe the protocol is simpler without it. Otherwise you have to define allprop, define its behavior, and then constrain its usage to only be Depth:0 or Depth:1. Since there is a perfectly good 2 request alternative to allprop, I believe we have one of those golden opportunities to actually *simpilify* the protocol, instead of layering on yet one more obscure rule (i.e. the "allprop only with Depth:0 or Depth:1" rule). Cheers, Geoff -----Original Message----- From: Greg Stein [mailto:gstein@lyra.org] Sent: Thursday, April 26, 2001 12:20 PM To: WebDAV WG Subject: Re: Issue: ALLPROP_AND_COMPUTED Fine, you have a nifty answer of replacing one allprop with two requests. But what is the point of tossing allprop, then? If a client is going to get all the names, then fetch them all, they are still going to end up fetching the "time-consuming, computed" properties. The issue isn't tossing allprop, but providing a warning to clients about dealing with expensive computed properties. Removing allprop does not solve the computed problem. Since allprop *is* useful, then there is no reason to remove it. Cheers, -g On Thu, Apr 26, 2001 at 09:21:44AM -0400, Clemm, Geoff wrote: > On Wed, Apr 25, 2001 at 02:36:39PM -0400, Clemm, Geoff wrote: > > I believe it is simpler and more desireable to deprecate the use > > of allprop in all situations, not just Depth:infinity. > > From: Greg Stein [mailto:gstein@lyra.org] > > Nah, that is a bit too extreme. There are clients that may not be > able to interpret all the properties, but still needs to retrieve > them. These are clients that deal with arbitrary properties as > blobs. > > Yes, but that's what the DAV:propname does, while encouraging clients > to be sensible if 5000 property names come back from the DAV:propname > request. > > And in any case, clients are going to have to get used to the fact > that the only way to get all the properties is to first use > DAV:propname (both the versioning and the ACL spec explicitly allow a > server to not return the versioning/acl live properties in response to > a DAV:allprop request). > > allprop is needed to avoid a multiple-trip to fetch names then values. > > In this case "multiple" is "2", and given the cost of computing and > transporting all properties on a resource, the cost of the extra round > trip is insignificant. > > Let's > also consider what would be needed if you're trying to do an allprop on a > tree. You would need to issue a PROPFIND/propname with a Depth:1, then > issue > N PROPFINDs to get each set of properties from the resources. That is > just > *way* too burdensome. > > The client can just union the property names returned by > PROPFIND/propname and make a single depth:1 PROPFIND request for that > list (client side list union is both fast and easy). Commonly, the > propname values for the members will be very similar, so the union of > the property names will be not much longer than what is returned from > a particular member. > > The alternative is a PROPFIND/allprop with Depth:1 as a single fetch for > the > properties of a collection and its members. > > Or a Depth:1 PROPFIND/propname, followed by a Depth:1 PROPFIND > on the unioned list of property names. > > Cheers, > Geoff -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Thu Apr 26 14:06:11 2001 Received: from www19.w3.org ([18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA14717 for ; Thu, 26 Apr 2001 14:06:07 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA03540; Thu, 26 Apr 2001 13:49:53 -0400 (EDT) Resent-Date: Thu, 26 Apr 2001 13:49:53 -0400 (EDT) Resent-Message-Id: <200104261749.NAA03540@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id NAA03515 for ; Thu, 26 Apr 2001 13:49:32 -0400 (EDT) Received: from megapathdsl.net (snowbird.megapath.net [216.200.176.7]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id NAA06960 for ; Thu, 26 Apr 2001 13:49:26 -0400 Received: from [216.36.75.57] (HELO beaver) by megapathdsl.net (CommuniGate Pro SMTP 3.4.3) with SMTP id 20611006; Thu, 26 Apr 2001 10:48:34 -0700 From: "Lisa Dusseault" To: "Clemm, Geoff" , "WebDAV WG" Date: Thu, 26 Apr 2001 10:48:07 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: <3906C56A7BD1F54593344C05BD1374B1018E239B@SUS-MA1IT01> Subject: RE: Issue: ALLPROP_AND_COMPUTED Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4872 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit To second what Geoff is saying, it really makes the protocol simpler for the client if they know they CANT rely on allprop. It doesn't return all properties; it may fail on some servers. Better not to use it at all. lisa > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff > Sent: Thursday, April 26, 2001 9:37 AM > To: WebDAV WG > Subject: RE: Issue: ALLPROP_AND_COMPUTED > > > The reason I want to get rid of DAV:allprop is that I believe the > protocol is simpler without it. Otherwise you have to define allprop, > define > its behavior, and then constrain its usage to only be Depth:0 or > Depth:1. Since there is a perfectly good 2 request alternative to > allprop, I believe we have one of those golden opportunities to > actually *simpilify* the protocol, instead of layering on yet one > more obscure rule (i.e. the "allprop only with Depth:0 or Depth:1" > rule). > > Cheers, > Geoff > > -----Original Message----- > From: Greg Stein [mailto:gstein@lyra.org] > Sent: Thursday, April 26, 2001 12:20 PM > To: WebDAV WG > Subject: Re: Issue: ALLPROP_AND_COMPUTED > > > Fine, you have a nifty answer of replacing one allprop with two requests. > But what is the point of tossing allprop, then? If a client is > going to get > all the names, then fetch them all, they are still going to end > up fetching > the "time-consuming, computed" properties. > > The issue isn't tossing allprop, but providing a warning to clients about > dealing with expensive computed properties. > > Removing allprop does not solve the computed problem. Since allprop *is* > useful, then there is no reason to remove it. > > Cheers, > -g > > On Thu, Apr 26, 2001 at 09:21:44AM -0400, Clemm, Geoff wrote: > > On Wed, Apr 25, 2001 at 02:36:39PM -0400, Clemm, Geoff wrote: > > > I believe it is simpler and more desireable to deprecate the use > > > of allprop in all situations, not just Depth:infinity. > > > > From: Greg Stein [mailto:gstein@lyra.org] > > > > Nah, that is a bit too extreme. There are clients that may not be > > able to interpret all the properties, but still needs to retrieve > > them. These are clients that deal with arbitrary properties as > > blobs. > > > > Yes, but that's what the DAV:propname does, while encouraging clients > > to be sensible if 5000 property names come back from the DAV:propname > > request. > > > > And in any case, clients are going to have to get used to the fact > > that the only way to get all the properties is to first use > > DAV:propname (both the versioning and the ACL spec explicitly allow a > > server to not return the versioning/acl live properties in response to > > a DAV:allprop request). > > > > allprop is needed to avoid a multiple-trip to fetch names > then values. > > > > In this case "multiple" is "2", and given the cost of computing and > > transporting all properties on a resource, the cost of the extra round > > trip is insignificant. > > > > Let's > > also consider what would be needed if you're trying to do an > allprop on > a > > tree. You would need to issue a PROPFIND/propname with a > Depth:1, then > > issue > > N PROPFINDs to get each set of properties from the resources. That is > > just > > *way* too burdensome. > > > > The client can just union the property names returned by > > PROPFIND/propname and make a single depth:1 PROPFIND request for that > > list (client side list union is both fast and easy). Commonly, the > > propname values for the members will be very similar, so the union of > > the property names will be not much longer than what is returned from > > a particular member. > > > > The alternative is a PROPFIND/allprop with Depth:1 as a single fetch > for > > the > > properties of a collection and its members. > > > > Or a Depth:1 PROPFIND/propname, followed by a Depth:1 PROPFIND > > on the unioned list of property names. > > > > Cheers, > > Geoff > > -- > Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Thu Apr 26 23:30:06 2001 Received: from www19.w3.org ([18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA00461 for ; Thu, 26 Apr 2001 23:30:03 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id TAA17582; Thu, 26 Apr 2001 19:41:51 -0400 (EDT) Resent-Date: Thu, 26 Apr 2001 19:41:51 -0400 (EDT) Resent-Message-Id: <200104262341.TAA17582@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id TAA17562 for ; Thu, 26 Apr 2001 19:41:47 -0400 (EDT) Received: from cats.ucsc.edu (rumpleteazer.ucsc.edu [128.114.129.45]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id TAA03078 for ; Thu, 26 Apr 2001 19:41:47 -0400 Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177]) by cats.ucsc.edu (8.9.3/8.8.4.cats-athena) with SMTP id QAA28769 for ; Thu, 26 Apr 2001 16:41:47 -0700 (PDT) From: "Jim Whitehead" To: "WebDAV WG" Date: Thu, 26 Apr 2001 16:40:05 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: Repository in a Box Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4873 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Members of this list might be interested in the following project: Repository in a Box http://www.nhse.org/RIB/index.html REPOSITORY IN A BOX (RIB) is a software package for creating WWW metadata repositories. Metadata is information that describes reusable objects, such as software. RIB allows the user to enter metadata into a user friendly java applet which then sends the information to a RIB server via HTTP. The information is then stored in an SQL database where it is automatically made available in a fully functional web site (catalog, search page, etc). Repositories which use similar data models can use the XML processing capabilities of RIB to share information via the Internet. Third party applications can access the data stored in RIB by using the RIB Application Programmer's Interface (API). Various tools utilizing the RIBAPI are available here. On the surface, it seems like DAV + DASL provide a set of functionality very similar to that provided by the RIB project. - Jim From w3c-dist-auth-request@w3.org Fri Apr 27 06:52:09 2001 Received: from www19.w3.org ([18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA21676 for ; Fri, 27 Apr 2001 06:52:09 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id GAA20888; Fri, 27 Apr 2001 06:46:18 -0400 (EDT) Resent-Date: Fri, 27 Apr 2001 06:46:18 -0400 (EDT) Resent-Message-Id: <200104271046.GAA20888@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id GAA20861 for ; Fri, 27 Apr 2001 06:46:09 -0400 (EDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id GAA22271 for ; Fri, 27 Apr 2001 06:46:04 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21324; Fri, 27 Apr 2001 06:45:58 -0400 (EDT) Message-Id: <200104271045.GAA21324@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: w3c-dist-auth@w3.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 27 Apr 2001 06:45:58 -0400 Subject: I-D ACTION:draft-ietf-webdav-acl-05.txt Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4874 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the WWW Distributed Authoring and Versioning Working Group of the IETF. Title : WebDAV Access Control Protocol Author(s) : G. Clemm, A. Hopkins, E. Sedlar, J. Whitehead Filename : draft-ietf-webdav-acl-05.txt Pages : 30 Date : 26-Apr-01 This document specifies a set of methods, headers, and message bodies that define the WebDAV Access Control extensions to the HTTP/1.1 protocol. This protocol permits a client to remotely read and modify access control lists that instruct a server whether to grant or deny operations upon a resource (such as HTTP method invocations) by a given principal. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-webdav-acl-05.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-webdav-acl-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-webdav-acl-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010426132720.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-webdav-acl-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-webdav-acl-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010426132720.I-D@ietf.org> --OtherAccess-- --NextPart-- From w3c-dist-auth-request@w3.org Sat Apr 28 14:15:55 2001 Received: from www19.w3.org ([18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA15827 for ; Sat, 28 Apr 2001 14:15:52 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA28674; Sat, 28 Apr 2001 14:07:21 -0400 (EDT) Resent-Date: Sat, 28 Apr 2001 14:07:21 -0400 (EDT) Resent-Message-Id: <200104281807.OAA28674@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id OAA28653 for ; Sat, 28 Apr 2001 14:07:10 -0400 (EDT) Received: from e1.ny.us.ibm.com ([32.97.182.101]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id OAA32151 for ; Sat, 28 Apr 2001 14:07:10 -0400 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id OAA452278; Sat, 28 Apr 2001 14:04:44 -0400 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.117.200.72]) by northrelay02.pok.ibm.com (8.8.8m3/NCO v4.96) with ESMTP id OAA83050; Sat, 28 Apr 2001 14:01:08 -0400 Importance: Normal To: Greg Stein Cc: WebDAV WG X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "Jason Crawford" Date: Sat, 28 Apr 2001 14:03:04 -0400 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 5.0.7 |March 21, 2001) at 04/28/2001 02:06:11 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: Re: Issue: ALLPROP_AND_COMPUTED Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4875 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: << The issue isn't tossing allprop, but providing a warning to clients about dealing with expensive computed properties. Removing allprop does not solve the computed problem. Since allprop *is* useful, then there is no reason to remove it. >> I agree with Greg. We can still have this size problem with depth one and depth zero. And FTP's MGET can have a similar problem and we don't hear people complaining about that. Are we being overly concerned? We as authors of the spec can't know if this is a problem in advance either. Sometimes it will be and other times it won't be. Let's just deal with what a client or server can do in situations where they feel it's a problem. So... Is it sufficient for a client to simply disconnect/timeout? Should we have an error code that the server can use if it deems a request too expensive? Or is there some other simple approach? Or should we defer the issue until version 2.0 if it then looks like this truly is a problem? J.